SHRI VAISHNAV VIDYAPEETH

VISHWAVIDYALAYA, INDORE
SHRI VAISHNAV INSTITUTE OF INFORMATION TECHNOLOGY
Department of Computer Science and Engineering

Lab Manual
Program :- B-Tech ( CSE )
Semester :- V Section :- A
Subject Name :- Software Testing & Quality Assurance
Subject Code :- BTDSE512N
Submitted By :- Submitted To :-
Aniket Kumar Jha Prof. Shuchi Mandhanya
21100BTCSE09768 CSE Department

SESSION:JUL-DEC 2023
 Shri Vaishnav Vidyapeeth Vishwavidyalaya
Shri Vaishnav Institute of Information Technology
Department of Computer Science and Engineering

Software Testing and Quality Assurance [ BTDSE-512N ]

LIST OF EXPERIMENTS

S. No. Name of Experiments Page No. Date of Sign /

Experiment Remarks

01. Design test cases using Boundary value

analysis by taking quadratic equation 01-04
problem
02. Design test cases using Equivalenceclass 05-07
partitioning taking triangle problem.

03. Design test cases using Decisiontable 08-14

taking Date problem.
04. Design independent paths by calculating 15-19
cyclometer complexityusing date problem.

05. Design the test cases for login pageof 20-23

AMIZONE.
06. Manual Testing for PAN card 24-26
verification.
07. Generate test case for ATM 27-29
machine.
08. Overview of Testing process using 30-32
Rational Robot.
ANIKET KUMAR JHA 21100BTCSE09768 III YEAR / V SEMESTER

EXPERIMENT-01

❖ AIM: Design test cases using Boundary value analysis by taking quadratic equation
problem.
Boundary value analysis is a software testing (Black Box) technique in which tests are
designed to include representatives of boundary values. The idea comes from the Boundary
(topology). Given that we have a set oftest vectors to test the system, a topology can be
defined on that set. Those inputs which belong to the same equivalence class as
defined by the equivalence partitioning theory w ou ld c on s t i t ut e t he basis
(topology). Given that the basis sets are ne i gh bo ur s as defined in
neighbourhood (mathematics), there would exist boundary between them. The test
vectors on either side of the boundary are called boundary values. In practice this would
require that the test vectors can be ordered, and that the individual parameters follow
some kind of order (either partial order or total order). The expected input and output
values to the software component should be extracted from the component specification.
The values are then grouped into sets with identifiable boundaries. Each set, or partition,
contains values that are expected to be processed by the component in the same way.

• PROGRAM: Consider a program for the determination of the nature of roots of a

quadratic equation. Its input is a triple of positive integers (say a,b,c) and values may be
from interval [0,200]. The program output may have one of the following words.

✓ Not a quadratic equation.

✓ Real roots.
✓ Imaginary roots.
✓ Equal roots.

Software Testing and Quality Assurance BTDSE512N 1|Page

ANIKET KUMAR JHA 21100BTCSE09768 III YEAR / V SEMESTER

• Code:

• Output:
Real roots

Equal roots

Software Testing and Quality Assurance BTDSE512N 2|Page

ANIKET KUMAR JHA 21100BTCSE09768 III YEAR / V SEMESTER

Not Quadratic

Imaginary

In Boundary Value Analysis, there will be 4N+1 test cases which means 4*3+1 = 13
test cases will be generated.

Software Testing and Quality Assurance BTDSE512N 3|Page

ANIKET KUMAR JHA 21100BTCSE09768 III YEAR / V SEMESTER

Here's an explanation of how boundary value analysis was used to design the test cases:

• For the coefficient 'a', the boundary values are a = 0 and a ≠ 0. We check if a is zero and print
an error message if it is.
• For the discriminant, the boundary values are discriminant < 0, discriminant = 0, and
discriminant > 0. We check if the discriminant is negative, zero, or positive, and print the
appropriate output for each case.
By testing these boundary values, we can ensure that the program works correctly for all possible
inputs, and that any errors or bugs are caught and handled properly.

Software Testing and Quality Assurance BTDSE512N 4|Page

