HMR

Institute of Technology and Management

Software Testing and Quality Assurance Lab

ETCS – 453

2019-2023

Submitted to: Submitted By:

Mr. Faisal Rais Harsh Garg
35396502719
CSE – 7 C
 INDEX

S. No. Experiment Date Signature

1 Experiment-1: 21/09/2022
Introduction to software testing

2 Experiment-2: 28/09/2022
Write a program to determine the type of triangle,
its
input is triple positive integers (say a, b, c) and
the values may be from
the interval [1,100]. The program output may
be one of the following
[Scalene, Isosceles, Equilateral, not a triangle].

A) Perform BVA.
B) Perform worst-case testing.
3 Experiment-3: 12/10/2022
Write a program to find the roots of the quadratic
equation, its input is triple positive integers (say
a, b, c) and the values may be from the interval
[1,100] and perform BVA & ROBUST
TESTING.
4 Experiment-4: 19/10/2022
Write a program to find the largest among three
numbers, its input is triple positive integers (say
a, b, c) and the values may be from the interval
[1,100] and perform BVA & ROBUST
TESTING
5 Experiment-5: 02/11/2022
WAP in C/C++ to find the area of a circle,
Triangle, Square and Rectangle and perform
equivalence class testing.
6 Experiment-6: 09/11/2022
WAP in C/C++ to compute 3 sides of a triangle
and to determine whether they form scalene,
isosceles, or equilateral triangle and perform
Cause effect testing, Decision table-based testing
and Equivalence Class testing
7 Experiment-7: 16/11/2022
Write a program in C/C++ to compute ab
and perform its decision tablebased testing

8 Experiment-8: 23/11/2022
WAP in C/C++ to compute previous
date, given the present date as input
and perform decision table-based
testing

9 Experiment-9: 07/12/2022
Create a test plan document for any
application (e.g. Library Management
System).

10 Experiment-10: 14/12/2022
Study of any open source testing tool(Open
STA)

11 Experiment-11: 21/12/2022
Study of any Test Management Tool(QA
Complete)

12 Experiment-12: 28/12/2022
Automated the Test cases using Test
Automation Tool(Using QA Complete)
 EXPERIMENT 1

Aim: Introduction to software testing

Introduction
Software Testing is the process of identifying the accuracy and quality
of the software product and service under test. Software testing is
nothing but an art of investigating software to ensure that its quality
under test is in line with the requirement of the client. Software testing
is carried out in a systematic manner with the intent of finding defects
in a system. It is required for evaluating the system.

Process of software testing:

●Step-1: Assess Development Plan and Status –
During this step, testers challenge completeness and correctness of
event plan. Based on extensiveness and completeness of Project Plan
testers can estimate quantity of resources they’re going to get to test
implemented software solution.
●Step-2: Develop the Test Plan –
Forming plan for testing will follow an equivalent pattern as any
software planning process.
●Step-3: Test Software Requirements –Testers, through verification,
must determine that requirements are accurate, complete, and they do
not conflict with another.
●Step-4: Test Software Design –The testers are concerned that planning
will achieve objectives of wants, also because design being effective
and efficient on designated hardware.
●Step-5: Build Phase Testing –The method chosen to build software
from internal design document will determine type and extensiveness
of testers needed. As the construction becomes more automated, less
testing are going to be required during this phase.
●Step-6: Execute and Record Result –This involves testing of code
during dynamic state. The approach, methods, and tools laid out in test
plan are going to be wont to validate that executable code actually
meets stated software requirements, and therefore the structural
specifications of design.
●Step-7: Acceptance Test –
Acceptance testing enables users to gauge applicability and usefulness
of software in performing their day-to-day job functions.
●Step-8: Report Test Results –
Test reporting is continuous process. It may be both oral and written. It
is important that defects and concerns be reported to the appropriate
parties as early as possible, so that corrections can be made at the lowest
possible cost.
●Step-9: The Software Installation –
Once test team has confirmed that software is prepared for production
use, power to execute that software during production environment
should be tested. This tests interface to operating software, related
software, and operating procedures.
●Step-10: Test Software Changes –
Whenever requirements change, test plan must change, and impact of
that change on software systems must be tested and evaluate.
●Step-11: Evaluate Test Effectiveness –
Testing improvement can best be achieved by evaluating effectiveness
of testing at top of every software test assignment.
Why should we do test
1.Helps in saving money:
The testing of software has a wide array of benefits. The cost-
effectiveness of the project happens to be one of the top reasons why
companies go for software testing Services

2.Security:
It is another crucial point because software testing should not be taken
into consideration. Personal details of the user can be safe. Users can
receive products that are free from vulnerability with the aid of
software testing.

3.Quality of the product:

For ensuring that the specific product comes to life, it should work in
accordance with the following.

4.Enhancing the development process:

With the aid of Quality Assurance, you can find a wide array of
scenarios and errors, for the reproduction of the error

5.Easy while adding new features:

As a new developer, changing older parts of your codebase can be
terrifying, but with tests, you’ll at least know if you’ve broken anything
important. This helps in making your software stand ahead in the
market, and beat the competition.
Levels of testing
Software testing process has 4 levels and each level has a specific
purpose:
●Unit testing
●Integration testing
●System testing
●Acceptance testing

1.Unit Testing: Unit testing is a level of the software testing process

where individual units of software are tested. A unit (also sometimes
called component) is the smallest functional part of a program or
application. The unit cannot function on its own and requires to be in
combination with other units.

