Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

STQA

Download as pdf or txt
Download as pdf or txt
You are on page 1of 54

LAB FILE

STQA Lab
(ETCS - 453)

Submitted to: Name: Disha Bhardwaj


Mrs Garima Gupta Roll No: 35396402719
CSE Dept, MAIT Semester: 7th
Group: C-13

Maharaja Agrasen Institute of technology, PSP area,


Sector – 22, Rohini, New Delhi – 110086
INDEX

Name of Experiment Date R1 R2 R3 R4 R5 Sign.


Exp
No.
1 Write a program to find whether a number is prime or
not. To determine the nature of roots of a quadratic
equation, its input is triple of +ve integers (say a,b,c)
and values may be from the interval[1,100] The
program output may have one of the following:-

● [Not Quadratic equations, Real roots,


Imaginary roots, Equal roots]
● Perform BVA (Boundary-value analysis).
● Perform Robust Case Testing

2 Write a program to determine the type of triangle. Its


input is triple of +ve integers (say x,y,z) and the values
may be from interval[1,l00].The program output may
be one of the following [Scalene, Isosceles, Equilateral,
Not a Triangle]. Perform BVA, Equivalence Class
Testing (Using Input Domain and Output domain).
Which Technique is best for the given problem
statement. Give reasons.
3 Equivalence Class Partitioning In the lecture, we used
the example of an app that classified Risk Exposure
(RE) as High, Moderate, or Low on the basis of Risk
Probability (RP) and Risk Impact (RI).
Consider the following specification for such an app:
1) the app accepts two integers, RP and RI, as input,
2) both RP and RI must be in the range [1, 5],
3) if either input is not an integer, it is invalid and the
app outputs “Invalid,
4) if either input is an integer outside the range
specified in (2), it is invalid and the app outputs “Out of
Range”,
5) given valid inputs, the app calculates RE as the
product of RP and RI, and outputs:
a. “High”, if RE is greater than 9
b. “Low” if RE is less than or equal to 2
c. “Moderate” if neither (a) nor (b) are
satisfied
i) Partition the domain of each parameter into
equivalence classes, label the classes, and list
them.
ii) Develop a set of test cases for the app to
satisfy Each Choice Coverage of the
equivalence classes. Indicate the equivalence
classes covered by each test case and, as
always, include the expected result. Notice the
actual classification process is not adequately
tested by your set of test cases.
iii) To better test the classification performed by
the app, partition the output domain and
develop additional test cases to cover any class
not covered by your test cases in (ii)

4 Develop a complete limited-entry decision table


for the following decision situation:

An airline offers only flights in Germany and


Europe. Under special conditions a discount is
offered — a discount with respect to the normal
airfare.
Rules:
• Passengers older than 18 with
destinations in Germany are offered a
discount at 20%, if the departure is not
on a Monday or Friday- If the
passengers stay at least 6 days at the
destination, an additional discount of
10% is offered.
• For destinations outside Of Germany
passengers are offered a discount Of
25%, if the departure is not on a
Monday or Friday.
• Passengers older than 2 but younger
than 18 years are offered a discount of
40% for all destinations.

• Children under 2 travel for free.


For each rule, design the test case

5 Create a test plan document for the application given in


Experiment 4

6 Study of Win Runner Testing Tool

7 Study of Test Management tool (QA Complete)

8 Automate the Test cases using Test Automation tool


(using QA Complete)

9 Learn how to raise and report Bugs using Bug tracking


tool (Bugzilla, Jira using QA Complete)

10 Study of any open source testing tool (Web


Performance Analyzer/OSTA)

11 The BSE Electrical Company charges its domestic


consumers using the following slab:

Identify the best suitable black box testing technique


and also frame the code for the above mentioned
problem statement and find the best suitable white box
testing technique.
EXPERIMENT – 1

Aim:
Write a program to find whether a number is prime or not. To determine the nature of roots of a
quadratic equation, its input is triple of +ve integers (say a,b,c) and values may be from the
interval[1,100] The program output may have one of the following:-

● [Not Quadratic equations, Real roots, Imaginary roots, Equal roots]


● Perform BVA (Boundary-value analysis).
● Perform Robust Case Testing

Theory:

BVA(Boundary value analysis)is a black box test design technique and it is used to find the
errors at boundaries of input domain rather than finding those errors in the center of input The
basic boundary value analysis technique can be generalized in two ways: by the number of
variables, and by the kinds of ranges. Generalizing the number of variables is easy: if we have a
function of n variables, we hold all but one at the nominal values, and let the remaining variable
assume the min, min+, nom, max- and max values, and repeat this for each variable. Thus for a
function of n variables, boundary value analysis yields 4n + 1 test cases.

In the above program consider the value 1(minimum), 2(just above Minimum), 50 (Nominal),
99(Just below Maximum) and 100(Maximum). Total No. of test cases will be 4*3+1=13

If a, b, and c denote the three integer in quadratic equation a(x2)+bx+c=0 then Calculate
discriminant d=(b*b)-4*a*c

● if((a<1)||(b<1)||(c<1)||(a>100)||(b>100)||(c>100)) then "Invalid input"


● if(a==0) then "Not a quadratic equation”
● if (d==0) then "Roots are equal"
● if(d<0) then "Imaginary roots"

● otherwise "Real Roots"

Robust Test Cases –


Here, we go outside the legitimate boundary, it is an extension of boundary value analysis.

Source Code:
import cmath

print("Enter the values of variable for the standard Quadratic equation ax^2 + bx + c = 0")
a = int(input("Enter Value of a: "))
b = int(input("Enter Value of b: "))
c = int(input("Enter Value of c: "))

