SOFTWARE TESTING AND QUALITY

ASSURANCE

BACHELORS OF TECHNOLOGY
IN
COMPUTER SCIENCE & ENGINEERING

Amity of School of Engineering & Technology

Amity University

Under Guidance of: Submitted By:

Mr. Arun Prakash Agrawal Anoushka Pradhan
7CSE3(Y)
A2305214187
 INDEX

S.No Category of Code Exp. Name of Date of Date of Max. Marks Signature
Assignment No. Experiment Allotment Evaluation obtained of
of Marks Faculty
experiment

1 Mandatory LR (10) 1 Design test 1

Experiment cases using
the boundary
value analysis
by taking
quadratic
problem.
2 Mandatory 2 Design test 1
Experiment cases using
Equivalence
class
partitioning
taking triangle
problem.
3 Mandatory 3 Design test 1
Experiment cases using
Decision table
by taking
triangle
problem.
4 Mandatory 4 Design 1
Experiment Independent
paths by
calculating
cyclomatic
complexity
using date
problem.
5 Mandatory 5 Design 1
Experiment Independent
paths by
taking DD
path using
 Date Problem

6 Mandatory 6 Design the 1

Experiment test cases for
login page of
AMIZONE.

7 Mandatory 7 Manual 1
Experiment Testing for
PAN card
verification.
8 Mandatory 8 Generate test 1
Experiment case for ATM
machine.
9 Mandatory 9 : Overview of 1
Experiment Testing
process using
Rational
Robot
10 Mandatory 10 Write a script 1
Experiment to record
verification
point using
Rational
Robot (For
GUI testing of
single click on
window OS).
11 Viva
VIVA(5)
 EXPERIMENT 1

Objective: Design test cases using the boundary value analysis by taking quadratic problem.
Software Required: Borland C/ C++
Theory: Boundary value analysis is a test case design technique to test boundary value between
partitions (both valid boundary partition and invalid boundary partition). A boundary value is an
input or output value on the border of an equivalence partition, includes minimum and maximum
values at inside and outside boundaries. Normally Boundary value analysis is part of stress and
negative testing.
Using Boundary Value Analysis technique tester creates test cases for required input field. For
example; an Address text box which allows maximum 500 characters. So, writing test cases for
each character once will be very difficult so that will choose boundary value analysis.

Example for Boundary Value Analysis:

Suppose you have very important tool at office, accepts valid User Name and Password field to
work on that tool, and accepts minimum 8 characters and maximum 12 characters. Valid range 8-
12, Invalid range 7 or less than 7 and Invalid range 13 or more than 13.

Write Test Cases for Valid partition value, Invalid partition value and exact boundary value.

 Test Cases 1: Consider password length less than 8.

 Test Cases 2: Consider password of length exactly 8.

 Test Cases 3: Consider password of length between 9 and 11.

 Test Cases 4: Consider password of length exactly 12.

 Test Cases 5: Consider password of length more than 12.

Problem Statement: consider a program for the determination of nature of roots of a quadratic
equation.

Description: its input is a triple of positive integers say a,b,c may be from interval 0 to 100. The
program output may have one of the following words: Not a quadratic equation, imaginary roots
and Equal Roots. Design the BV test cases.

PROGRAM:
#include<stdio.h>

#include<conio.h>

#include<math.h>

void main()

clrscr();

int a,b,c.d;

printf(“the quadratic equation is of the type a(x2)+bx+c=0”);

printf(“\nenter the value of a:”);

scanf(“%d”,%a);

printf(“\nenter the value of b:”);

scanf(“%d”,%b);

printf(“\nenter the value of c:”);

scanf(“%d”,%c);

d=(b*b)-4*a*c;

if((a<0)||(b<0)||(c<0)||(a>100)||(b>100)||(c>100))

printf(“\ninvalid input”);

else if(a==0)

printf(“\n not a quad equation”);

 else if(d==0)

printf(“\nroots are equal”);

else if(d<0)

printf(“\nimaginary roots”);

else

printf(“\n real roots”);

getch();

Results: Test Cases:

In the above program, we consider the values as lower as 0(lower boundary) and 1(just above
lower boundary) 50(center) 99(just below the higher boundary)and 100(upper boundary).

TEST RESULTS:
We have performed 13 test cases to perform BVA on Quadratic Equations which has resulted into
as per mentioned expected outputs.
 EXPERIMENT 2

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

Software Required: Turbo C++ Environment

Theory: Equivalence partitioning is a Test Case Design Technique to divide the input data of
software into different equivalence data classes. Test cases are designed for equivalence data
class. The equivalence partitions are frequently derived from the requirements specification for
input data that influence the processing of the test object. A use of this method reduces the time
necessary for testing software using less and effective test cases.
Equivalence Partitioning = Equivalence Class Partitioning = ECP
It can be used at any level of software for testing and is preferably a good technique to use first.
In this technique, only one condition to be tested from each partition. Because we assume that,
all the conditions in one partition behave in the same manner by the software. In a partition, if
one condition works other will definitely work. Likewise we assume that, if one of the condition
does not work then none of the conditions in that partition will work.
Equivalence partitioning is a testing technique where input values set into classes for testing.

 Valid Input Class = Keeps all valid inputs.

 Invalid Input Class = Keeps all Invalid inputs.

Example of Equivalence Class Partitioning:

 A text field permits only numeric characters

 Length must be 6-10 characters long

Partition according to the requirement should be like this:

While evaluating Equivalence partitioning, values in all partitions are equivalent that’s why 0-5
are equivalent, 6 – 10 are equivalent and 11- 14 are equivalent.
At the time of testing, test 4 and 12 as invalid values and 7 as valid one.
It is easy to test input ranges 6–10 but harder to test input ranges 2-600. Testing will be easy in
the case of lesser test cases but you should be very careful. Assuming, valid input is 7. That
means, you belief that the developer coded the correct valid range (6-10).

Problem Statement: Consider a program for the determination of Previous date. Its input is a
triple of day, month and year with the values in the range

1 ≤ month ≤ 12
1 ≤ day ≤ 31
2000 ≤ year ≤ 2050
The possible outputs are “Previous date” and “Invalid date”. Design the test cases using decision
table based testing.

Program:

#include<iostream.h>

# include<conio.h>

int leap(int year);

void main()

clrscr();

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;

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";

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";

getch();

int leap(int year)

if(((year%100==0) && (year%400==0)) || (year%4==0))

return 1;

else
 return 0;

Test Cases:
Output domain equivalence classes are:
O1= {<D, M, Y>: Previous date if all are valid inputs}
O1= {<D, M, Y>: Invalid date if any input makes the date invalid}

Test case M D Y Expected output

1 6 15 2025 14 June, 2025

2 6 31 2025 Invalid date

We may have another set of test cases which are based on input domain.
I1= {month: 1 ≤ m ≤ 12}
I2= {month: m < 1}
I3= {month: m > 12}
I4= {day: 1 ≤ D ≤ 31}
I5= {day: D < 1}
I6= {day: D > 31}
I7= {year: 1900 ≤ Y ≤ 2050}
I8= {year: Y < 2000}
I9= {year: Y > 2050}
Inputs domain test cases are:
Test Case M D Y Expected output

1 6 15 2025 14 June, 2025

2 -1 15 2025 invalid input

3 13 15 2025 invalid input

4 6 15 2025 14 June, 2025

5 6 -1 2025 invalid input

6 6 32 2025 invalid input

7 6 15 2025 14 June, 2025

 8 6 15 1999 invalid input (Value out of
range)

9 6 15 2051 invalid input (Value out of

range)

Result: The result interprets that the program used conforms to Equivalence Class Test.

EXPERIMENT 3

Objective: Design test cases using Decision table by taking triangle problem.
Software used: Borland C/C++.
Theory: A decision table is a good way to deal with different combination inputs with their
associated outputs and also called cause-effect table. Reason to call cause-effect table is an
associated logical diagramming technique called ’cause-effect graphing that is basically use to
derive the decision table.
Decision table testing is black box test design technique to determine the test scenarios for
complex business logic.