2.Integration Testing: Integration testing is the next level after unit

testing. This is a stage of the software testing process where a group of
interacting modules is tested together. The purpose of integration
testing is to ensure that the modules function successfully in
conjunction with each other.

3.System Testing: System testing is a level of the software testing

process where the application is tested as a whole. At this stage, the
entirety of the code is tested in an environment similar to the one where
the finished program will be deployed. The goal at this level is to
evaluate whether the system has complied with all of the requirements
specified at the start of the development. There are two approaches to
system testing:
●Requirements based - for each one of the requirements, test cases are
written to verify that this requirement is met.
●Use case based - it takes as a foundation the scenarios and patterns of
how end-users will interact with the finished product. For each specific
use case, one or more scenarios can be defined. Test cases are written
for each of these scripts to be tested.

4.Acceptance Testing: Acceptance testing is a formal testing process

that checks the compliance of the system with the requirements and is
conducted with the aim of:
●determining whether or not the system meets the acceptance criteria;
●deciding whether or not the needs of the end-user, the client and/or
the product owner are satisfied.

Limitation of testing
●Exhaustive (total) testing is impossible in present scenario.
●Time and budget constraints normally require very careful planning
of the testing effort.
●Compromise between thoroughness and budget.
●Test results are used to make business decisions for release dates.
●Even if you do find the last bug, you’ll never know it
●You will run out of time before you run out of test cases
●You cannot test every path
●You cannot test every valid input
●You cannot test every invalid input
Quality assurance and quality factor:
Quality Assurance is also known as QA Testing. QA is defined as an
activity to ensure that an organization is providing the best product or
service to the customers. Quality Assurance is a systematic way of
creating an environment to ensure that the software product being
developed meets the quality requirements. This process is controlled
and determined at the managerial level. It is a preventive process whose
aim is to establish the correct methodology and standard to provide a
quality environment to the product being developed. Quality Assurance
focuses on process standard, projects audit, and procedures for
development. QA is also known as a set of activities designed to
evaluate the process by which products are manufactured.

Quality factors are:

1.Functionality
Quality of software is defined as how effectively the software interacts
with other components of the system. The software must provide
appropriate functions as per requirement, and these functions must be
implemented correctly.

2.Reliability
It is defined as the capability of the software to perform under specific
conditions for a specified duration.

3.Usability
Usability of software is defined as its ease of use. Quality of the
software is also identified as how easily a user can understand the
functions of the software and how much efforts are required to follow
the features.
4.Efficiency
The efficiency of the software is dependent on the architecture and
coding practice followed during development.

5.Maintainability
Maintainability is also one of the significant factors to define the
quality of the software. It refers to identify the fault and fix in the
software. It should be stable when the changes are made.

6.Portability
Portability of the software, defined as how easily a system adapts to
changes in the specifications. Quality of the software is also determined
by the portability of the system how easy it is to install the software and
how easy it is to replace a component of the order in a given
environment.

Models of quality management and its core component

Following are the various models of total quality management:
▪Deming Application Prize
▪Malcolm Baldrige Criteria for Performance Excellence
▪European Foundation for Quality Management, and
▪ISO quality management standards

9 Core Elements of a Quality Management System

1.Quality Objectives-The creation of quality objectives is a common
requirement of QMS standards, including ISO 9001. These objectives
are designed to encourage organizations to define strategic goals and a
purpose for the QMS.
2.Quality Manual-A quality manual is defined as the first
documentation of a QMS. It states the motivation for adopting a QMS
framework and the role of quality within the organization. ISO 9000
requirements for a quality manual prescribe that this document should:
● Describe the scope of the QMS
● Detail the requirements of the QMS standard or framework
● List any elements of the QMS which are excluded from the
implementation

3.Organizational Structure and Responsibilities-A QMS should include

a clear and updated model of the organization's structure and
responsibilities of all individuals within the organization.
Documentation of structure and responsibilities should include visual
guides such as flowcharts and clear documentation.

4.Data Management-Data is at the core of modern approaches to total

quality management. Data quality and availability are critical to the
success of a QMS framework to drive continuous improvement and
preventative quality control activities.

5.Processes-QMS are inherently process-driven approaches to quality

control and assurance. Standards for quality management require
organizations to identify and define all organizational processes which
use any resource to transform inputs into outputs.

6.Customer Satisfaction with Product Quality-A core component of

QMS is the requirement for organizations to monitor customer
satisfaction to determine if quality objectives are achieved.
7.Continuous Improvement
Continuous improvement and adaptation are necessary for
organizations to drive benefits with the QMS and maintain customer
satisfaction. QMS dictate that continual improvement is an
organization-wide responsibility.

8.Quality Instruments
The control and calibration of tools used to measure quality are integral
to the success of a QMS. The QMS system design within an
organization should dictate a clear policy for the maintenance of quality
instruments based on nationally or internationally recognized standards
for each piece of quality equipment.

9.Document Control
The definition of a document in a quality-driven organization is broad,
according to ISO. It includes all records of:

●Communications
●Evidence
●QMS Conformity
●Knowledge Sharing
 EXPERIMENT 2

Aim: Write a program to determine the type of triangle, its input is

triple positive integers (say a, b, c) and the values may be from the
interval [1,100]. The program output may be one of the following
[Scalene, Isosceles, Equilateral, not a triangle].
A) Perform BVA.
B) Perform Worst-Case Testing

Perform BVA CODE:

#include<conio.h> #include<stdio.h>
void main()
{
int a,b,c,result;
printf("\n\tEnter the values of a, b and c : = "); scanf("\t%d %d %d",
&a,&b,&c); if(((a+b)>c)&&((b+c)>a)&&((c+a)>b))
{
if((a==b)&&(b==c))
printf("\n\t It is an Equilatral Triangle"); else
if((a==b)||(b==c)||(c==a))
printf("\n\t It is an isosceles Triangle"); else
printf("\n\t It is a Scalene Triangle");
}
else
printf("\n\t not a triangle"); getch();
}
Output:

Boundary Value Test

Case X Y Z Expected output

1 50 50 1 Isosceles

2 50 50 2 Isosceles

3 50 50 50 Equilateral

4 50 50 99 Isosceles
5 50 50 100 Not a triangle

6 50 1 50 Isosceles

7 50 2 50 Isosceles

8 50 99 50 Isosceles

9 50 100 50 Not a triangle

10 1 50 50 Isosceles

11 2 50 50 Isosceles

12 99 50 50 Isosceles

13 100 50 50 Not a triangle

Perform Worst-Case Testing

Worst case test cases (75 out of 125 cases)
Case X Y Z Expected output
1 1 1 1 Equilateral
2 1 1 2 Not a triangle
3 1 1 50 Not a triangle
4 1 1 99 Not a triangle
5 1 1 100 Not a triangle
6 1 2 1 Not a triangle
7 1 2 2 Isosceles
8 1 2 50 Not a triangle
9 1 2 99 Not a triangle
10 1 2 100 Not a triangle
11 1 50 1 Not a triangle
12 1 50 2 Not a triangle
13 1 50 50 Isosceles
14 1 50 99 Not a triangle
15 1 50 100 Not a triangle
16 1 99 1 Not a triangle
17 1 99 2 Not a triangle
18 1 99 50 Not a triangle
19 1 99 99 Isosceles
20 1 99 100 Not a triangle
21 1 100 1 Not a triangle
22 1 100 2 Not a triangle
23 1 100 50 Not a triangle
24 1 100 99 Not a triangle
25 1 100 100 Isosceles
26 2 1 1 Not a triangle
27 2 1 2 Isosceles
28 2 1 50 Not a triangle
29 2 1 99 Not a triangle
30 2 1 100 Not a triangle
31 2 2 1 Isosceles
32 2 2 2 Equilateral
33 2 2 50 Not a triangle
34 2 2 99 Not a triangle
35 2 2 100 Not a triangle
36 2 50 1 Not a triangle
37 2 50 2 Not a triangle
38 2 50 50 Isosceles
39 2 50 99 Not a triangle
40 2 50 100 Not a triangle
41 2 99 1 Not a triangle
42 2 99 2 Not a triangle
43 2 99 50 Not a triangle
44 2 99 99 Isosceles
45 2 99 100 Scalene
46 2 100 1 Not a triangle
47 2 100 2 Not a triangle
48 2 100 50 Not a triangle
49 2 100 99 Scalene
50 2 100 100 Isosceles
51 50 1 1 Not a triangle
52 50 1 2 Not a triangle
53 50 1 50 Isosceles
54 50 1 99 Not a triangle
55 50 1 100 Not a triangle
56 50 2 1 Not a triangle
57 50 2 2 Not a triangle
58 50 2 50 Isosceles
59 50 2 99 Not a triangle
60 50 2 100 Not a triangle
61 50 50 1 Isosceles
 62 50 50 2 Isosceles
63 50 50 50 Equilateral
64 50 50 99 Isosceles
65 50 50 100 Not a triangle
66 50 99 1 Not a triangle
67 50 99 2 Not a triangle
68 50 99 50 Isosceles
69 50 99 99 Isosceles
70 50 99 100 Scalene
71 50 100 1 Not a triangle
72 50 100 2 Not a triangle
73 50 100 50 Not a triangle
74 50 100 99 Scalene
75 50 100 100 Isosceles

(These are the 75 cases out of the 125 cases)

 EXPERIMENT 3

Aim: Write a program to find the roots of the quadratic equation, its
input is triple positive integers (say a, b, c) and the values may be from
the interval [1,100] and perform BVA & ROBUST TESTING.

BVA for nature of roots of a quadratic equation

#include <bits/stdc++.h> using namespace std;
void nature_of_roots(int a, int b, int c)
{
if (a == 0) {
cout << "Not a Quadratic Equation" << endl; return;
}
int D = b * b - 4 * a * c; if (D > 0) {
cout << "Real Roots" << endl;
}
else if (D == 0) {
cout << "Equal Roots" << endl;
}
else {
cout << "Imaginary Roots" << endl;
}}
int main()
{
int a,b,c; cin>>a; cin>>b; cin>>c;
nature_of_roots(a,b,c);
return 0;
}

Test Cases: -

Test Cases a b c Expected Output

1 1 50 50 Real Roots

2 2 50 50 Real Roots

3 50 50 50 Imaginary Roots

4 99 50 50 Imaginary Roots

5 100 50 50 Imaginary Roots

6 50 1 50 Imaginary Roots

7 50 2 50 Imaginary Roots

8 50 99 50 Imaginary Roots

9 50 100 50 Equal Roots

10 50 50 1 Real Roots

11 50 50 2 Real Roots

12 50 50 99 Imaginary Roots

13 50 50 100 Imaginary Roots

Output:
ROBUST for nature of roots of a quadratic equation
Test Cases: -

Test Cases a b c Expected Output

1 0 50 50 Invalid INPUT