sqrt_d = cmath.sqrt((b**2) - (4*a*c))

root1 = (-b - sqrt_d)/(2*a)


root2 = (-b + sqrt_d)/(2*a)

print('The real roots of the equation "{0}x^2 + {1}x + {2} = 0" are {3} and {4}\n'.format(a, b, c,
root1.real, root2.real))

print('The imaginary roots of the equation "{0}x^2 + {1}x + {2} = 0" are {3} and {4}'.format(a,
b, c, root1.imag, root2.imag))

Output:
Test Cases:

Boundary Value analysis: The basic idea of boundary value analysis is to use input variables at
their maximum, just above minimum, normal value, just below maximum and maximum.
In this program, we consider the value as 0 (minimum), 1(just above minimum), 50 (normal), 99
(just below maximum) and 100 (maximum).
Maximum of 4n+1 test cases

Test Input Data Expected Output Actual Output Pass/ Fail


Case ID a b c

1 1 50 50 Real Roots Real Roots Pass

2 2 50 50 Real Roots Real Roots Pass

3 50 50 50 Imaginary Roots Imaginary Roots Pass

4 99 50 50 Imaginary Roots Imaginary Roots Pass

5 100 50 50 Imaginary Roots Imaginary Roots Pass

6 50 1 50 Imaginary Roots Imaginary Roots Pass

7 50 2 50 Imaginary Roots Imaginary Roots Pass

8 50 99 50 Imaginary Roots Imaginary Roots Pass

9 50 100 50 Real and Equal Roots Real and Equal Roots Pass

10 50 50 1 Real Roots Real Roots Pass

11 59 50 2 Real Roots Real Roots Pass

12 50 50 99 Imaginary Roots Imaginary Roots Pass

13 50 50 100 Imaginary Roots Imaginary Roots Pass


Robust Testing: The term 'robust' is synonymous with strength. So robustness testing is the way
to assess the quality of a software product. It the process of verifying whether a software system
performs well under stress conditions or not.

The method of carrying out robustness testing follows a set of conventions. A set of invalid
inputs or an odd/stressful environment is set up. Sometimes it so happens that on providing
certain inputs the program may crash . It becomes significant to capture those errors and rectify it
in accordance with the requirement specifications.

Hence suitable test cases are developed to perform testing in an appropriate test environment.
Total number of test cases generated in robust testing are 6*N +1 due to min-1 , min , min+1 ,
mid , max -1 , max and max+1.

Robustness testing ensures that a software system qualifies as the end product for which it was
meant for, hence serving the right purpose. As we know that a complete software system
comprises various components, such kind of testing ensures reducing cost and time required for
efficient delivery of a software system.

So robustness testing is carried out somewhat like this- a combination of valid and invalid inputs
is passed to the system and checked for the performance . So a system is tested and validated
under different conditions.

Maximum of 6n+1 test cases


Test Input Data Expected Output Actual Output Pass/ Fail
Case Id a b c

1 0 50 50 Invalid input Invalid input Pass

2 1 50 50 Real Roots Real Roots Pass

3 2 50 50 Real Roots Real Roots Pass


4 50 50 50 Imaginary Roots Imaginary Roots Pass

5 99 50 50 Imaginary Roots Imaginary Roots Pass

6 100 50 50 Imaginary Roots Imaginary Roots Pass

7 101 50 50 Invalid input Invalid input Pass

8 50 0 50 Invalid inputs Invalid inputs Pass

9 50 1 50 Imaginary roots Imaginary roots Pass

10 50 2 50 Imaginary roots Imaginary roots Pass

11 50 99 50 Imaginary roots Imaginary roots Pass

12 50 100 50 Equal roots Equal roots Pass

13 50 101 50 Invalid inputs Invalid inputs Pass

14 50 50 0 Invalid inputs Invalid inputs Pass

15 50 50 1 Real Roots Real Roots Pass

16 50 50 2 Real Roots Real Roots Pass

17 50 50 99 Imaginary Roots Imaginary Roots Pass

18 50 50 100 Imaginary Roots Imaginary Roots Pass

19 50 50 101 Invalid Inputs Invalid inputs Pass


EXPERIMENT – 2

Aim:
To determine the type of triangle. Its input is triple of +ve integers (say x,y,z) and the values may
be from interval[1,l00].The program output may be one of the following [Scalene, Isosceles,
Equilateral, Not a Triangle]. Perform BVA, Equivalence Class Testing (Using Input Domain and
Output domain). Which Technique is best for the given problem statement. Give reasons.

Theory:
Boundary Value Analysis (BVA) is a black box software testing technique where test cases are
designed using boundary values. BVA is based on the single fault assumption, also known as
critical fault assumption which states that failures are rarely the product of two or more
simultaneous faults. Hence while designing the test cases for BVA we keep all but one variable
to the nominal value and allowing the remaining variable to take the extreme value. 

Test Case Design for BVA: 


While designing the test cases for BVA first we determine the number of input variables in the
problem. For each input variable, we then determine the range of values it can take. Then we
determine the extreme values and nominal value for each input variable. 

If any of these conditions is violated output is Not a Triangle.  


● For Equilateral Triangle all the sides are equal.
● For Isosceles Triangle exactly one pair of sides is equal.
● For Scalene Triangle all the sides are different.
The table shows the Test Cases Design for the Triangle Problem. The range value [l, r] is taken
as [1, 100] and nominal value is taken as 50.

The total test cases is, 4n+1 = 4*3+1 = 13

Source Code:

# Function definition to check validity


def is_valid_triangle(a,b,c):
    if a+b>=c and b+c>=a and c+a>=b:
        return True
    else:
        return False

# Function definition for type