Example:

Printer troubleshooter

Rules

Printer does not print Y Y Y Y N N N N

Conditions A red light is flashing Y Y N N Y Y N N

Printer is unrecognized Y N Y N Y N Y N
 Check the power cable X

Check the printer-computer cable X X

Actions Ensure printer software is installed X X X X

Check/replace ink X X X X

Check for paper jam X X

Problem Statement: Consider a program for the classification of a triangle.

Description: its input is a triple of positive integers say a,b,c from the interval [1,100]. The
output may be scalene, equilateral and not a triangle.
Program:
#include<stdio.h>

#include<conio.h>

#include<mathio.h>

void main()

int a,b,c;

clrscr();

printf(“enter side 1”);

scanf(“%d”,&a);

printf(“enter side 2”);

scanf(“%d”,&b);

printf(“enter side 3”);

scanf(“%d”,&c);

if((a+b)<c)
 printf(“\n not a triangle”);

else if((a==b)&&(b==c)&&(c==a))

printf(“\nequilateral triangle”);

else if((a==b)||(b==c)||(c==a))

printf(“\nisoceles triangle”);

else if ((a!=b)||(b!=c)||(c!=a))

printf(“\nscalene triangle”);

getch();

Decision Table:
Conditions-
c1: a,b,c are sides of a triangle?
c2: a=b?
c3: a=c?
c4: b=c?
Actions-
a1: impossible
a2: equilateral triangle
a3: isosceles triangle
a4: scalene triangle
a5: not a triangle
Test Cases:

Test Results: various conditions are taken into account and respective actions based on them are
identified thus generating the test results for the problem statement.
 EXPERIMENT 4

Objective: Design Independent paths by calculating cyclomatic complexity using date problem.

Theory: Cyclomatic complexity is software metric (measurement), used to indicate the

complexity of a program. It is a quantitative measure of the number of linearly independent paths
through a program's source code. It gives the maximum number of independent paths in a
program. Two alternate methods are available for the complexity calculations:

1. McCabe's cyclomatic metric V(G) = e-n+2P

where, e:number of edges
n:number of nodes
P:number of connected components
2. Cyclomatic Complexity V(G) of a flow graph is equal to the number of predicate
(decision) nodes plus one.
V(G) = pi+1
where, pi is the number of predicate nodes contained in the flow graph.

Problem Statement: Consider a program for the determination of previous date. Its input is a
triple of day, month and year with the values in the range

1 ≤ month ≤ 12

1 ≤ day ≤ 31

1900 ≤ year ≤ 2025

The possible outputs are “Previous date” and “Invalid date”.

Program:

#include<iostream.h>

# include<conio.h>

int leap(int year);

void main()

clrscr();

intdc,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;

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";

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";

getch();

int leap(int year)