2 1 50 50 Real Roots

3 2 50 50 Real Roots

4 50 50 50 Imaginary Roots

5 99 50 50 Imaginary Roots

6 100 50 50 Imaginary Roots

7 101 50 50 Invalid INPUT

8 50 0 50 Invalid INPUT

9 50 1 50 Imaginary Roots

10 50 2 50 Imaginary Roots

11 50 99 50 Imaginary Roots

12 50 100 50 Equal Roots

13 50 101 50 Invalid INPUT

14 50 50 0 Invalid INPUT

15 50 50 1 Real Roots
16 50 50 2 Real Roots
17 50 50 99 Imaginary Roots
18 50 50 100 Imaginary Roots
19 50 50 101 Invalid INPUT
 EXPERIMENT 4

Aim: Write a program to find the largest among three numbers, its input
is triple positive integers (say a, b, c) and the values may be from the
interval [1,100] and perform BVA & ROBUST TESTING

Code:
#include <stdio.h> int main()
{
int A, B, C;
printf("\n\tEnter three numbers: "); scanf("\n\t%d %d %d", &A, &B,
&C);
if( A<1 || B<1 || C<1 || A>100 || B>100 || C>100 )
printf("\n\t INVALID Input"); else
{
if (A >= B && A >= C)
printf("\n\t%d is the largest number.", A);
else if (B >= A && B >= C)
printf("\n\t%dis the largest number.", B);
else
printf("\n\t%d is the largest number.", C);
}
return 0;
}
BVA for nature of roots of a quadratic equation
Test Cases: -

Test Cases a b c Expected Output

1 1 50 50 50
2 2 50 50 50
3 50 50 50 50
4 99 50 50 99
5 100 50 50 100
6 50 1 50 50
7 50 2 50 50
8 50 99 50 99
9 50 100 50 100
10 50 50 1 50
11 50 50 2 50
12 50 50 99 99
13 50 50 100 100

Output:
ROBUST for nature of roots of a quadratic equation
Test Cases: -
Test Cases a b c Expected Output
1 0 50 50 Invalid INPUT
2 1 50 50 50
3 2 50 50 50
4 50 50 50 50
5 99 50 50 99
6 100 50 50 100
7 101 50 50 Invalid INPUT
8 50 0 50 Invalid INPUT
9 50 1 50 50
10 50 2 50 50
11 50 99 50 99
12 50 100 50 100
13 50 101 50 Invalid INPUT
14 50 50 0 Invalid INPUT
15 50 50 1 50
16 50 50 2 50
17 50 50 99 99
18 50 50 100 100
19 50 50 101 Invalid INPUT
 EXPERIMENT 5

Aim: WAP in C/C++ to find the area of a circle, Triangle, Square and
Rectangle and perform equivalence class testing.

Code:
#include <iostream> using namespace std;
int main()
{
int ch; char c;
float b, h, a;
cout<<"\n\tEnter your choice"; cout<<"\n\t1.Triangle";
cout<<"\n\t2.Square"; cout<<"\n\t3.Rectangle"; cout<<"\n\t4.Circle";
cout<<"\n\t5.Exit";
cin>>ch;
switch(ch)
{
case 1 :
b: cout<<"\n\tEnter the base of the triangle (1-100)"; cin>>b;
if ((b<=0)||(b>100))
{
cout<<"\n\tInvalid entry for base\n"; goto b;
}
h: cout<<"\n\tEnter the height of the triangle (1-100)"; cin>>h;
if ((h<=0)||(h>100))
{
cout<<"\n\tInvalid height for height\n"; goto h;
}
a= 0.5*b*h;
cout<<"\n\tThe area is "<<a; break;

case 2 :
s: cout<<"\n\tEnter the side of the square (1-100)"; cin>>b;
if ((b<=0)||(b>100))
{
cout<<"\n\tInvalid entry for base \n"; goto s;
}
a= b*b;
cout<<"\n\tThe area is "<<a; break;

case 3:
d: cout<<"\n\tEnter the base of the triangle (1-100)" ; cin>>b;
if((b<=0)||(b>100))
{
cout<<"\n\tInvalid entry for base\n "; goto d;
}
p: cout<<"\n\tEnter the height of the triangle (1-100) ";
cin>>h;
if ((h<=0)||(h>100))
{
cout<<"\n\tInvalid height for height\n"; goto p;
}
a=b*h;
cout<<"\n\tThe area is "<<a; break;

case 4:
t: cout<<"\n\tEnter the radius of the circle "; cin>>b;
if ((b<=0)||(b>100))
{
cout<<"\n\tInvalid entry for base\n "; goto t;
}
a= 3.14*b*b; cout<<"\n\tThe area is "<<a; break;
case 5: exit(0); break;
default : cout<<"\n\t WRONG CHOICE";
}
return 0;
}
Case 1: Triangle
Input Domain:
I1 = {h : h<=0} I2 = {h : h>100}
I3 = {h : 1<=h<=100} I4 = {b : b<=0}
I5 = {b : b>100}
I6 = {b : 1<=b<=1001}
Test Cases for the Case of Triangle are as under:

Test Case ID H b Expected Output

1 0 50 Invalid Input

2 50 50 1250

3 101 50 Invalid Input

4 50 0 Invalid Input

5 50 50 1250

6 50 101 Invalid Input