def type_of_triangle(a,b,c):
    if a==b and b==c:
        print('Triangle is Equilateral.')
    elif a==b or b==c or a==c:
        print('Triangle is Isosceles.')
    else:
        print('Triangle is Scalane')

# Reading Three Sides


side_a = float(input('Enter length of side a: '))
side_b = float(input('Enter length of side b: '))
side_c = float(input('Enter length of side c: '))

# Function call & making decision


if is_valid_triangle(side_a, side_b, side_c):
    type_of_triangle(side_a, side_b, side_c)
else:
    print('Tringle is not possible from given sides.')
Output:
Test Cases:
Boundary Value analysis: The basic idea of boundary value analysis is to use input variable at
their maximum, just above minimum, normal value, just below maximum and maximum.

In this program, we consider the value as 0 (minimum), 1(just above minimum), 50 (normal), 99
(just below maximum) and 100 (maximum).

Maximum of 4n+1 test cases


Test Input Data Expected Output Actual Output Pass/ Fail
Case ID a b c

1 1 5 5 Isosceles Isosceles Pass

2 2 5 5 Isosceles Isosceles Pass

3 9 5 5 Isosceles Isosceles Pass

4 10 5 5 Not a Triangle Not a Triangle Pass

5 5 1 5 Isosceles Isosceles Pass

6 5 2 5 Isosceles Isosceles Pass

7 5 9 5 Isosceles Isosceles Pass

8 4 8 6 Scalene Scalene Pass

9 50 50 50 Equilateral Equilateral Pass

10 5 10 5 Not a Triangle Not a Triangle Pass

11 100 100 100 Equilateral Equilateral Pass

12 5 5 10 Not a Triangle Not a Triangle Pass

13 5 5 5 Equilateral Equilateral Pass


Robust Testing: The term 'robust' is synonymous with strength. So robustness testing is the way
to assess the quality of a software product. It is the process of verifying whether a software
system performs well under stress conditions or not.

Total test cases, = 6*n+1 = 6*3+1 = 19

The method of carrying out robustness testing follows a set of conventions. A set of invalid
inputs or odd/stressful environment is set up. Sometimes it so happens that on providing certain
inputs the program may crash . It becomes significant to capture those errors and rectify it in
accordance with the requirement specifications.

Hence suitable test cases are developed to perform testing in an appropriate test environment.
Total number of test cases generated in robust testing are 6*N +1 due to min-1 , min , min+1 ,
mid , max -1 , max and max+1.

So robustness testing is carried out somewhat like this- a combination of valid and invalid inputs
is passed to the system and checked for the performance . So a system is tested and validated
under different conditions.

Maximum of 6n+1 test cases


Test Input Data Expected Output Actual Output Pass/ Fail
Case Id a b c

1 0 50 50 Invalid input Invalid input Pass

2 50 50 50 Equilateral Equilateral Pass

3 5 10 5 Not a Triangle Not a Triangle Pass

4 100 100 100 Equilateral Equilateral Pass

5 5 5 10 Not a Triangle Not a Triangle Pass


6 5 5 5 Equilateral Equilateral Pass

7 101 50 50 Invalid input Invalid input Pass

8 50 0 50 Invalid inputs Invalid inputs Pass

9 5 1 5 Isosceles Isosceles Pass

10 5 2 5 Isosceles Isosceles Pass

11 5 9 5 Isosceles Isosceles Pass

12 4 8 6 Scalene Scalene Pass

13 50 101 50 Invalid inputs Invalid inputs Pass

14 50 50 0 Invalid inputs Invalid inputs Pass

15 1 5 5 Isosceles Isosceles Pass

16 2 5 5 Isosceles Isosceles Pass

17 9 5 5 Isosceles Isosceles Pass

18 10 5 5 Not a Triangle Not a Triangle Pass

19 50 50 101 Invalid Inputs Invalid inputs Pass

Result:
BVA and Robust testing was performed for given conditions and verified.
EXPERIMENT – 3
Aim:
Equivalence Class Partitioning In the lecture, we used the example of an app that classified Risk
Exposure (RE) as High, Moderate, or Low on the basis of Risk Probability (RP) and Risk Impact
(RI).
Consider the following specification for such an app:
1) the app accepts two integers, RP and RI, as input,
2) both RP and RI must be in the range [1, 5],
3) if either input is not an integer, it is invalid and the app outputs “Invalid,
4) if either input is an integer outside the range specified in (2), it is invalid and the app outputs
“Out of Range”,
5) given valid inputs, the app calculates RE as the product of RP and RI, and outputs:
a. “High”, if RE is greater than 9
b. “Low” if RE is less than or equal to 2
c. “Moderate” if neither (a) nor (b) are satisfied

iv) Partition the domain of each parameter into equivalence classes, label the classes, and list
them.
v) Develop a set of test cases for the app to satisfy Each Choice Coverage of the equivalence
classes. Indicate the equivalence classes covered by each test case and, as always, include
the expected result. Notice the actual classification process is not adequately tested by
your set of test cases.
vi) To better test the classification performed by the app, partition the output domain and
develop additional test cases to cover any class not covered by your test cases in (ii).
Theory:
Risk is the probability of a negative or undesirable outcome or event. Risk is any problem that
might occur that would decrease customer, user, stakeholder perception of quality and/or project
success. 

Types of risks:
There are 2 types of risks- Product Risk and Quality Risk.

1. Product risk-
When the Primary effect of a potential problem is on product quality, then the potential
problem is called Product risk. It can also be called a quality risk. Example- A defect that
can cause a system crash or monetary loss. 

2. Project Risk-
When the Primary effect of a potential problem is on the overall success of the
project, those potential problems are called Project risk. They can also be called Planning
risks.  Example- Staffing issues that can delay project completion.