ANIKET KUMAR JHA 21100BTCSE09768 III YEAR / V SEMESTER

EXPERIMENT-02

❖ AIM: Design test cases using Equivalence class partitioning taking triangle
problem.

Equivalence class partitioning is a testing technique that divides the input values into different
equivalence classes based on certain criteria. For the triangle problem, we can use the following
equivalence classes:
• Equilateral triangle: All sides are equal.
• Isosceles triangle: Two sides are equal, third side is different.
• Scalene triangle: All sides are different.
• Invalid triangle: One or more sides are less than or equal to zero, or the sum of any two
sides is less than or equal to the third side.

➢ Program:

Software Testing and Quality Assurance BTDSE512N 5|Page

ANIKET KUMAR JHA 21100BTCSE09768 III YEAR / V SEMESTER

➢ Output:
Equilateral Triangle

Isosceles Triangle

Scalene Triangle

Using these equivalence classes, we can design the following test cases:

Software Testing and Quality Assurance BTDSE512N 6|Page

ANIKET KUMAR JHA 21100BTCSE09768 III YEAR / V SEMESTER

• Here are the test cases and program tested results.

Software Testing and Quality Assurance BTDSE512N 7|Page

ANIKET KUMAR JHA 21100BTCSE09768 III YEAR / V SEMESTER

EXPERIMENT-03

❖ AIM: Design test cases using Decision table taking date problem.
1≤month≤12
1≤day≤31
2000≤year≤2030
The possible out puts are “Previous date” and “Invaliddate”.

CODE:

#include<iostream>
using namespace std;
int leap(int year);
int main()
{
int dc, month, date, year, dm, dn, leap;
cout<<"Enter the date : ";
cin>>date;
cout<<"\nEnter the month : ";
cin>>month;
cout<<"\nEnter the year : ";
cin>>year;
cout<<"\nEntered date is : "<<date<<"/"<<month<<"/"<<year;

if(leap==0)
{
if(month==1)
dm=0;
if(month==2)
dm=31;
if(month==3)
dm=59;
if(month==4)
dm=90;
if(month==5)
dm=120;
if(month==6)
dm=151;
if(month==7)
dm=181;
if(month==8)
dm=212;

Software Testing and Quality Assurance BTDSE512N 8|Page

ANIKET KUMAR JHA 21100BTCSE09768 III YEAR / V SEMESTER

if(month==9)
dm=243;
if(month==10)
dm=273;
if(month==11)
dm=304;
if(month==12)
dm=334;
}

else
{
if(month==1)
dm=0;
if(month==2)
dm=31;
if(month==3)
dm=60;
if(month==4)
dm=91;
if(month==5)
dm=121;
if(month==6)
dm=152;
if(month==7)
dm=182;
if(month==8)
dm=213;
if(month==9)
dm=244;
if(month==10)
dm=274;
if(month==11)
dm=305;
if(month==12)
dm=335;
}

dc=dm+date;

cout<<"The no of Day is : "<<dc;

dn=dc%7;

if(dn==0)
cout<<"\nSaturday";

Software Testing and Quality Assurance BTDSE512N 9|Page

ANIKET KUMAR JHA 21100BTCSE09768 III YEAR / V SEMESTER

else if(dn==1)
cout<<"\nSunday";
else if(dn==2)
cout<<"\nMonday";
else if(dn==3)
cout<<"\nTuesday";
else if(dn==4)
cout<<"\nWednesday";
else if(dn==5)
cout<<"\nThursday";
else if(dn==6)
cout<<"\nFriday";
return 0;
}

int leap(int year)

{
if(((year%100==0) && (year%400==0)) || (year%4==0))
{
return 1;
}
else
return 0;
}

Output:-
➢

Software Testing and Quality Assurance BTDSE512N 10 | P a g e

 ANIKET KUMAR JHA 21100BTCSE09768 III YEAR / V SEMESTER

The decision table is given below:

Sr.No. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

C1:Monthsi M M M M M1 M M M1 M1 M M M M M2 M
n 1 1 1 1 1 1 1 2 2 2 2