Output Domain:
O1 = {: Triangle if h > 0, b > 0}
O2 = {: Not a triangle if h <= 0, b <= 0}
Output:
Case 2: Square
Input Domain:
I1 = {s : s<=0}
I2 = {s : s>100}
I3 = {s : 1<=s<=100}
Test Cases for the Case of Square are as under:
Test Case ID S Expected Output

1 0 Invalid Input
2 50 2500
3 101 Invalid Input
Output Domain:
O1 = {: Square if s>}
O2 = {: Not a square if s <= 0}
Output:
Case 3: Rectangle
Input Domain:
I1 = {l : l<=0} I2 = {l : l>100}
I3 = {l : 1<=l<=100} I4 = {b : b<=0}
I5 = {b : b>100}
I6 = {b : 1<=b<=100}
Test Cases for the Case of Rectangle are as under
Test Case ID L b Expected Output
1 0 50 Invalid Input
2 50 50 2500
3 101 50 Invalid Input
4 50 0 Invalid Input
5 50 50 2500
6 50 101 Invalid Input
Output:
Case 4: Circle
Input Domain:
I1 = {r : r<=0} I2 = {r : r>100}
I3 = {r : 1<=r<=100}
Test Cases for the Case of Circle are as under:
Test Case ID R Expected Output
1 0 Invalid Input
2 50 7850
3 101 Invalid Input
Output Domain:
O1 = {: Circle if 1<=r<=100}
O2 = {: Not a Circle if r <= 0}
Output:
 EXPERIMENT 6

Aim: WAP in C/C++ to compute 3 sides of a triangle and to determine

whether they form scalene, isosceles, or equilateral triangle and
perform Cause effect testing, Decision table-based testing and
Equivalence Class testing.

Code:
: #include<conio.h> #include<stdio.h>
void main()
{
int a,b,c,result;
printf("\n\tEnter the values of a, b and c : = "); scanf("\t%d %d %d",
&a,&b,&c); if(((a+b)>c)&&((b+c)>a)&&((c+a)>b))
{
if((a==b)&&(b==c))
printf("\n\t It is an Equilatral Triangle"); else if((a==b)||(b==c)||(c==a))
printf("\n\t It is an isosceles Triangle"); else
printf("\n\t It is a Scalene Triangle");
}
else
printf("\n\t not a triangle"); getch();
}
Output:

Decision Table Based Test Cases

Equivalence Class testing
Output domain equivalence classes are:
O1={<x,y,z>: Equilateral triangle with sides x,y,z}
O1={<x,y,z>: Isosceles triangle with sides x,y,z}
O1={<x,y,z>: Scalene triangle with sides x,y,z}
O1={<x,y,z>: Not a triangle with sides x,y,z}
The test cases are:

Input domain-based classes are:

I1={x: x < 1} I2={x: x > 100}
I3={x: 1 ≤x ≤100}
I4={y: y < 1} I5={y: y > 100}
I6={y: 1 ≤y ≤100}
I7={z: z < 1} I8={z: z > 100}
I9={z: 1 ≤z ≤100}

Some inputs domain test cases can be obtained using the

relationship amongst x,y and z.
I10={< x,y,z >: x = y = z}
I11={< x,y,z >: x = y, x ≠z}
I12={< x,y,z >: x = z, x ≠y}
I13={< x,y,z >: y = z, x ≠y}
I14={< x,y,z >: x ≠y, x ≠z, y ≠z}
I15={< x,y,z >: x = y + z}
I16={< x,y,z >: x > y +z}
I17={< x,y,z >: y = x +z}
I18={< x,y,z >: y > x + z}
I19={< x,y,z >: z = x + y}
I20={< x,y,z >: z > x +y}

Test cases derived from input domain are:

Cause effect testing
The causes are:
c1: side x is less than sum of sides y and z
c2: side y is less than sum of sides x and y
c3: side z is less than sum of sides x and y
c4: side x is equal to side y
c5: side x is equal to side z
c6: side y is equal to side
and effects are:
e1: Not a triangle
e2: Scalene triangle
e3: Isosceles triangle
e4: Equilateral triangle
e5: Impossible stage
Cause effect graph
Experiment 7
Aim- Write a program in C/C++ to compute ab and perform its decision
tablebased testing.

Code-
#include<bits/stdc++.h>
using namespace std; int
main(){
int t;
cout<<"How many times you wish to run ?";
cin>>t;
while(t-){
int a,b;
cout<<"enter value of a ";
cin>>a;
cout<<endl<<"enter value of b ";
cin>>b;
float c=pow(a,b);
cout<<c<<endl;
}
return 0;
}

Conditions
C1:a = 0,b = 0
C2:a = -ve, b =+ve
C3:a = +ve, b = -ve
C4:a = -ve, b = -ve
C5:a = +ve, b = +ve
C6:a = 0, b = integer
C7:b = 0, a = integer
C8:a = -ve, b = -ve odd

Actions
A1: Domain Error
A2: Negative Output
A3: Output = 1
A4: Positive Output
A5: Output = 0

OUTPUT-
Test Case Table

S.No. A B Output

1 2 3 +ve result

2 -1 3 -ve result

3 -2 -4 +ve result

4 0 1 Result is 0

5 0 0 Domain error

6 -1 -0.6 Result is 1
 EXPERIMENT – 8

AIM: WAP in C/C++ to compute previous date, given the present date as input
and perform decision table-based testing

Code:
#include <iostream>
using namespace std;

void getPrevDate(int *day,int *month, int *year)