Not all risks are equally important. There is a number of ways we can classify the level of risk.
The easiest way is to look at two factors-

1. Likelihood of occurrence of the problem. Likelihood arises from technical considerations.

2. Impact of the problem, if it occurs. Impact arises from business considerations.

What Is Risk-Based Testing? 


In risk-based testing, we use the risk items identified during risk analysis, along with the level of
risk associated with each risk item to guide the testing. It is a type of software testing technique
that is primarily based on the probability of the risk. Risk-based testing involves the following
steps:

1. Accessing the risk based on software quality.

2. Frequency of use.

3. Criticality of Business.
4. Possible areas with defects, etc.

Characteristics Of Risk-Based Testing (RBT): 


Below are some characteristics of Risk-based testing (RBT)-

1. RBT strategy matches the level of test effort to the level of risk. The higher the risk, the
more is the test effort. This applies to test execution as well as other test activities like
test designing and implementation. 

2. It matches the order of testing with the level of risk. Higher risk tests tend to find more
defects or are related to more important areas in the application or maybe both. So higher
the risk, we plan the tests earlier in the cycle- both in design and execution. This helps in
building the confidence of business stakeholders as well. 

3. By effort allocation and maintaining the order of testing, the quality risk gets
systematically and predictably reduced. By maintaining a traceability matrix of tests vs
risks and defects identified to risks, reporting the risk as residual risks make sense. This
allows the concerned stakeholders to decide when to stop testing i.e whenever the risk of
continuing testing exceeds the risk of testing completion. 

4. If schedule reduction requires scope reduction, it is easier to decide what needs to go out.
It will always be acceptable and explainable to business stakeholders as risk levels are
agreed upon.

5. To identify risks, we need to take inputs from various sources like – Requirements
specifications, design specifications, existing application data, previous incident records,
etc. However, if this information is not readily available, we can still use this approach by
getting inputs from stakeholders for the risk identification and assessment process. 

When To Implement Risk-Based Testing?


Risk-based testing approach is implemented in scenarios where- 
1. There is time/resource or budget constraints. For example- A hotfix to be deployed in
production.

2. When a proof of concept is being implemented.

3. When the team is new to the technology platform or to the application under test.

4. When testing in Incremental models or Iterative models.

5. Security testing is done in Cloud computing environments.


 

How Risk-Based Testing Is Implemented?


Risk can guide testing in multiple ways but below are the major ones –

1. The effort is allocated by test managers proportional to the risk associated with the test
item.

2. Test techniques are selected in a way that matches the rigor and extensiveness required
based on the level of risk of the test item.

3. Test activities should be carried out in reverse order of risk i.e The Highest risk item
should be tested first.

4. Prioritization and resolution of defects should be done as appropriate with the level of
risk associated. 

5. During test planning and control, test managers should carry out risk control for all
significant risk items. The higher the level of risk associated, the more thoroughly it
should be controlled.

6. Reporting should be done in terms of residual risks. Example- Which tests have not run
yet? Which defects have not fixed yet?

Benefits of Risk-Based Testing (RBT):


By identifying and analyzing the risks related to the system, it is possible to make testing
efficient and effective-
1. Efficient-
RBT is efficient because you test the most critical areas of the system early in the cycle
(the earlier the defect is detected the lower is the cost of solving those issues)

2. Effective-
RBT is effective because your time is spent according to the risk rating and mitigation
plans. You do not spend time on items and activities which might not be very important
in the overall scheme of things.

3. Reduced Test cases-


Test case count gets reduced as test cases become more focused.

4. Cost reduction-
A reduction in cost per quality as critical issues get fixed early in the cycle and hence
lowering the cost of change.

5. Faster time to market-


Faster time to market is more easily achievable with RBT approach as the most important
features are available in a shippable position early in the cycle.

Solution:
i)

RP RI Equivalence Class

RP < 1 1 <= RI <=5 Invalid

RP > 5 1 <= RI <=5 Invalid

1 <= RP <=5 RI < 1 Invalid

1 <= RP <=5 RI > 5 Invalid

Non Integer 1 <= RI <=5 Invalid

Non Integer RI < 1 Invalid

Non Integer RI > 5 Invalid


RP < 1 Non Integer Invalid

RP > 5 Non Integer Invalid

1 <= RP <=5 Non Integer Invalid

1 <= RP <=5 1 <= RI <=5 Valid

ii)

RP RI Equivalence Test Case Test Case Expected


Class RP RI Output
RP < 1 1 <= RI Invalid 0 3 Out of Range
<=5
RP > 5 1 <= RI Invalid 7 2 Out of Range
<=5
1 <= RP RI < 1 Invalid 3 -1 Out of Range
<=5
1 <= RP RI > 5 Invalid 4 23 Out of Range
<=5
Non Integer 1 <= RI Invalid 23.4 3 Invalid
<=5
Non Integer RI < 1 Invalid a 0 Invalid

Non Integer RI > 5 Invalid Hello 17 Invalid

RP < 1 Non Invalid -45 3.2 Invalid


Integer
RP > 5 Non Invalid 60 xyz Invalid
Integer
1 <= RP Non Invalid 2 * Invalid
<=5 Integer
1 <= RP 1 <= RI Valid 2 3 Moderate
<=5 <=5
iii)

Test Case RP Test Case RI Expected Output


4 3 High
1 1 Low
3 2 Moderate

Result:
Problems based on the given conditions were solved and verified.
EXPERIMENT – 4
Aim:
Develop a complete limited-entry decision table for the following decision situation:

An airline offers only flights in Germany and Europe. Under special conditions a discount is
offered — a discount with respect to the normal airfare.

Rules:

• Passengers older than 18 with destinations in Germany are offered a discount at


20%, if the departure is not on a Monday or Friday- If the passengers stay at least
6 days at the destination, an additional discount of 10% is offered.

• For destinations outside Of Germany passengers are offered a discount Of 25%, if


the departure is not on a Monday or Friday.

• Passengers older than 2 but younger than 18 years are offered a discount of 40%
for all destinations.

• Children under 2 travel for free.

For each rule, design the test case

Theory:
A decision table is a brief visual representation for specifying which actions to perform
depending on given conditions. The information represented in decision tables can also be
represented as decision trees or in a programming language using if-then-else and switch-case
statements. 

A decision table is a good way to settle with different combination inputs with their
corresponding outputs and is also called a cause-effect table. The reason to call cause-effect table
is a related logical diagramming technique called cause-effect graphing that is basically used to
obtain the decision table. 

Importance of Decision Table:

● Decision tables are very much helpful in test design techniques.


● It helps testers to search the effects of combinations of different inputs and other software
states that must correctly implement business rules.

● It provides a regular way of starting complex business rules, that is helpful for developers
as well as for testers.

● It assists in the development process with the developer to do a better job. Testing with
all combinations might be impractical.

● A decision table is basically an outstanding technique used in both testing and


requirements management.

● It is a structured exercise to prepare requirements when dealing with complex business


rules.

● It is also used in model complicated logic.

Advantages of Decision Table: 

● Any complex business flow can be easily converted into test scenarios & test cases using
this technique.

● Decision tables work iteratively which means the table created at the first iteration is used
as input tables for the next tables. The iteration is done only if the initial table is not
satisfactory.

● Simple to understand and everyone can use this method to design the test scenarios & test
cases.

● It provides complete coverage of test cases which helps to reduce the rework on writing
test scenarios & test cases.

● These tables guarantee that we consider every possible combination of condition values.
This is known as its completeness property.

Solution:
Airline Passenger Discount Policy
An airline offers only flights to India and Asia. Under special conditions, a discount is offered on
the normal airfare:

o Passengers older than 18 with destinations in India are offered a discount of 20%, as long
as the departure is not on a Monday or Friday.

o For destinations outside of India, passengers are offered a discount of 25%, if the
departure is not on a Monday or Friday.

o Passengers who stay at least 6 days at their destination receive an additional discount of
10%.

o Passengers older than 2 but younger than 18 years are offered a discount of 40% for all
destinations.

o Children 2 and under travel for free.

Extracting Rules
Conditions:
o Destination (India, Asia)
o Passenger Age (<= 2, > 2 && < 18, > 18
o Depart on Monday or Friday (Yes, No)
o Stay 6 days or more (Yes, No)
Actions:
o Travel Free
o 0% discount
o 10% discount
o 20% discount
o 40% discount
Number of rules: 2 values * 3 values * 2 values * 2 values = 24 rules
Scenarios
Reduced Table

Decision Table:

Destination Age IsWeekDay MoreThan6 Discount

Rule 1 Group1 100

Rule 2 India Group2 Y 40

Rule 3 India Group2 N 50

Rule 4 Group3 Y N 0

Rule 5 Group3 Y Y 10

Rule 6 India Group3 N Y 30

Rule 7 India Group3 N N 20

Rule 8 Asia Group2 Y Y 50


Rule 9 Asia Group2 Y N 40

Rule 10 Asia Group2 N Y 75

Rule 11 Asia Group2 N N 65

Rule 12 Asia Group3 N Y 35

Rule 13 Asia Group3 N N 25

Result:
For each rule test-case was designed and verified.
EXPERIMENT – 5
Aim:

Create a test plan document for the application given in Experiment 4.

Theory:

TEST PLAN DOCUMENT

A Test Plan is a detailed document that describes the test strategy, objectives, schedule,
estimation, deliverables, and resources required to perform testing for a software product. Test
Plan helps us determine the effort needed to validate the quality of the application under test. The
test plan serves as a blueprint to conduct software testing activities as a defined process, which is
minutely monitored and controlled by the test manager.

Table of Contents :
1) Introduction
2) Purpose
3) Scope
4) Testing Strategies
4.1. Unit testing
4.2 System & Integration texting
4.3. Performance testing & Stress testing
4.4. Acceptance Testing
5) features to be listed
6) Hardware requirements
7) Environment requirements
8) Test schedule
9) Risk & Mitigation
10) Tools

1. Introduction
Aviation provides the only rapid worldwide transportation network, generating economic growth,
creating jobs, and facilitating international trade and tourism. Therefore with such increasing
number it is important to provide different offers to customers to cater the need of all the age
groups.

2. Purpose
The aviation discount management tool is an online application for managing discounts and
ticket activities to various age groups. This test plan document support the following objective :

● Identify the user’s age and offer discount according to the availability
● List the recommended tools requirements.
● Recommend and describe the testing strategies to be employed.
● List the deliverable elements of the test activities.
3. Scope
The system that is to developed provides the related information on customers and system
administration
● Creating a system administrator who will be the sole user managing the system on the
backend.
● System admin can add/ delete/view/ edit the discount details
● Admin can add/delete/view/edit the tickets issued as well as discounts.
● Admin can search for the tickets issued.

4. Testing Strategies
The aim of the system testing process is to determine all the defects in the project.

4.1 Unit Testing :