C2:daysin D1 D1 D2 D2 D3 D3 D4 D4 D5 D5 D1 D1 D2 D2 D3

C3:yearin Y1 Y2 Y1 Y2 Y1 Y2 Y1 Y2 Y1 Y2 Y1 Y2 Y1 Y2 Y1

a1:Impossi X X
ble

a2:Decrem X X X X X X X X X
entday

a3: X X
Reset
dayto31
a4: X X
Reset
dayto30
a5:
Reset
dayto29
a6:
Reset
dayto28
a7:decrem X X X X
entmonth

a8:Resetm
onthtoDec
ember

a9:Decrem
entyear

Software Testing and Quality Assurance BTDSE512N 11 | P a g e

ANIKET KUMAR JHA 21100BTCSE09768 III YEAR / V SEMESTER

Sr.No. 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

C1:Monthsi M M M M M2 M M M3 M3 M M M M M3 M
n 2 2 2 2 3 3 3 3 3 3 3

C2:daysin D3 D4 D4 D5 D5 D1 D1 D2 D2 D3 D3 D4 D4 D5 D5

C3:yearin Y2 Y1 Y2 Y1 Y2 Y1 Y2 Y1 Y2 Y1 Y2 Y1 Y2 Y1 Y2

a1:Impossi
ble

a2:Decrem X X X X X X X X X X X X X
entday

a3:
Reset
dayto31
a4:
Reset
dayto30
a5: X
Reset
dayto29
a6: X
Reset
dayto28
a7:decrem X X
entmonth

a8:Resetm
onthtoDec
ember

a9:Decrem
entyear

Sr.No. 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45

Software Testing and Quality Assurance BTDSE512N 12 | P a g e

ANIKET KUMAR JHA 21100BTCSE09768 III YEAR / V SEMESTER

C1:Monthsi M M M M M4 M M M4 M4 M M M M M5 M
n 4 4 4 4 4 4 4 5 5 5 5

C2:daysin D1 D1 D2 D2 D3 D3 D4 D4 D5 D5 D1 D1 D2 D2 D3

C3:yearin Y1 Y2 Y1 Y2 Y1 Y2 Y1 Y2 Y1 Y2 Y1 Y2 Y1 Y2 Y1

a1:Impossi
ble

a2:Decrem X X X X X X X X X X X
entday

a3: X X X X
Reset
dayto31
a4:
Reset
dayto30
a5:
Reset
dayto29
a6:
Reset
dayto28
a7:decrem X X
entmonth

a8:Resetm X X
onthtoDec
ember

a9:Decrem X X
entyear

Sr.No. 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60

Software Testing and Quality Assurance BTDSE512N 13 | P a g e

ANIKET KUMAR JHA 21100BTCSE09768 III YEAR / V SEMESTER

C1:Monthsi M M M M M5 M M M6 M6 M M M M M6 M
n 5 5 5 5 6 6 6 6 6 6 6

C2:daysin D3 D4 D4 D5 D5 D1 D1 D2 D2 D3 D3 D4 D4 D5 D5

C3:yearin Y2 Y1 Y2 Y1 Y2 Y1 Y2 Y1 Y2 Y1 Y2 Y1 Y2 Y1 Y2

a1:Impossi X X X X X
ble

a2:Decrem X X X X X X X X
entday

a3: X X
Reset
dayto31
a4:
Reset
dayto30
a5:
Reset
dayto29
a6:
Reset
dayto28
a7:decrem X X
entmonth

a8:Resetm
onthtoDec
ember

a9:Decrem
entyear

Software Testing and Quality Assurance BTDSE512N 14 | P a g e

ANIKET KUMAR JHA 21100BTCSE09768 III YEAR / V SEMESTER

EXPERIMENT-04

❖ AIM: Design independent paths by calculating cyclometer complexity using date

problem.

Cyclomatic complexity is a source code complexity measurement that is being correlated to a

number of coding errors. It is calculated by developing a Control Flow Graph of the code that
measures the number of linearly-independent paths through a program module.
Lower the Program's cyclomatic complexity, lower the risk to modify and easier to understand. It
can be represented using the below formula:

Cyclomatic complexity = E - N + 2*P