{
if(*day==1)
{
if(*month==4|| *month==6|| *month==9|| *month==11)
{
*day=31;
*month = *month -1;
}
else if(*month==3)
{if(*year%4==0)*day=29;
else
*day=28;

*month = *month -1;

}
else if(*month==1)
{
*day=31;
*month = 12;
*year = *year - 1 ;
}
else if(*month==2)
{
*day=31;
*month = *month -1;
}
else
{
*day=30;
*month = *month -1;
}}
 else
{ *day = *day-1;
}}

int main()
{
int dd,mm,yy;
int a=0;
cout<<"\n\tEnter Date:";
cin>>dd;
cout<<"\n\tEnter Month:";
cin>>mm;
cout<<"\n\tEnter Year:";
cin>>yy;
if(yy>=1900 && yy<=9999)
{
//check month
if(mm>=1 && mm<=12)
{
//check days
if((dd>=1 && dd<=31) && (mm==1 || mm==3 || mm==5 || mm==7 || mm==8 ||
mm==10 || mm==12))
a=1;
else if((dd>=1 && dd<=30) && (mm==4 || mm==6 || mm==9 || mm==11))
a=1;
else if((dd>=1 && dd<=28) && (mm==2))
a=1;
else if(dd==29 && mm==2 && (yy%400==0 ||(yy%4==0 && yy%100!=0)))
a=1;
else
a=0;}
else
{
a=0;
}}
else
{a=0;}
if(a==0)
cout<<"\n\tImpossible";
else
{getPrevDate(&dd,&mm, &yy);
cout<<endl<<"\tPrevious date : "<<dd<<"/"<<mm<<"/"<<yy;}

return 0;
}
Decision Table Based Test Cases
Test Cases: -

Case ID Month Day Year Expected Output

1 June 1 1964 31 May 1964

2 June 21 1984 20 June 1984

3 May 1 1945 30 April 1945

4 March 31 2007 30 March 2007

5 August 29 2007 28 August 2007

6 February 29 1962 Impossible

Output:
 EXPERIMENT – 9
AIM - Create a test plan document for any application (e.g. Library Management
System).

LIBRARY MANAGEMENT SYSTEM

1. Introduction

The goal of this document is to develop a test plan for the Online Book
Store design system. This document defines all the procedures and
activities required to prepare for testing of the functionalities of the
system which are specified in Vision document. The objectives of the test
plan are to define the activities to perform testing, define the test
deliverables documents and to identify the various risks and
contingencies involved in testing.

2. Features to be tested

The following list describes the features to be tested:

USER:
Registration
Login
Add To Cart
Edit Cart

ADMIN:
Create and Delete book from Category
Create and Delete a Category
Manage Orders
Manage Members
3. Test Cases
 3.1 USER

Registration
ID TEST CASE USER INPUT PASS CRITERIA

U_REG_1 User User selects already Display message to choose

Registration existing user name different user name

U_REG_2 User User enters different Display message that

Registration password in password Password and Confirm
confirm field Password fields don't
match

U_REG_3 User User forgets to enter a Display message The value

Registration particular required fields in field is required

U_REG_4 User User enters all the details User account created
Registration successfully

Login
ID TEST USER INPUT PASS CRITERIA
CASE

U_LOG_1 User User enters a wrong Display message Login or

Login username Password is incorrect.

U_LOG_2 User User enters a wrong Display message Login or

Login password Password is incorrect.

U_LOG_3 User User enters correct User logs in successfully

Login username and password

Add to Cart
ID TEST USER INPUT PASS CRITERIA
CASE

U_AC_1 Add to User selects a book and clicks Book is added to the
Cart add to cart button shopping cart

U_AC_2 Add to Guest selects a book and clicks User should create an
Cart add to cart button account.

Edit Cart
ID TEST USER INPUT PASS CRITERIA
 CASE

U_EC_1 Edit Cart User changes the Quantity Quantity and total cost of Cart
should be updated

U_EC_2 Edit Cart User deletes a book from Books and total cost of Cart
shopping Cart should be updated

U_EC_3 Edit Cart User selects a new book to Books and total cost of Cart
shopping Cart should be updated

3.2 ADMIN

Create and Delete a Book from Category

ID TEST CASE ADMIN INPUT PASS CRITERIA

AD_CDB_1 Create and Delete a Admin adds a new Book should be updated
Book from book to category in Categories list
Category

AD_CDB_2 Create and Delete a Admin deletes a Book should be deleted

Book from book from category in Categories list
Category

Create and Delete a Category

ID TEST CASE ADMIN INPUT PASS CRITERIA

AD_CDC_1 Create and Delete a Admin adds a new Category should be

Category category updated to system

AD_CDC_1 Create and Delete a Admin deletes a Category should be

Category category deleted from system

Manage Orders
ID TEST CASE ADMIN INPUT PASS CRITERIA

AD_MO_1 Manage Orders Admin accepts an order Order is processed

AD_MO_2 Manage Orders Admin deletes an order Order is not processed

Manage Members
ID TEST CASE ADMIN INPUT PASS CRITERIA
AD_MM_1 Manage Members Admin accepts Members Member is accepted

AD_MM_2 Manage Members Admin deletes Members Member is not accepted