In order to test a single module, we need to provide a complete environment and besides the
module we could require
● The procedure belongs to other modules.
● Non local data structures that module accesses.
● A procedure to call the functions of the module for testing.
Unit testing was done on each of every modules that it describes under the module description :
1) Test for admin module:
● Testing admin for login
● Check admin for accessibility of tickets and discount
2) Test for user module :
● Test for user login interface
● Test for account creation
● Test for available discounts
● Allocation of discounts to users based on age and days

4.2 System of integration testing :


The primary objective is to test the module interfaces
● UI user interface module, w/c is visible to end user
● DBMS is the database management system w/c has all data
● VAL is the validation module
● CNT : these contents are displayed in reports.
4.3 Performance of stress testing
Stress testing involving beyond normal operational capacity
4.4 User Acceptance Testing
There are different types of acceptance testing . The most common among them is the user
acceptance (UA)
Test Schedule

S.NO Task Days Start End Time Responsibility


Time

1. Understanding and 5 2 July 7 July Team


Analysis

2. Generating Test Cases 10 7 July 17 July Member 1

3. Test Case Documentation 40 17 July 17 Aug Member 2

4. Verifying env. steps 1 17 Aug 17 Aug Member 3

5. Unit Testing 10 18 Aug 28 Aug Member 4


6. IVT Testing 15 7 Sept 22 Sept Member 5

7. Final Testing 15 21 Sept 24 Sept End User 1

8. Eval. Test Criteria 2 22 Sept 24 Sept Member 1

9. Summary Report 1 25 Sept 25 Sept Team

5) Features to be tested
● GUI testing
● Database testing
● Basic operations add/delete/etc
● Advance operations
● BIU
6) Hardware requirements / Software requirements
● Windows -OS
● Python language
● MySQL database
● Visual studio code - IDE
7) Environment requirement
● Mainframe- Specify both the necessary and designed properties of test acquirement
● Workstations - computers provided in the libraries to be used by admins and students.
8) Risk and mitigation
Keep battery back up and avoid electricity issues
9) Tools
● Selenium
● 2 pp
Result: Successfully prepared a test plan for an aviation system.
EXPERIMENT – 6

Aim:
Study of Win Runner Testing Tool
Theory:
Win Runner is the most used Automated Software Testing Tool.
The main Features of Win Runner are
1. Developed by Mercury Interactive
2. Functionality testing tool
3. Supports C/s and web technologies such as (VB, VC++, D2K, Java, HTML,
Power Builder, Delphe, Cibell (ERP))
4. To Support .net, xml, SAP, Peoplesoft, Oracle applications, Multimedia we can use
QTP.
5. Winrunner runs on Windows only.
6. Xrunner runs only UNIX and Linux.
7. Tool developed in C on VC++ environment.
8. To automate our manual test win runner used TSL (Test Script language)
● The main Testing Process in Win Runner is
1) Learning
Recognition of objects and windows in our application by WinRunner is called learning.

Winrunner 7.0 follows Auto learning.

2) Recording

Winrunner records over the manual business operation in TSL

3) Edit Script

Depending on the corresponding manual test, the test engineer inserts checkpoints into that
record script.

4) Run Script
During test script execution, WinRunner compares tester given expected values and application
actual values and returns results.

5) Analyze Results

Tester analyzes the tool given results to concentrate on defect tracking if required.

Recording Test Cases


To test any application, first, you can run the application and understand its operation. Then, you
can invoke WinRunner, again run the application and record the GUI operations. During the
recording mode, WinRunner will capture all your actions, which button you pressed, where you
clicked the mouse etc. You need to work with the application as usual and perform all the action
to be tested. Once the recording is completed, WinRunner generates a script in TSL (Test Script
Language). You can run this test script generated by WinRunner to view the results. The test
results will show whether the test has passed or failed.

There are two modes of recording:


Context-Sensitive mode: This mode of recording is used when the location of the GUI controls
(i.e. X and Y coordinates) or the mouse positions are not necessary. Analog mode: This mode of
recording is used when the mouse positions, the location of the controls in the application, also
play an important role in testing the application. This mode of recording has to be used to
validate bitmaps, test the signature etc.

The procedure for recording a test case is as follows:

Step 1: Open a new document: File -> New (or) Select "New Test"

from the WinRunner's Welcome screen.

Step 2: Open (run) the application to be tested.

Step 3: Start recording a test case.


Create ->Record - Context Sensitive (or) click on the toolbar's "Record" button once, to record in
Context Sensitive mode.

Step 4: Select the application to be tested by clicking on the application's title bar.

Step 5: Perform all the actions to be recorded .

Step 6: Once all required actions are recorded, stop the recording.

Create -> Stop (or) Click on the toolbar's "Stop" button to stop the recording WinRunner
generates the script for the recorded actions

There are two modes for generating the test cases: "Global GUI map file mode" and "GUI map
file per test mode". By default, it is in "Global GUI map file mode".

In Global GUI map file mode, you have to explicitly save the information learnt by WinRunner.
WinRunner saves it in a file with the extension "gui". When you have to run a test, you need to
load the corresponding GUI map file; otherwise, it will not be able to recognize the objects in the
test case and display an error message. In GUI map file per test mode, WinRunner automatically
saves the information it has learnt from the application. It is always preferred to work in Global
GUI map file mode.
EXPERIMENT – 7
Aim:
Study of Test Management tool (QA Complete)

Theory:
QA Complete is a Test management tool that can be used for both manual and Automated
Testing. It is a tool with powerful test management capabilities that allow us to track all aspects
of software quality in an efficient manner. QA Complete supports all aspects of the test process
and ensures the delivery of high-quality software.

Benefits:

QA Complete can be integrated with any number of tools Customizable as per the tester’s needs
Requirements and tests can be traced to defect effectively Reports and Dashboards are the key
features of QA Complete.

Features:

Test Case Management – Simple Test Case structuring also allows for focused metrics and clear
status report

● Test Environment Management – Various environments are linked to individual test cases for
effective Test Coverage across different platforms, operating systems, and devices

● Defect and Issue Management – Mainly tracks the resolution process of bugs for

each release and automatically creates bugs when test cases fail.
● Test Automation Integration – This can be integrated with various automation tools, and it
allows us to track and report overall (manual and automated) Test Management efforts

at a single place
● Bug Tracker Integration – Can be integrated with various Bug tracking tools
● Shared Documents – Stores all test documents in one central location to improve
collaboration
Steps to Setup and Work on the QA Complete
To manage and produce the right test deliverables, let us assume an E-Work Sight Login Page
needs to be tested manually. The following steps and screenshots will explain how we can
manage the Test Deliverables using QA Complete Test Management Tool.

Step 1: Log into QA Complete Tool

Step 2: Create a New Release as E-Work under the Release tab by clicking the Add New icon
and click the Add New Item to add an Iteration/Build

Step 3: Navigate to the Test Management Tab -> Test Library -> Add New folder
Step 4: Navigate to Test Management Tab -> Test Sets -> Create a folder (Add the ‘+’ @ left
panel) -> Create a new test set using the Add New icon -> After entering the details click the
Submit button -> Navigate to the Tests Tab and Design the steps accordingly

Step 5: To run the Test Sets -> Test Management Tool -> Test Sets -> Click the RUN icon

Step 6: Click the Start Run at the top right corner. Based on the working functionality, select the
Run Status and click the End Run option finally.
A

Step 7: If any of the steps fail in a Test Set during the run, it prompts to create a defect
automatically

Step 8: When the YES option is selected, a defect is created automatically


Step 9: Navigate to the Defects Tab and view the automatically created bug(s).
EXPERIMENT – 8
Aim:
Automate the Test cases using Test Automation tool (using QA Complete)

Theory:
Automations allow you to run tests without user interaction on remote computers. You can
perform such tests as often as needed, for example, after a successful build or on a daily basis.
Integrate QAComplete tests with various testing tools to track results using the features provided
by the Test Library. You can automatically run necessary tests and collect results for full tracking
of your testing coverage and progress.

How the test automation works


The test automation mechanism in QAComplete works in the following way:

1. In your automated testing tool, you create tests that will perform the needed actions to
test your application or feature.
2. You pack the automated test files into a .zip archive. These can be stored in a shared
network folder or on a separate website.

Note: It is also possible to attach files directly to the test item in the Test Library.

3. You install and configure the Test Agent on the computers that you will use to preform

automated tests.

4. You associate the automated tests with tests in the Test Library.
5. (Optional) You create schedules to run tests at the time specified.
6. During the scheduled run time or when you request the test to run, the Test Agent
performs the following actions on the host:

○ Connecting to the QAComplete web service;

○ Fetching the automated test files;

○ Launching the testing tool on the host;

○ Performing the test.


7. Tip: You can configure the Test Agent to log out of Windows while closing any open
applications, then log back in with the specific credentials. It is also possible to check if a
user on the host machine is currently logged in to avoid the logout routine.
EXPERIMENT – 9
Aim:
Learn how to raise and report Bugs using Bug tracking tool (Bugzilla, Jira using QA Complete)

Theory:
What is Bugzilla?
Bugzilla is an open-source issue/bug tracking system that allows developers to keep track of
outstanding problems with their products. It is written in Perl and uses the MYSQL database.
Bugzilla is a Defect tracking tool, however, it can be used as a test management tool as such it
can be easily linked with other Test Case management tools like Quality Center, Testlink etc.
This open bug-tracker enables users to stay connected with their clients or employees, to
communicate about problems effectively throughout the data-management chain.

Key features of Bugzilla includes


● Advanced search capabilities
● E-mail Notifications
● Modify/file Bugs by e-mail
● Time tracking
● Strong security
● Customization
● Localization

How to log in to Bugzilla


Step 1) Use the following link for your handons. To create an account in the Bugzilla tool or to
login into the existing account go to New Account or Login option in the main menu.
Step 2) Now, enter your personal details to log into Bugzilla
Password
And then click on “Log in”

Step 3) You are successfully logged into the Bugzilla system

Creating a Bug-report in Bugzilla


Step 1) To create a new bug in Bugzilla, visit the home page of Bugzilla and click on a NEW tab
from the main menu
Step 2) In the next window
Enter Product
Enter Component
Give Component description
Select version,
Select severity
Select Hardware
Select OS
Enter Summary
Enter Description
Attach Attachment
Submit
NOTE: The above fields will vary as per your customization of Bugzilla

NOTE: The mandatory fields are marked with *.


In our case field’s
Summary
Description
Are mandatory
If you do not fill them you will get a screen like below
Step 4) Bug is created ID# 26320 is assigned to our Bug. You can also add additional
information to the assigned bug-like URL, keywords, whiteboard, tags, etc. This extra
information is helpful to give more detail about the Bug you have create.

Large text box


URL
Whiteboard
Keywords
Tags
Depends on
Blocks
Attachments

Step 5) In the same window if you scroll down further. You can select the deadline date and also

the status of the bug. The deadline in Bugzilla usually gives the time limit to resolve the bug in

the given time frame.


Create Graphical Reports
Graphical reports are one way to view the current state of the bug database. You can run reports
either through an HTML table or graphical line/pie/bar-chart-based one. The idea behind the
graphical report in Bugzilla is to define a set of bugs using the standard search interface and then
choose some aspect of that set to plot on the horizontal and vertical axes. You can also get a
3-dimensional report by choosing the option of “Multiple Pages”.