{
 if(((year%100==0) && (year%400==0)) || (year%4==0))

return 1;

else

return 0;

Test Cases:
Result:

As per the DD path graph for the date problem:

Number of edges (e) = 65

Number of nodes(n) = 49

V(G) = e-n+2P = 65-49+2 = 18

V(G) = Number of regions(inside +outside) = 17 + 1 = 18

EXPERIMENT 5

Objective: Design Independent paths by taking DD path using Date Problem

Software Required: Borland C/ Turbo C

Theory: Every node on a flow graph of a program belongs to one DD-path. If the first node on a
DD-path is traversed, then all other nodes on that path will also be traversed. The DD path graph
is used to find independent path for testing. Every statement in the program has been executed at
least once.

Problem Statement: Give the present date in the form of a triplet of day, month and year. To
check whether the date given is valid or invalid. If valid then the output is previous date.

Program:

#include<stdio.h>
#include<conio.h>
void main()
{
clrscr();
int day,month,year,flag=0;
int prev_day, prev_month, prev_year;
Printf(“enter the date=dd-mm-yy”);
Printf(“\nenter the day:”);
Scanf(“%d”,&day);
Printf(“\nenter the month:”);
Scanf(“%d”,&month);
Printf(“\nenter the year:”);
Scanf(“%d”,&year);
if((day>=1 && day<=31) && (month==1 || month==3|| month==5||
month==7|| month==8|| month==10 month==12||) && (year>=1))
{
Printf(“The date entered is valid”);
flag=1;
}
else if((day>=1 && day<=30) && (month==4|| month==6|| month==9||
month==11) && (year>=1))
{
Printf(“The date entered is valid”);
flag=1;
}
else if((day>=1 && day<=29) && (month=2) && (year>=1) && ((year%100==0 &&
year%400==0) || (year>=1) && (year%100!==0 && year%4==0)))
{
Printf(“The date entered is valid”);
flag=1;
}

else if((day>=1 && day<=28) && (month==2) && (year>=1))

 {
Printf(“The date entered is valid”);
flag=1;
}
else
{
Printf(“\n The date is invalid”);
}
if(flag==1)
{
if(day>=2)
{
prev_day = -prev_day;
printf(“\nThe previous date is:%d%d%d”,&prev_day,&month,&year);
}
else if(day==1)
{
if(month==1)
{
prev_day = 31;
prev_month = 12;
prev_year= -year;
printf(“\nThe previous date is:%d%d%d”,&prev_day,&month,&year);
}
if(month==5||month==7|| month==10||month==12)
{
prev_day = 31;
prev_month = -month;
printf(“\nThe previous date is:%d%d%d”,&prev_day,&month,&year);
}
Else if(month==2|| month==4|| month==6||month==8|| month==9|| month==11)
{
prev_day = 31;
prev_month = -month;
printf(“\nThe previous date is:%d%d%d”,&prev_day,&month,&year);

else
if(month==3)
{
if((year%100==0 && year%400==0) || (year>=1) && (year%100!==0
&& year%4==0))
{
prev_day = 29;
prev_month = -month;
printf(“\nThe previous date is:%d%d%d”,&prev_day,&month,&year);
}
else
{
prev_day = 28;
prev_month = -month;
 printf(“\nThe previous date
is:%d%d%d”,&prev_day,&month,&year);
}
}
}
}
getch();

Flow Graph:

Flow Table:
Flow Graph Nodes DD Path graph Remarks
corresponding node
1 to 9 n1 There is a sequential flow from node 1 to 9
10 n2 Decision node. if true go to 13 else go to 44
11 n3 Decision node. if true go to 12 else go to 19
12 n4 Decision node. if true go to 13 else go to 15
13,14 n5 Sequential Nodes
15,16,17 n6 Sequential Nodes
18 n7 Edges from node 14 to 17 are terminated here
19 n8 Decision node. if true go to 20 else go to 37
20 n9 Intermediate node with one input edge and one
output edge
21 n10 Decision node. if true go to 22 else go to 27
22 n11 Intermediate node
23 n12 Decision node. if true go to 24 else go to 26
24,25 n13 Sequential Nodes
26 n14 Two edges from node 25 & 23 are terminated
here
27 n15 Two edges from node 26 & 21 are terminated
here. And also a Decision node.
28,29 n16 Sequential Nodes
30 n17 Decision node. if true go to 31 else go to 33
31,32 n18 Sequential Nodes
33,34,35 n19 Sequential Nodes
36 n20 Three edges from node 29,32 & 35 are
terminated here
37 n21 Decision node. if true go to 38 else go to 40
38,39 n22 Sequential Nodes
40,41,42 n23 Sequential Nodes
43 n24 Three edges from node 36,39 & 42 are
terminated here
44 n25 Decision node. if true go to 45 else go to 82,
Three edges from node 18,43 & 10 are
terminated here
45 n26 Decision node. if true go to 46 else go to 77
46 n27 Decision node. if true go to 47 else go to 51
47,48,49,50 n28 Sequential Nodes
51 n29 Decision node. if true go to 52 else go to 68
52 n30 Intermediate node with one input edge and one
output edge
53 n31 Decision node. if true go to 54 else go to 49
54 n32 Intermediate Node
55 n33 Decision node. if true go to 56 else go to 58
56,57 n34 Sequential Nodes
58 n35 Two edges from node 57 & 55 are terminated
here
59 n36 Decision node. if true go to 60 else go to 63
60,61,62 n37 Sequential Nodes
63,64,65,66 n38 Sequential Nodes
67 n39 Two edges from node 62 & 66 are terminated
here
68 n40 Decision node. if true go to 69 else go to 72
69,70,71 n41 Sequential Nodes
72,73,74,75 n42 Sequential Nodes
76 n43 Four edges from node 50,67,71 & 75 are
terminated here
77,78,79 n44 Sequential Nodes
80 n45 Two edges from node 76 & 79 are terminated
here
81 n46 Intermediate Node
82,83,84 n47 Sequential Nodes
85 n48 Two edges from node 81 & 84 are terminated
here
86,87 n49 Sequential Nodes with exit node

DD Path Graph:
Independent Path:

Independent Path Of Date Problem

1 n1-n2-n25-n47-n48-n49
2 n1-n2-n3-n4-n5-n7-n25-n47-n48-n49
3 n1-n2-n3-n4-n6-n7-n25-n47-n48-n49
4 n1-n2-n3-n8-n21-n22-n24-n25-n47-n48-n49
5 n1-n2-n3-n8-n21-n23-n24-n25-n47-n48-n49
6 n1-n2-n3-n8-n9-n10-n15-n17-n19-n20-n24-n26-n47-n48-n49
7 n1-n2-n3-n8-n9-n10-n15-n17-n18-n20-n24-n26-n47-n48-n49
8 n1-n2-n3-n8-n9-n10-n11-n12-n13-n14-n15-n17-n18-n20-n24-n25-n47-
n48-n49
9 n1-n2-n3-n8-n9-n10-n11-n12-n14-n15-n17-n18-n20-n24-n25-n47-n48-
n49
10 n1-n2-n3-n8-n9-n10-n15-n16-n20-n24-n25-n47-n48-n49
11 n1-n2-n3-n8-n9-n10-n15-n16-n20-n24-n25-n44-n45-n46-n48-n49
12 n1-n2-n3-n8-n9-n10-n11-n12-n14-n15-n16-n20-n24-n25-n26-n27-n29-
n40-n41-n43-n45-n46-n48-n49
13 n1-n2-n3-n8-n9-n10-n11-n12-n14-n15-n16-n20-n24-n25-n26-n27-n29-
n40-n42-n43-n45-n46-n48-n49
14 n1-n2-n3-n8-n21-n22 n45-n46-n48-n49-n24-n25-n26-n27-n29-n30-n31-
n36-n37-n39-n43- n45-n46-n48-n49
15 n1-n2-n3-n8-n21-n22 n45-n46-n48-n49-n24-n25-n26-n27-n29-n30-n31-
n36-n38-n39-n43- n45-n46-n48-n49
16 n1-n2-n3-n8-n21-n22 n45-n46-n48-n49-n24-n25-n26-n27-n29-n30-n31-
n32-n33-n35-n36-n37-n39-n43-n45-n46-n48-n49
17 n1-n2-n3-n8-n21-n22 n45-n46-n48-n49-n24-n25-n26-n27-n29-n30-n31-
n32-n33-n34-n36-n37-n39-n43-n45-n46-n48-n49

Conclusion:

With the help of DD path, Number of independent path will be calculated.

EXPERIMENT 6

Objective: Design the test cases for login page of AMIZONE.

Theory: GUI testing is a process to test application's user interface and to detect if application is
functionally correct. GUI testing involves carrying set of tasks and comparing the result of same
with the expected output and ability to repeat same set of tasks multiple times with different data
input and same level of accuracy. GUI Testing includes how the application handles keyboard
and mouse events, how different GUI components like menu bars, toolbars, dialogs, buttons, edit
fields, list controls, images etc. reacts to user input and whether or not it performs in the desired
manner. Implementing GUI testing for your application early in the software development cycle
speeds up development improves quality and reduces risks towards the end of the cycle. GUI
Testing can be performed both manually with a human tester or could be performed
automatically with use of a software program.

Every software organization tests its software’s, still the end product always have some issues
left. Testing team tries their best to find all the bugs before release of the software but still there
are issues left in the product and they often re-appear as new modules are added to the software.
Even the best of manual testing process struggle to deliver effective, efficient, accurate and
increased test coverage.

Manual testing is often error prone and there are chances of most of the test scenarios left out.
Also with the project in development phase where source code changes appear every other day,
manually keeping up with the pace to test each and every feature is a difficult task. More often
than not the newly added features would bring regression along with them, so to accurately cover
all the old test cases manually is very time consuming and error prone.

Automated GUI Testing is use of software program to detect if your desktop application is
functionally correct. Automated GUI Testing includes automating manual testing tasks which are
mostly time consuming and error prone. Automated GUI Testing is a more accurate, efficient,
reliable and cost effective replacement to manual testing. Automated GUI Testing involves
carrying set of tasks automatically and comparing the result of same with the expected output
and ability to repeat same set of tasks multiple times with different data input and same level of
accuracy. Implementing GUI Testing for your application early in the software development
cycle speeds up development improves quality and reduces risks towards the end of the cycle.

Automated GUI Testing is a solution to all the issues raised with Manual GUI Testing. An
Automated GUI Testing tool can playback all the recorded set of tasks, compare the results of
execution with the expected behaviour and report success or failure to the test engineers. Once
the GUI tests are created they can easily be repeated for multiple numbers of times with different
data sets and can be extended to cover additional features at a later time.

Most of the software organizations consider GUI Testing as critical to their functional testing
process and there are many things which should be considered before selecting an Automated
GUI Testing tool. A company can make great strides using functional test automation. The
important benefits include, higher test coverage levels, greater reliability, shorted test cycles,
ability to do multi user testing at no extra cost, all resulting in increased levels of confidence in
the software.

Test Cases:

Test URL: https://www.Amizone.net

Preconditions: Open web browser and enter the given url in the address bar. Home page must be
displayed. All test cases must be executed from this page.

Test Test case Test case Test Steps Test Test Test Defect
case ID Name desc. case status Priority Severit
Step Expected Act status (P/F) y
ual

Login0 Validate To verify Enter login An error Design High

1 Login that Login name less message
name on than 3 chars “Login not
login (say a) and less than 3
page must password characters”
be greater and click must be
than 3 Submit displayed
characters button

Enter login An error Design High

name less message
than 3 chars “Login not
(say ab) and less than 3
Submit characters”
button must be
displayed

Enter name Login Design High

3 chars (say successful
abc) and or an error
password message
and click “Invalid
Submit Login or
button Password”
must be
displayed
Login Validate To verify Enter login An error Design High
02 Login that Login name message
name on greater than “Login not
login 10 chars greater than
page (say 10
should bjkluiopyrt) characters”
not be and must be
greater password displayed
than 10 and click
characters Submit
button

Enter login Login Design High

name less successful
than 10 or an error
chars (say message
bnkjh) and “Invalid
password Login or
and click password”
Submit must be
button displayed

Login Validate To verify Enter login An error Design High

03 Login that Login name message
name on starting with “Special
login special chars not
page does chars allowed in
not take (@hello) login” must
special and click be
characters submit displayed
button

Enter name An error Design High

ending with message
special “Special
chars chars not
(hello$) allowed in
password login” must
and click be
submit displayed
button
 Enter login An error Design High
name with message
special “Special
chars in chars not
middle allowed in
(he#$%llo) login” must
password be
and click displayed
submit
button

Pwd01 Validate To verify Enter An error Design High

password that Password message
Password less than 6 “Password
on login chars (say a) not less
page must and login than 6
be greater Name click characters”
than 6 Submit must be
characters Button displayed

Enter Login Design High

password 6 successful
chars (say or an error
abcdef) and message
Login Name “Invalid
and Click Login or
Submit Password”
button must be
displayed

Pwd02 Validate To verify Enter An error Design High

Password that Password message
Password greater than “Password
on login 10 chars not greater
page must (say than 10
be less abcdefghij) characters”
than 10 and Login must be
characters Name and displayed
click
Submit
button

Enter Login Design High

password Successful
 less than 10 or an error
chars (say a) message
and Login “Invalid
Name and Login or
click Password”
Submit must be
button displayed

Pwd03 Validate To verify Enter Login Design High

Password that Password successful
Password with special or an error
on login chars (sg$ message
page must %^rt) Login “Invalid
be allow Name and Login or
special click submit Password”
characters button must be
displayed

Link01 Verify To Verify Click Home Home page Design Low

Hyperlink the Hyper Link must be
s Links displayed
available
at left side Click sign Sign Up Design Low
on login Up Link page must
page be
working displayed
or not
Click New New User Design Low
Users Link Registratio
n Form
must be
displayed

Click Page with Design Low

Advertise Information
Link and Tariff
Plan for
Advertisers
must be
displayed
 Click Contact Design Low
Contact Us Information
Link page must
be
displayed

Click Terms Terms of Design Low

Link the Service
page must
be
displayed

Flnk01 Verify To Verify Click Home Home page Design Low

Hyper the Hyper Link must be
Links Links displayed
displayed
at Footer Click Contact Design Low
on login Contact Us information
page Link page must
working be
or not displayed

Click Terms Terms of Design Low

of the service
membership page must
Link be
displayed

Click Privacy Design Low

Privacy Policy page
Policy Link must be
displayed

Lblnk0 Verify To verify Click NEW New users Design Low

1 Hyper the Hyper USERS Registratio
Link Link Link located n Form
displayed in login box must be
at Box on displayed
login
 page Click New New User Design Low
working Users(Blue Registratio
or not colour) Link n form
located in must be
login Box displayed

Click forget Password Design Mediu

password retrieval m
Link located Page must
in login box be
displayed

Result: The Test cases generated were able to test LOGIN page successfully.

EXPERIMENT 7

Objective: Manual Testing for PAN card verification.

Resources Required: PAN CARD

Theory:
Manual testing is the process of manually testing software for defects. It requires a tester to play
the role of an end user and use most of all features of the application to ensure correct behavior.
To ensure completeness of testing, the tester often follows a written test plan that leads them
through a set of important test cases.
A key step in the process is, testing the software for correct behaviour prior to release to end
users. For small scale engineering efforts (including prototypes), exploratory testing may be
sufficient.
With this informal approach, the tester does not follow any rigorous testing procedure, but rather
explores the user interface of the application using as many of its features as possible, using
information gained in prior tests to intuitively derive additional tests.
The success of exploratory manual testing relies heavily on the domain expertise of the tester,
because a lack of knowledge will lead to incompleteness in testing. One of the key advantages of
an informal approach is to gain an intuitive insight to how it feels to use the application.

Test Cases:

TEST TEST TEST TEST INPUTS TEST

CASE ID DESCRIPTIO PREREQUISIT RESULTS
N E
1. Card holder Should be in NIKITA Accepted
name Block letters MEHTA
2. Card holder In a sequence of MEHTA Error
name first name NIKITA
followed by
second or last
name
3. Card holder Should be in SANJAY Accepted
father’s name Block letters MEHTA
4. Card holder In a sequence of MEHTA Error
father’s name first name SANJAY
followed by
second or last
name
5. Card holder’s In format of 25/01/1994 Accepted
Date of Birth (DD/MM/YYYY)
6. Pan Card Must be of 10 BSH3KSSN07 Accepted
number characters
7. Pan Card Should be in ASUT09TY87 Accepted
number alpha-numeric
formats
8. Pan Card Should have block Awut09yh87 Error
number letters
Test Results:
Various conditions are taken into fields and respective test cases for the PAN card is designed.

EXPERIMENT 8

Objective: Generate test case for ATM machine.

Resources Required: ATM Machine

Theory:
An automated teller machine or automatic teller machine
(ATM, American, Australian, Singaporean, Indian, Maldivian, and Hiberno-English), also known
as an automated banking machine (ABM, Canadian English), cash machine, cashpoint, cash line,
or colloquially hole in the wall (Australian, British, South African, and Sri Lankan English), is an
electronic telecommunications device that enables the customers of a financial institution to
perform financial transactions without the need for a human cashier, clerk or bank teller.
On most modern ATMs, the customer is identified by inserting a plastic ATM card with
a magnetic stripe or a plastic smart card with a chip that contains a unique card number and some
security information such as an expiration date or CVVC (CVV). Authentication is provided by
the customer entering a personal identification number (PIN).

Test Cases:

Test Case Test Cases Pre-Conditions Input Expected Output

System is
System asks
System allows displaying
Perform a whether customer
1. customer to perform menu of
transaction wants another
a transaction transaction
transaction
types
System is
System allows asking whether System displays a
2. multiple transactions customer wants Answer yes menu of transaction
in one session another types
transaction
System is
Session ends when
asking whether System ejects card
customer chooses
3. customer wants Answer no and is ready to start
not to do another
another a new session
transaction
transaction

Test Results:
Various conditions are taken into account and respective test cases for the ATM machine is
designed.

EXPERIMENT 9

Objective: Overview of Testing process using Rational Robot

Theory: Rational Robot is a complete set of components for automating the testing of Microsoft
Windows client/server and internet applications. The main component of Robot lets you start
recording tests in as few as two mouse clicks. After recording, Robot plays back the tests in a
fraction of the time it would take to repeat the actions manually.

Steps:

1 File>New>Script
2 Name:Login1
Description=Log in to the Classics Online application
3 Press OK
4 In Rational robot main window
Place cursor at the beginning of blank line after start application command
5 Record>insert at cursor
6 On GUI Record toolbar click Display GUI Insert Toolbar
7 Click write to LOG
Message=Verify the initial state of classics online application
Description=the next VP will verify initial state of classics online.
Result option=none
Ok
8 On GUI Record Toolbar click display GUI Insert Toolbar
Click Windows Existence
Name=Login1
Ok
Click Select
Drag Object Finder Pointer to Classics Login Dialog Box and release the mouse
Ok
Ok
9 In classics Login Dialog box click Ok
10 On GUI Record Toolbar, click Stop Recording Button.
11 Exit Classics Online
12 Playback the script file>Playback(Select Login1>ok, Accept default log info.)
13 Look at the results.

Conclusion: Rational Robot is used for software testing purpose and provide then results and
script of whatever we have done during till now in the process and used for both network
environment and windows application but not useful for network application because use of
it disclose the password also.
 EXPERIMENT 10

Objective: Write a script to record verification point using Rational Robot (For GUI testing of
single click on window OS).

Theory:

During recording, a verification point captures object information (based on the type of
verification point) and stores it in a baseline data file. The information in this file becomes the
baseline of the expected state of the object during subsequent builds.
When you play back the script against a new build, Rational Robot retrieves the information in
the baseline file for each verification point and compares it to the state of the object in the new
build. If the captured object does not match the baseline, Robot creates an actual data file. The
information in this file shows the actual state of the object in the build.
After playback, the results of each verification point appear in the Test Manager log. If a
verification point fails (the baseline and actual data do not match), you can select the verification
point in the log and click View > Verification Point to open the appropriate Comparator. The
Comparator displays the baseline and actual files so that you can compare them.

Procedure:

Steps required to work on Rational Robot:

Step1: Click on Start -> Rational Software -> Rational Administrator

Step2: On Admin Window right click on Project and enter Project name and Location

Step3: Keep password blank and click on next -> finish

Step4: On a new Configuration Project Window under Test Assets click on Create

Step5: Select the Microsoft Access as the Database and click on next -> finish

Step6: In the rational administrator window click on Rational Robot Icon that is 10th from right

Step7: After giving the name a GUI Record Window is displayed as follows.

Step8: You can open any window point verification and record the script. We can work also in
the application. GUI will record each and every event that occurs.

Step9: Stop the recording and click on third icon named Specify Log Information and make
build file giving your testing name and a new window will open containing log information
specifying whether it is pass or fail.
Conclusion: We checked the script and got the results in terms of pass/fail.