4. Approach
This section describes the overall approach of the testing which ensures that the each feature
and the combination of the features are adequately tested. The major tasks that are used are
4.1 Unit testing
Unit testing is a method of testing that verifies the individual units of source code are
working properly. The goal of unit testing is to isolate each part of the program and show
that the individual parts are correct. The NUnit a testing tool for C#, will be used for unit
testing.
4.2 Load testing
Load testing is the process of creating demand on a system or device and measuring its
response. It generally refers to the practice of modeling the expected usage of a software
program by simulating multiple users accessing the program concurrently. As such, this
testing is most relevant for multi-user systems; often one built using a client/server model,
such as web servers
4.3 System Testing
Once the entire system has been built then it has to be tested against the Software
Requirement Specification and System Specification to check if it delivers the features
required. System testing can involve a number of specialist types of test to see if all the
functional and non-functional requirements have been met.
4.4 Performance Testing
The system should meet the performance requirements as mentioned in the Vision document.
The performance will be evaluated based on the response time of the GUI and the database
commands. Using JMETER tool performance testing will be done.
4.5 Manual Testing
Manual Testing will be done to ensure the correctness of various parts of the code using test
cases generated by the tester.

5. Pass/fail criteria
The system should satisfy all the functional requirements, in the Vision document. Each
feature to be tested will be evaluated against its requirement as stated in the Vision
Document. The pass or fail of a test depends on whether the system meets with all the
particular post conditions.
Test cases executed on the Online Book Store will pass if they meet the specific
requirements as mentioned in the Vision Document.

6. Suspension criteria and resumption requirements

6.1 Suspension criteria
If the system contains one or more critical defects like the defects in the GUI editor which
provides the editing features for one line diagrams and database locking, unlocking
and sharing features which provides the environment for multiple users to work in parallel,
the entire system should be suspended.
The testing may also be suspended if the hardware and software components required are
not available on time.
The failed test cases should be recorded along with the description for failure.
6.2 Resumption requirements
When a new version of the system is transmitted to the test group after a suspension of
testing has occurred, all previous tests will be rerun to ensure program changes have not
inadvertently affected other portions of the program.

7. Test deliverables
The following documents are the available test deliverables:-
• Test plan
• Test case specifications
• Test input and output data
• Test procedure specifications
• Test logs
EXPERIMENT - 10
AIM: Study of Any Testing Tool (Win Runner).

INTRODUCTION:
HP Win Runner software was an automated functional GUI testing tool that allowed a user to
record and play back user interface (UI) interactions as test scripts.
As a functional test suite, it worked with HP Quick Test Professional and supported
enterprise quality assurance. It captured, verified and replayed user interactions
automatically, in order to identify defects and determine whether business processes worked
as designed. The software implemented a proprietary Test Script Language (TSL) that
allowed customization and parameterization of user input.
HP Win Runner was originally written by Mercury Interactive. Mercury Interactive was
subsequently acquired by Hewlett Packard (HP) in 2006. On February 15, 2008, HP Software
Division announced the end of support for HP Win Runner versions 7.5, 7.6, 8.0, 8.2, 9.2—
suggesting migration to HP Functional Testing software as a replacement.

MAIN FEATURES OF WIN RUNNER

● Developed by Mercury Interactive
● Functionality testing tool
● Supports C/s and web technologies such as (VB, VC++, D2K, Java, HTML, Power
Builder, Delphe, Cibell (ERP))
● To Support .net, xml, SAP, PeopleSoft, Oracle applications, Multimedia we can use
QTP.
● Win runner run on Windows only.
● Xrunner run only UNIX and Linux.
● Tool developed in C on VC++ environment.
● To automate our manual test win runner used TSL (Test Script language like c)

TESTING PROCESS IN WIN RUNNER

1. Learning - Recognition of objects and windows in our application by win runner is
called learning. Win runner 7.0 follows Auto learning.

2. Recording - Win runner records over manual business operation in TSL.

3. Edit Script - Depends on corresponding manual test, test engineer inserts check
points in to that record script.

4. Run Script - During test script execution, win runner compare tester given expected
values and application actual values and returns results.
5. Analyse Results - Tester analyses the tool given results to concentrate on defect
tracking if required.

ANALYSING TEST RESULTS IN WINRUNNER TOOL AND REPORTING

THE DEFECTS

When you finish any test in WinRunner, WinRunner displays the results in a report
format.
The report logs the general information about the test run.ie, date, operator mode and
total run time. Also, the report details all the major events that occurred during the run,
such as checkpoints, error messages, system messages, or user messages.
A mismatch can be found in the report panel by seeing the actual result and the expected
result. If a test run fails due to a defect in the application being tested, you can report
information about the defect directly from the Test Results window.
This information is sent via e-mail to the quality assurance manager, who tracks the
defect until it is fixed.

DIFFERENT MODES OF RECORDING IN WINRUNNER

Two types of recording in WinRunner:

1. CONTEXT SENSITIVE RECORDING records the operations you perform on your

application by identifying Graphical User Interface (GUI) objects. Winrunner
identifies all the objects in your window you click like menus, windows, lists,
buttons and the type of operation you perform such as enable, move, select etc.
2. ANALOG RECORDING records keyboard input, mouse clicks, and the precise x-
and y-coordinates travelled by the mouse pointer across the screen i.e., Winrunner
records exact co-ordinates travelled by mouse.

STEPS TO USE WINRUNNER

After installing the WinRunner on the computer, invoke the WinRunner
application:
Start -> Programs ->WinRunner ->WinRunner
The opening screen of the WinRunner application is displayed, prompting to select one
of the three options:

● New Test: To create a new test script

● Open Test: To open an existing test script
● Quick Preview: To view the quick preview of WinRunner
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 actions 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.

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 recoded actions.

MODES FOR GENERATING TEST CASES

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 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 displays
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.

The procedure for saving the GUI map file in Global GUI map file mode is
as follows:
Step 1: Record a test case by following the preceding procedure.