Reports are helpful in many ways, for instance, if you want to know which component has the
largest number of bad bugs reported against it. In order to represent that in the graph, you can
select severity on X-axis and component on Y-axis and then click on generate a report. It will
generate a report with crucial information.

The graph below shows the Bar chart representation for the Bugs severity in component “Widget
Gears”. In the graph below, the most severe bug or blockers in components are 88 while bugs
with normal severity are at the top with 667 numbers.
EXPERIMENT – 10

AIM
Study of any open source testing tool (Web Performance Analyzer/OSTA)

THEORY
The performance of web applications can affect business. Top engineering organizations consider
performance not as nice-to-have, but as a crucial feature of their products. Unfortunately, most
engineering teams do not regularly test the performance and scalability of their infrastructure,
and most lack the tools to properly do so. Although plenty of commercial tool options out there,
for the right organization, free and open source tools may be a good alternative or the perfect
complement to a commercial tool set.

The goal of performance testing is to understand how your applications behave under heavy load
conditions. To get started, you need to understand the baseline performance of your application
and that the performance of each transaction is unique. For example, in an ecommerce
application, a home page transaction is likely highly cached and very fast, whereas a checkout
transaction is more complicated and must talk to a payment service, shipping service, etc. To
ensure that users have a great experience, you must test the most common flows for your users
and understand performance both in the browser and on the server.To get the job done, we’ll
need server-side, client-side, and performance tools.

Open STA (Open System Testing Architecture)


Open STA is the abbreviation for Open System Testing Architecture and it is built around
COBRA. This GUI based testing tool is used by testers for load analyzing and load testing. This
is a complex testing tools and is known to perform heavy test load for scripted HTTP and
HTTPS. Here, the tests are performed using simple scripts, recordings and it also takes into
account various results and statistics. During load tests, Open STA graphs resource utilization
information from application servers, web servers, operating platforms and database servers that
help in further analysis.
WAPT(Web Application Performance Tool) :

This web performance testing tool can be used for intranet applications and websites. WAPT is
short for Web Application Performance Tool, and it acts as a scale or analyzing tool for
measuring the output and performance of a web application and related interface. The tools help
measure the performance of any web-related interface, web service or web application. You can
use this tool to test the application performance in different environments and load conditions.
The tool provides detailed information on the virtual users and its output to the users during load
testing. It is considered by many to be one of the best and most costeffective tools for analyzing
the performance of web services. The WAPT tool can also test the compatibility of a web
application with operating systems and browsers. It can be used for testing the compatibility with
Windows applications in certain cases. However, the tool only works on Windows operating
systems.
Experiment 11
AIM : The BSE Electrical Company charges its domestic consumers using the following slab:

Identify the best suitable black box testing technique and also frame the code for the above
mentioned problem statement and find the best suitable white box testing technique.

THEORY:
Black Box Testing Technique Black box testing is a type of testing that does not require
knowledge of the internal workings of the code being tested. Instead, it focuses on the inputs and
outputs of the code, and determines whether the outputs are correct for a given set of inputs.
Some suitable black box testing techniques for the above problem statement might include:

● Equivalence partitioning: This technique divides the input data into "equivalence partitions,"
or groups of data that are expected to behave in the same way. For example, in the BSE
Electrical Company case, we might create an equivalence partition for consumers who use less
than 100 units of electricity per month, another partition for consumers who use between 100 and
200 units per month, and so on. We can then test the code using representative samples from
each partition to ensure that it is correct for all consumers within that partition.

● Boundary value analysis: This technique tests the code using input values that are at the
minimum and maximum boundaries of the expected input range. For example, in the BSE
Electrical Company case, we might test the code using input values of 0 units, 100 units, 199
units, and 200 units to ensure that it is correct at the minimum and maximum boundaries of the
input range.
White Box Testing Techniques

White Box Testing is a testing technique in which software’s internal structure, design, and
coding are tested to verify input-output flow and improve design, usability, and security. In this
we analyze the internal structures, the used data structures, internal design, code structure, and
the working of the software rather than just the functionality as in the case of black box testing.

In white box testing, the code is visible to testers, so it is also called Clear box testing, open box
testing, transparent box testing, Code-based testing, and Glass box testing.
Some suitable White Box testing techniques for the above problem might include:

Branch coverage technique is used to cover all branches of the control flow graph. It covers all
the possible outcomes (true and false) of each condition of decision point at least once. Branch
coverage technique is a white box testing technique that ensures that every branch of each
decision point must be executed.
Basis Path Testing is a white-box testing technique based on the control structure of a program
or a module. Using this structure, a control flow graph is prepared and the various possible paths
present in the graph are executed as a part of testing.
Condition coverage testing is a type of white-box testing that tests all the conditional
expressions in a program for all possible outcomes of the conditions. It is also called predicate
coverage.

Here is some example code for the BSE Electrical Company case: This code calculates the bill
for a domestic consumer based on the number of units of electricity they have used. The bill is
calculated using the following slab:

#include <iostream>
using namespace std;
int main()
{
int consumptionUnit = 0;
cout<<"Enter consumption unit: ";
cin>>consumptionUnit;
if(consumptionUnit >= 0) {
float cost = 0;
if(consumptionUnit <= 150)
cost = consumptionUnit*2;
else if(consumptionUnit <= 300)
cost = 200 + (consumptionUnit-150)*3;
else if(consumptionUnit <= 400)
cost = 300 + (consumptionUnit-300)*3.9;
else
cost = 350 + (consumptionUnit-400)*4.4;
cout<<"Energy charges: "<<cost;
}
else cout<<"Invalid Consumption!!!";
return 0;
}

OUTPUT

You might also like