where,
E = number of edges in the flow graph.
N = number of nodes in the flow graph.
P = number of nodes that have exit points

Two alternate methods are available for the complexity calculations.

1. Cyclomatic complexity V(G) of a flow graph G is equal to the number of predicate (decision) nodes
plus one. V(G)= π +1 where π is the number Aniket Kumar Jha of predicate nodes contained in the
flow graph G.
2. Cyclomatic complexity is equal to the number of regions of the flow graph.

Software Testing and Quality Assurance BTDSE512N 15 | P a g e

ANIKET KUMAR JHA 21100BTCSE09768 III YEAR / V SEMESTER

➢ PROGRAM:

Software Testing and Quality Assurance BTDSE512N 16 | P a g e

ANIKET KUMAR JHA 21100BTCSE09768 III YEAR / V SEMESTER

➢ OUTPUT:

1. Enter date in the format DD MM YYYY: 25 25 2025

Invalid date

Software Testing and Quality Assurance BTDSE512N 17 | P a g e

ANIKET KUMAR JHA 21100BTCSE09768 III YEAR / V SEMESTER

2. Enter date in the format DD MM YYYY: 08 05 2002

Valid date

3. Enter date in the format DD MM YYYY: 20 27 2027

Invalid date

4. Enter date in the format DD MM YYYY: 30 10 2025

Valid date

Software Testing and Quality Assurance BTDSE512N 18 | P a g e

ANIKET KUMAR JHA 21100BTCSE09768 III YEAR / V SEMESTER

5. Enter date in the format DD MM YYYY: 08 30 2114

Invalid date

Test Cases-

Software Testing and Quality Assurance BTDSE512N 19 | P a g e

ANIKET KUMAR JHA 21100BTCSE09768 III YEAR / V SEMESTER

EXPERIMENT-05

❖ AIM: Design the test cases for login page of AMIZONE.

To design the test cases for a login page of AMIZONE(mobile app is for the students of Amity
University), we can consider the following scenarios:
• Valid login credentials - Enter the correct login credentials (username and password) and
ensure that the user is logged in successfully.
• Invalid username - Enter an incorrect username and the correct password, and ensure that the
system prompts the user to enter valid credentials.
• Invalid password - Enter the correct username and an incorrect password, and ensure that the
system prompts the user to enter valid credentials.
• Incorrect username and password - Enter incorrect login credentials and ensure that the
system prompts the user to enter valid credentials.

Test Cases in Tabular Format

Software Testing and Quality Assurance BTDSE512N 20 | P a g e

ANIKET KUMAR JHA 21100BTCSE09768 III YEAR / V SEMESTER

➢ PROGRAM:

Software Testing and Quality Assurance BTDSE512N 21 | P a g e

ANIKET KUMAR JHA 21100BTCSE09768 III YEAR / V SEMESTER

➢ OUTPUT:

Software Testing and Quality Assurance BTDSE512N 22 | P a g e

ANIKET KUMAR JHA 21100BTCSE09768 III YEAR / V SEMESTER

➢ INPUT:

Enter your AMIZONE username : Captain_Jack_Sparrow

Enter your password: Death_of_the_Nile@Aniket_007

Software Testing and Quality Assurance BTDSE512N 23 | P a g e

ANIKET KUMAR JHA 21100BTCSE09768 III YEAR / V SEMESTER

EXPERIMENT-06

❖ AIM: Manual Testing for PAN card verification.

Manual testing for PAN card verification typically involves the following steps:

• Verify the format of the PAN card number: The PAN card number should be in the format
of five alphabets followed by four numbers and one alphabet.
• Verify the length of the PAN card number: The PAN card number should be exactly 10
characters long.
• Verify the first five characters of the PAN card number: The first five characters of the
PAN card number should consist of alphabets only.
• Verify the sixth to ninth characters of the PAN card number: The sixth to ninth characters
of the PAN card number should consist of numbers only.
• Verify the last character of the PAN card number: The last character of the PAN card
number should consist of an alphabet only.

Test Cases in Tabular Format

Software Testing and Quality Assurance BTDSE512N 24 | P a g e