Step 2: Open the GUI Map Editor window as shown in Fig. Tools -> GUI Map Editor.

Step 3: On selecting the GUI Map Editor. The screen as shown in figure is displayed.
Step 4: Save the GUI Map file.
File -> Save As
A File dialog appears and you need to enter the filename.

Step 5: Close the GUI Map Editor window.

PROCEDURE FOR LOADING GUI MAP FILE

The procedure for loading the GUI map file is as follows:

Step 1: Open the GUI Map Editor.

Tools -> GUI Map Editor

Step 2: Close all the opened GUI Map

files File -> Close all.
PROCEDURE FOR RUNNING TEST CASE
The procedure for running a test case is as follows:

Step 1: Open the test script to be executed.

Step 2: Run the test

Run -> Run from top (or) press F5 to run the test.
WinRunner executes the generated script and displays the results in the Test Results
window.
 Experiment-11

Aim:- Study of test management tool(QA Complete)

INTRODUCTION
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 test process and ensures the delivery of high quality
software.

Benefits

1. QA Complete can be integrated with any number of tools

2. Customizable as per the tester’s needs
3. Requirements and tests can be traced to defect effectively
4. Reports and Dashboards are the key features of QA Complete
Features

1. Test Case Management – Simple Test Case

structuring also allows for focused metrics and clear
status report
2. Test Environment Management – Various environments are
linked to individual test cases for effective Test Coverage
across different platforms, operating systems, and devices
3. Defect and Issue Management – Mainly tracks the resolution
process of bugs for each release and automatically creates bugs
when test cases fail.
4. Test Automation Integration – 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
5. Bug Tracker Integration – Can be integrated with various Bug tracking
tools
6. 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.

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).

Synchronize the QA Complete with JIRA project Management Tool

To synchronize the QA Complete Test Management tool with the

JIRA Project Management tool we must install and configure QA
Complete – JIRA Connector.
QA Complete – JIRA Connector:
It is a connector to synchronize JIRA issues with QA Complete Defects
or Requirements.It synchronizes the data based on the settings that are done
i.e. Unidirectional synchronization/bidirectional synchronization

1. Bidirectional – Any change made in one system will be updated in the

other system
2. Unidirectional – Changes that are made in the source
system will be updated in the destination system [NOTE:
Changes made in the destination system will be overwritten
by the changes made later in the source system.
Below are the Steps to Synchronize QA Complete with JIRA

Step 1: Download the latest version of QA Complete – JIRA Connector

Step 2: Create a Profile for Synchronization:

Stop Services -> Manage -> Add -> Fill in the details -> Click OK
Step 3: Select the Synchronization Profile -> Manage -> Edit ->
Settings -> Set the Synchronization

Step 4: Navigate to ALM/QA Complete tab and fill in the fields to

establish the connection
 Step 5: Navigate to the JIRA tab and establish the connection

Step 6: Navigate to the Field Mapping tab and select the desired
fields to synchronize the corresponding data in JIRA

Step 7: To Start synchronizing, select “Synchronize Now” and

view the result in the Synchronization Log tab.
Step 8: Items that are synchronized between QA Complete and
JIRA can be viewed in Synchronized Items tab.

Synced data from QA Complete to JIRA – The defects from

the QA Complete are synchronized with the JIRA
Advantages:

1. Defects are created automatically under the Defects section

as a test step fails in a Test set.
2. Automation tests can be scheduled accordingly for the next run.
3. Synchronization with tools like Jira helps in providing the
deliverables in the right way
Conclusion:

Thus, QA Complete Test Management tool might be of great

use to the QA team in producing effective deliverables at the
right time
 EXPERIMENT-12

Aim : Automate the Test Cases using Test Automation

Tool – QA Complete

Introduction
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
test process and ensures the delivery of high-quality software.
Benefits
1. QA Complete can be integrated with any number of tools
2. Customizable as per the tester’s needs
3. Requirements and tests can be traced to defect effectively
4. Reports and dashboards are the key features of QA Complete
Features
1. Test case management – simple test case structuring also allows for
focused metrics and clear status report
2. Test environment management – various environments are linked
to individual test cases for effective test coverage across different
platforms, operating systems, and devices
3. Defect and issue management – mainly tracks the resolution
process of bugs for each release and automatically creates bugs
when test cases fail
4. Test automation integration – 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
5. Bug tracker integration – can be integrated with various bug tracking tools
6. Shared documents – stores all test documents in one central
location to improve collaboration
Steps to Setup and Work on 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.
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).

Synchronize the QA Complete with JIRA Project Management Tool

To synchronize the QA complete test management tool with the
JIRA project management tool we must install and configure QA
Complete – JIRA Connector.

QA Complete - JIRA Connector

It is a connector to synchronize JIRA issues with QA Complete
defects or requirements.it synchronizes the data based on the settings
that are done i.e., Unidirectional synchronization/bidirectional
synchronization.
▪ Bidirectional – any change made in one system will be updated
in the other system
▪ Unidirectional – changes that are made in the source system will
be updated in the destination system (changes made in the
destination system will be overwritten by the changes made later in
the source system).
Advantages
1. Defects are created automatically under the defects section
as a test step fails in a test set.
2. Automation tests can be scheduled accordingly for the next run.
3. Synchronization with tools like JIRA helps in providing the
deliverables in the right way.

Conclusion
QA Complete test management tool might be of great use to the
QA team in producing effective deliverables at the right time.