ANIKET KUMAR JHA 21100BTCSE09768 III YEAR / V SEMESTER

➢ PROGRAM:

➢ OUTPUT:

1. Enter Pan No. : 12345aqswe

PAN in invalid

Software Testing and Quality Assurance BTDSE512N 25 | P a g e

ANIKET KUMAR JHA 21100BTCSE09768 III YEAR / V SEMESTER

2. Enter Pan No. : 0000001234

PAN is invalid

3. Enter Pan No. : ABCF12341f

PAN is invalid

4. Enter Pan No. : ABCDE1234F

PAN is invalid

Software Testing and Quality Assurance BTDSE512N 26 | P a g e

ANIKET KUMAR JHA 21100BTCSE09768 III YEAR / V SEMESTER

EXPERIMENT-07

❖ AIM: Generate test case for ATM machine.

Here are the steps for ATM validation of user when cash is to be withdrawn:

• Insert an ATM card into the machine.

• Enter PIN.
• Select the 'Withdraw Cash' option.
• Enter the amount to be withdrawn.
• Check for available balance.
• If the available balance is less than the entered amount, display an appropriate error
message and ask for re-entering the amount or to cancel the transaction.
• If the available balance is sufficient, dispense cash.
• Collect the dispensed cash.
• Collect the ATM card.
• Collect the transaction receipt if offered.
• End the transaction.
Test Cases in Tabular Format

Software Testing and Quality Assurance BTDSE512N 27 | P a g e

ANIKET KUMAR JHA 21100BTCSE09768 III YEAR / V SEMESTER

Software Testing and Quality Assurance BTDSE512N 28 | P a g e

ANIKET KUMAR JHA 21100BTCSE09768 III YEAR / V SEMESTER

Software Testing and Quality Assurance BTDSE512N 29 | P a g e

ANIKET KUMAR JHA 21100BTCSE09768 III YEAR / V SEMESTER

EXPERIMENT-08

❖ AIM: Overview of Testing process using Rational Robot.

Rational Robot is an automated testing tool developed by IBM. The testing process using Rational
Robot typically involves the following steps:
• Planning: In this phase, the testing team defines the scope of testing, identifies the testing
objectives, and prepares the test plan. The test plan defines the testing strategy, the testing
types, and the test cases to be executed.

• Recording: Rational Robot supports two methods of recording tests - GUI Recording and
Script Recording. GUI Recording records user actions by capturing the GUI components,
while Script Recording records user actions as code. The recording process creates a test script
that can be replayed to simulate user actions.

• Enhancing: Once the test script is recorded, it can be enhanced by adding verification points,
data-driven parameters, and error-handling routines. Verification points validate the
application's output against expected values, while data-driven parameters allow the same test
script to be executed with different input values. Error-handling routines detect and handle
errors that may occur during test execution.

• Debugging: The test script is then debugged to ensure it runs without errors. Debugging
involves identifying and fixing any issues in the script, such as syntax errors, missing object
references, or incorrect verification points.

• Execution: The test script is executed against the application under test (AUT). During test
execution, Rational Robot captures the test results, including any errors or failures.

• Reporting: After test execution, Rational Robot generates a detailed test report that includes
information on the test cases executed, their pass/fail status, and any defects identified. The
test report can be used to track testing progress and to identify areas for improvement in the
application under test.

Overall, the Rational Robot testing process involves planning, recording, enhancing, debugging,
executing, and reporting. By automating these steps, Rational Robot helps to reduce testing time
and increase test coverage, while improving the quality and reliability of the application under test.

Software Testing and Quality Assurance BTDSE512N 30 | P a g e

ANIKET KUMAR JHA 21100BTCSE09768 III YEAR / V SEMESTER

Program for testing using Rational Robot, you would typically use a scripting language such as
VBScript or JScript.

➢ Here's an example of test cases in tabular format:

Software Testing and Quality Assurance BTDSE512N 31 | P a g e

ANIKET KUMAR JHA 21100BTCSE09768 III YEAR / V SEMESTER

Software Testing and Quality Assurance BTDSE512N 32 | P a g e