0% found this document useful (0 votes)
182 views101 pages

Stqa Lab Manual

The document describes experiments to be conducted for a Software Testing and Quality Assurance Lab Manual. It lists 10 experiments including implementing loops, matrices, test cases, test plans, studying testing tools and case studies on bug tracking and test management tools.

Uploaded by

Bushra Hamid
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
182 views101 pages

Stqa Lab Manual

The document describes experiments to be conducted for a Software Testing and Quality Assurance Lab Manual. It lists 10 experiments including implementing loops, matrices, test cases, test plans, studying testing tools and case studies on bug tracking and test management tools.

Uploaded by

Bushra Hamid
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 101

Mahatma Education Society

Pillai College of Engineering


New Panvel

Department Of Information Technology

Software Testing and Quality Assurance Lab Manual

Conducted By:
Sushopti Gawade
Suresh Khandare
Samruddhi Khandare

Academic Year: 2016-2017

Semester VIII

List of Experiments

Sr. No. Name of Experiment


1 To implement: Do while, while do, if else, switch, for loops in C.
2 To implement working of matrix multiplication in C.
3 To study System Specifications and Bugs.
4 Write Test Cases for known Application.
5 Create Test Plan Document for any Application.
6 Case Study: Study of any Testing Tool.
7 Case Study: Study of any Web Testing Tool.
8 Case Study: Study of Bug Tracking Tool.
9 Case Study: Study of any Test Management Tool.
10 Case Study: Study of Open Source Testing Tool.

EXPERIMENT NO 1

Aim: Write a ‘c’ program to demonstrate the working of the fallowing constructs:
i) do…while ii) while… iii) if …else iv) Switch v) for Loops in C language

1. To demonstrate the working of do..while construct

Objective: To understand the working of do while with different range of values and test cases

Program:

#include <stdio.h>
int main( )
{
int i,j=0,n=5;
printf("enter a
number");
scanf("%d",&i);
do
{
if(i%2==0)
{
printf("%d",i);
printf("is a even number\
n"); i++;
j++;
}
else
{
printf("%d",i);
printf("is a odd nuumber\n");
i++;
j++;
}
}while(i>0 &&
j<n); return
0;
}

Output:

Input = 56 Actual output


56 is even number
57 is odd number
58 is even number
59 is odd number
60 is even number
Test cases:
Test case no: 1
Test case name: Positive values within range

Input Expected output Actual output Remarks


Input = 56 56 is even number 56 is even number Success
57 is odd number 57 is odd number
58 is even number 58 is even number

59 is odd number 59 is odd number

60 is even number 60 is even number

Test case no: 2


Test case name: Negative values within a range

Input Expected output Actual output Remarks


Input = -56 -56 is even number -56 is even number Fail
-57 is odd number
-58 is even number

-59 is odd number


-60 is even number
Test case no: 3
Test case name: Out of range values testing

Input Expected output Actual output Remarks


Input = 54687123416345151 54687123416345151 is a 2147483647 is Fail
odd number a odd number

2. To demonstrate the working of while construct

Objective: To understand the working of while with different range of values and test cases

Program:
#include <stdio.h>
int main( )
{
int i,j=0,n=5;
printf("enter a number\n");
scanf("%d",&i);
while(i>0 && j<n)
{
if(i%2==0)
{
printf("%d",i);
printf("is a even number\
n"); i++;
j++;
}
else
{
printf("%d",i);
printf("is a odd number\n");
i++;
j++;
}
}
return 0;
}

Output:

Input Actual output


Input = 7 7 is odd number
8 is even number
9 is odd number
10 is even number
11 is odd number

Test cases:
Test case no: 1
Test case name: Positive values within range

Input Expected output Actual output Remarks


Input = 7 7 is odd number 7 is odd number Success
8 is even number 8 is even number
9 is odd number 9 is odd number
10 is even number 10 is even number

11 is odd number 11 is odd number

Test case no: 2


Test case name: Negative values within a range
Input Expected output Actual output Remarks
Input = -85 -85 is odd number Fail

-86 is even number //No output


-87 is odd number While condition fails//
-88 is even number

-89 is odd number


Test case no: 3
Test case name: Out of range values testing

Input Expected output Actual Rem


output arks
Input 1234569874563210233211445632000 2147483 Fail
=123456987456321023321144563200 00111223333333636666666666 is a 6472147
000111223333333636666666666 even number is a odd
number

3. To demonstrate the working of “if else construct”

Objective: To understand the working of if else with different range of values and test cases

Program:
#include <stdio.h>
int main()
{
int a; printf("Enter
a: ");
scanf("%d",&a); if
(a%2 == 0)
{
printf("The given number is EVEN");
}
else
{
printf("The given number is ODD");
}
return 0;
}

Output:

Input = 124 Actual output


The given number is EVEN

Test cases:
Test case no: 1
Test case name: Positive values within range

Input Expected output Actual output Remarks


Input = 124 The given number is EVEN The given number is EVEN Success

Test case no: 2


Test case name: Negative values within a range

Input Expected output Actual output Remarks


Input = -84123 The given number is ODD The given number is ODD Fails
Test case no: 3
Test case name: Out of range values testing

Input Expected output Actual output Remarks


Input = The given number The given number Fails
22369978452435235365614652 is ODD is ODD
3335664561461413031303

4. To demonstrate the working of “switch constructs”

Objective: To understand the working of switch with different range of values and test cases

Program:
#include<stdio.h>
int main()
{
int a,b,c,i;
printf("1.add\n2.sub\n3.mul\n4.div\n5.enter your choice\n");
scanf("%d",&i);
printf("Enter value of a and b");
scanf("%d%d",&a,&b); switch(i)
{
case 1: c=a+b;
printf("Sum of no is:%d",c); break;
case 2: c=a-b;
printf("Substraction of no is:%d",c); break;
case 3: c=a*b;
printf("multiplication of no is:%d",c); break;
case 4: c=a/b;
printf("division of no is:%d",c); break;
default:
printf("Enter your choice"); break;
}
return 0;
}

Output:

Input Output
Enter Ur choice: 1 Sum of no. is: 11
Enter a, b Values: 5,6
Enter Ur choice: 2 Subtraction of no. is: 4
Enter a, b Values: 9,5
Enter Ur choice: 3 Multiplication of no. is: 30
Enter a, b Values: 5,6
Enter Ur choice: 4 Division of no. is: 4
Enter a, b Values: 20,5

Test cases:
Test case no: 1
Test case name: Positive values within range

Input Expected output Actual output Remarks


Enter Ur choice: 1 Sum of no. is: 11 Sum of no. is: 11 Success
Enter a, b Values: 5,6
Enter Ur choice: 2 Subtraction of no. is: 4 Subtraction of no. is: 4
Enter a, b Values: 9,5
Enter Ur choice: 3 Multiplication of no. is: 30 Multiplication of no. is: 30
Enter a, b Values: 5,6
Enter Ur choice: 4 Division of no. is: 4 Division of no. is: 4
Enter a, b Values: 20,5
Test case no:2
Test case name: Out of range values testing

Input Expected output Actual Remarks


output
Enter Ur choice: 1 Sum of no. is: Sum of no. Fails
Enter a, b Values: 24569875351868756480120 is: -2
4865121355651131256456231122315,
8452312355465612321355461213545
Test case no: 3
Test case name: Divide by zero

Input Expected output Actual output Remarks


Enter Ur choice: 4 Division of no. is: 0 Floating point Fails
Enter a, b Values: 25, 0 exception(core dumped)

5. To demonstrate working of “for construct”

Objective: To understand the working of for with different range of values and test cases

Program:

#include <stdio.h>
int main()
{
int i,j;
printf("enter a number\n");
scanf("%d",&j);
for(i=1;i<=5;i++)
{
if(i%2==0)
{
printf("%d",j);
printf("is a even no\n");
j++;
}
else
{
printf("%d",j);
printf("is a odd no\n");
j++;
}
}
return 0;
}

Output:

Input Actual output


Input = 63 63 is odd no
64 is even no
65 is odd no
66 is even no
67 is odd no

Test cases:

Test case no: 1


Test case name: Positive values within range

Input Expected output Actual output Remarks


Input = 63 63 is odd no 63 is odd no Success
64 is even no 64 is even no
65 is odd no 65 is odd no

66 is even no 66 is even no

67 is odd no 67 is odd no
Test case no:2
Test case name: Negative values within a range

Input Expected output Actual output Remarks


Input = -36 -36 is even no -36 is odd no Fails
-37 is odd no -35 is even no
-38 is even no -34 is odd no

-39 is odd no -33 is even no

-40 is even no -32 is odd no

Test case no: 3


Test case name: Out of range values testing

Input Expected output Actual output Remarks


Input = 2147483647 is odd no 2147483647 is odd no Fails
54878845445544545454 2147483648 is even no -2147483648 is even no
545444445454455445545 2147483647 is odd no -2147483647 is odd no

454554554444545455454
2147483646 is even no -2147483646 is even no

454544
2147483645 is odd no -2147483645 is odd no
Conclusion: Thus we have successfully implemented Do while, while do, if else, switch, for loops
in C.
EXPERIMENT NO 2
Write a ‘c’ program to demonstrate the working of Matrix Multiplication.

Aim: Write a ‘c’ program to demonstrate the working of Matrix Multiplication.

Program:

#include <stdio.h> int main()

{
int m, n, p, q, c, d, k, sum = 0;
int first[10][10], second[10][10], multiply[10][10]; clrscr();

printf("Enter the number of rows and columns of first matrix\n"); scanf("%d%d", &m, &n);

printf("Enter the elements of first matrix\n"); for (c = 0; c < m; c++)

for (d = 0; d < n; d++) scanf("%d", &first[c][d]);

printf("Enter the number of rows and columns of second matrix\n"); scanf("%d%d", &p, &q);

if (n != p)

printf("Matrices with entered orders can't be multiplied with each other.\n"); else

printf("Enter the elements of second matrix\n"); for (c = 0; c < p; c++)

for (d = 0; d < q; d++) scanf("%d", &second[c][d]);

for (c = 0; c < m; c++) {f


for (d = 0; d < q; d++) {
for (k = 0; k < p; k++) {
sum = sum + first[c][k]*second[k][d];
}
multiply[c][d] = sum;
sum = 0;
}
}
printf("Product of entered matrices:-\n");
for (c = 0; c < m; c++) {
for (d = 0; d < q; d++)
printf("%d\t", multiply[c][d]);
printf("\n");
}
}
getch();
return 0;
}
Output:

Input Output
Enter the number of rows and columns of first Product of entered matrices:-
matrix 3 3

14 9 9
Enter the elements of first matrix 1 2 2
23 15 15
233
32 21 21
344
Enter the number of rows and columns of
second matrix 3 3

Enter the elements of second matrix 4 3 3


322
211
Test cases:

Test case no: 1


Test case name: Equal number of rows and columns.

Input Expected Output Actual Output Remarks


Enter the number of rows and Product of Product of
columns of first matrix entered entered matrices:-
3 matrices:- SUCCESSFUL
3 30 36 42
Enter the elements of first 30 36 42 66 81 96
matrix 1 2 3 66 81 96 102 126 150
456 102 126 150
789

Enter the number of rows and


columns of second matrix
3
3
Enter the elements of
second matrix 1 2 3
456
789
Test case no: 2
Test case name: Column of 1st matrix not equals to rows of 2nd matrix.

Input Expected Output Actual Output Remarks


Enter the number of rows and Product of
columns of first matrix entered Matrices with
2 matrices:- entered orders FAILURE
2 can't be
Enter the elements of first multiplied with
matrix 5 10 400 475 each other.
15 20 900 1075

Enter the number of rows and 1300 1375


columns of second matrix
3
2
Enter the elements of second
matrix 20 25
30 35
40 45
Test case no: 3
Test case name: Out of range value testing.

Input Expected Output Actual Output Remarks


Enter the number of rows and Product of Product of
columns of first matrix entered entered matrices:-
2 matrices:- FAILURE
2
Enter the elements of first 17620 24668
matrix 11111 33333 45462 87434 -19724 1420
55555 77777 94564 21075
Enter the number of rows and
columns of second matrix (Garbage Values) 2 2

Enter the elements of


second matrix 22222 44444
66666 88888
Conclusion: Hence, we demonstrated the working of Matrix Multiplication.
EXPERIMENT NO 03
BUGS IDENTIFICATION AND TEST CASES ON ATM MACHINE

Aim: Take any system (e.g. ATM system) and study its system specifications and report the various
bugs.

Program:
Features to be tested:
1. Machine is accepting ATM card
2. Machine is rejecting expired card
3. Successful entry of PIN number
4. Unsuccessful operation due to enter wrong PIN number 3 times
5. Successful selection of language
6. Successful selection of account type
7. Unsuccessful operation due to invalid account type
8. Successful selection of amount to be withdrawn
9. Successful withdrawal
10. Expected message due to amount is greater than day limit
11. Unsuccessful withdraw operation due to lack of money in ATM
12. Expected message due to amount to withdraw is greater than possible balance
13. Unsuccessful withdraw operation due to click cancel after insert card
14. Unsuccessful transaction due to ATM goes offline

Bugs Identified:
Bugs_Name Bugs_Id
Invalid card ATM_001
Invalid pin ATM_002
Invalid selection of language ATM_003
Invalid account type ATM_004
Insufficient balance ATM_005
Day limit ATM_006
Transaction limit ATM_007
Invalid money denomination ATM_008
Not sufficient amount ATM_009
Transaction failed ATM_010
Incorrect insertion of card ATM_011
Null transaction ATM_012
No printed receipt ATM_013

Bug Report:
ATM_001 Bug_Id
Invalid Card Bug Description
Keep valid card in the ATM Steps to Reproduce
Welcome Screen Expected Result
Invalid Card Actual Result
Pass/Fail Status

ATM_002 Bug_Id
Invalid Pin Entered Bug Description
Enter the authorized PIN Steps to Reproduce
Menu Screen displayed Expected Result
Invalid PIN screen is displayed Actual Result
Pass/Fail Status

ATM_003 Bug_Id
Invalid Selection of Language Bug Description
Select the correct language from menu Steps to Reproduce
Menu Screen displayed Expected Result
Invalid language selected screen is displayed Actual Result
Pass/Fail Status

ATM_004 Bug_Id
Invalid Account type Bug Description
1. Enter a valid user PIN number Steps to Reproduce
2. Select the withdraw option on the main menu
3. Choose the correct type of account (either
savings or current account)
Enter the Amount screen displayed Expected Result
Invalid Account type screen is displayed Actual Result
Pass/Fail Status
ATM_005 Bug_Id
Insufficient Balance Bug Description
1. Menu screen should be displayed Steps to Reproduce
2. Select the withdraw option
3. Select the correct type of account
4. Enter the sufficient amount to withdraw from
the account
5. Dispense the cash screen & amount to be
deducted from account
Collect the amount screen displayed Expected Result
Insufficient balance in the account Actual Result
Pass/Fail Status

ATM_006 Bug_Id
Day Limit Bug Description
1. Keep a valid card in ATM Steps to Reproduce
2. Enter the authorized PIN
3. Enter the amount to withdraw from the
account
4. Amount enter is over the day limit (>40000)
5. Amount enter is over the day limit and
display screen is displayed
Cash is dispensed and collect the receipt Expected Result
Day limit exceeded screen is displayed Actual Result
Pass/Fail Status

ATM_007 Bug_Id
Transaction Limit Bug Description
1. Menu screen should be displayed Steps to Reproduce
2. Select the withdraw option
3. Select the correct type of account
4. Enter sufficient amount to withdraw from the
account Transaction
within the limit
5. Dispense the cash screen & amount to be
deducted from account
Transaction limit exceeded screen is displayed Expected Result
Day limit exceeded screen is displayed. Actual Result
Pass/Fail Status

ATM_008 Bug_Id
Invalid Money Denominations Bug Description
1. Keep a valid card in ATM Steps to Reproduce
2. Enter the authorized PIN
3. Enter the amount which should be in
multiples of 100
4. Cash Dispenser screen is displayed
Collect the amount screen is displayed Expected Result
Amount enter not in required denominations Actual Result
Pass/Fail Status

ATM_009 Bug_Id
Not Sufficient Amount in ATM Bug Description
1. Menu screen should be displayed Steps to Reproduce
2. Select the withdraw option
3. Select the correct type of account
4. Enter the sufficient amount to withdraw from
the account
5. Dispense the cash screen & amount to be
deducted from account
Collect the amount screen displayed Expected Result
Not sufficient amount in ATM Actual Result
Pass/Fail Status

ATM_010 Bug_Id
Transaction Failed Bug Description
1. Menu screen should be displayed Steps to Reproduce
2. Select the withdraw option
3. Select the correct type of account
4. Enter the sufficient amount to withdraw from
the account
5. Dispense the cash screen & amount to be
deducted from account
6. Collect the card and receipt
Transaction completed successfully Expected Result
Transaction failed screen is displayed Actual Result
Pass/Fail Status
ATM_011 Bug_Id
Incorrect insertion of card Bug Description
1. Card inserted incorrectly Steps to Reproduce
Card accepted Expected Result
Insert the card properly Actual Result
Pass/Fail Status

ATM_012 Bug_Id
Null transactions Bug Description
1. Menu screen should be displayed Steps to Reproduce
2. Select the withdraw option
3. Select the correct type of account
4. Enter the sufficient amount to withdraw from
the account
5. Dispense the cash screen & amount to be
deducted from account
6. Collect the card and receipt
Transaction completed successfully Expected Result
No amount withdrawn/Null transaction Actual Result
Pass/Fail Status

ATM_013 Bug_Id
No printed receipt Bug Description
1. Menu screen should be displayed Steps to Reproduce
2. Select the withdraw option
3. Select the correct type of account
4. Enter the sufficient amount to withdraw from
the account
5. Dispense the cash screen & amount to be
deducted from account
6. Collect the card and receipt
Please collect the receipt Expected Result
No printed receipt Actual Result
Pass/Fail Status

Test cases:
1. Machine is accepting ATM card
Actual output Expected output Test case name Test case ID
Card accepted Card accepted ATM Card inserted 1
Card rejected with error message Card rejected Only half card inserted 2
(Insert Card properly)

2. Machine is rejecting expired card (expired date- 12/10/2015)


Actual output Expected output Test case name Test case ID
Card accepted Card accepted Card inserted on 2/10/2015 1
Card rejected with error Card rejected Card inserted on 13/10/2015 2
message(expired card
inserted)

3. Successfully entry of pin


Actual output Expected output Test case name Test case ID
Menu Screen displayed Menu Screen displayed Correct Pin enter 1
Enter valid pin Card Rejected Incomplete pin entered 2

4. Unsuccessful operation due to enter wrong pin 3 times


Actual output Expected output Test case name Test case ID
Menu Screen displayed Menu Screen displayed Correct Pin enter at 2nd 1
Time
Improper pin entered Card Rejected Wrong pin entered 3rd 2
and the card is not Time
active

5. Successful selection of language


Actual output Expected output Test case name Test case ID
Proceed to transaction Enter the pin screen is User preferable 1
Displayed language selected
(English)
Unable to make Enter the pin screen is User preferable 2
transaction displayed but user not
able to understand the
language

6. Successful selection of account type


Actual output Expected output Test case name Test case ID
Enter amount screen is Enter amount screen is Correct account type 1
displayed displayed Selected
Select correct account Enter amount screen is Incorrect account type 2
type displayed Selected

7. Unsuccessful operation due to invalid account type


Actual output Expected output Test case name Test case ID
Transaction failed Transaction successful Trying to withdrawal cash 1
(invalid account type)
Select correct account Balance to be display Balance enquiry 2
type

8. Successful selection of amount to be withdrawn


Actual output Expected output Test case name Test case ID

Transaction successful Transaction Entered the amount within 1


successful available account balance
Transaction failed with Transaction failed Entered the amount more than 2
error message (no account balance
sufficient balance)

9. Successful withdrawn
Actual output Expected output Test case name Test case ID
Transaction successful Withdrawn successful All details entered 1
correctly

Transaction failed(Enter Transaction failed All details entered 2


the correct details) incorrectly

10.Expected message due to amount is greater than the day limit (10000)
Actual output Expected output Test case name Test case ID
Transaction Successful. Transaction Entered amount 8000 1
(Collect your money) Successful

Transaction failed with Transaction failed Entered amount 15000 2


message (Amount exceed
the days limit)
11. Unsuccessful withdraw operation due to lack of money in ATM
Actual output Expected output Test case name Test case ID

Transaction failed. Transaction Successful. Entered amount 800 1


(Insufficient balance in
your account)

Transaction Successful. Transaction Successful. Entered amount 600 2

12. Unsuccessful withdraw operation due to click cancel after insert card
Actual output Expected output Test case name Test case ID
Transaction failed(please Collect your card Card inserted and 1
collect your card) displayed clicked cancel

Transaction failed Cash withdrawn and Enter amount and 2


transaction successful clicked cancel

Conclusion: ATM System specifications are studied and various bugs related to system are
identified.
EXPERIMENT NO 04
TEST CASES ON BANK APPLICATION

AIM: Write the test cases for Banking Application.

Here let’s take the banking application of HDFC bank as an example.

TEST CASES:

 Checking mandatory input parameters

TEST CASE ID INPUT EXPECTED OUTPUT ACTUAL INPUT


1 Name, address Account created Account created
details,
mobile no, email address,
job details, birth date proof,
Reference details
2 Name and address Account created Incomplete details for
account creation
proof
(Incomplete details)

 Checking optional input parameters

TEST CASE ID INPUT EXPECTED OUTPUT ACTUAL INPUT


1 Nomination details , Net Account created Account created
banking option, VISA card
option
2 No optional details filled Account created While creating account
system will ask you to
provide those optional
details as it will be
helpful for us.

 Check whether able to create account entity.

TEST CASE ID INPUT EXPECTED OUTPUT ACTUAL INPUT


1 All mandatory details filled Account entity created Account entity created
and verified by bank
authority
2 Incomplete details Account created Incomplete details for
account creation

 Check whether you are able to deposit an amount in the newly created account (and
thus updating the balance)

TEST CASE ID INPUT EXPECTED OUTPUT ACTUAL INPUT


1 Depositing Rs 1000 by a Amount is deposited Amount is deposited and
user whose account and balance is updated balance is updated
(78932) entity is created to Rs.2000 to Rs.2000
2 Depositing Rs 1000 No such account is Amount cannot
found be
but deposited,
the user doesn’t
have account entity. nosuch account exist

 Check whether you are able to withdraw an amount in the newly created
account (after deposit) (and thus updating the balance)

TEST CASE ID INPUT EXPECTED OUTPUT ACTUAL INPUT


1 Withdraw Rs 800 from Amount is withdrawn Amount is
account 78932 and current balance is withdrawn
Rd 1200 and balance is updated
to Rs.1200
2 Withdraw Rs 500 from Amount Withdrawn Amount
account 12344
cannotbe
withdraw, no sufficient
balance.
 Check whether company name and its pan number and other details are provided
in case of salary account

TEST CASE ID INPUT EXPECTED OUTPUT ACTUAL INPUT


1 Correct Pan no, company SalaryAccountis Salary account is created
name and details created
are provided
2 Only personal details, Salary account created Pan no is mandatory,
company details account is not created.
are provided.
No pan no.

 Check whether primary account number is provided in case of secondary account

TEST CASE ID INPUT EXPECTED OUTPUT ACTUAL INPUT


1 Primary account no is Secondary Account Secondary account
Provided is
is created
created
2 Incorrect primary account Secondary Primary account no does
no is provided not exist. Please provide
account correct primary account
cannot opened no to open secondary
account

 Check whether company details are provided in cases of company's current account

TEST CASE ID INPUT EXPECTED OUTPUT ACTUAL INPUT


1 Company name, address Company can have Company can
and details are provided current account. have
correctly current account.
2 Incomplete Company’s All details and proofs
company are
details and proof current account cannot incomplete;
are open company’s current
Provided account is not open.

 Check whether proofs for joint account is provided in case of joint account

TEST CASE ID INPUT EXPECTED OUTPUT ACTUAL INPUT


1 All proofs and photos are Joint Account Joint account is created
Provided is
created
2 Only proof of 2nd person Joint Account is Joint account is
is provided. not created as
not created proof of the person is
mandatory.

 Check whether you are able deposit an account in the name of either of the person in
a joint account.

TEST CASE ID INPUT EXPECTED OUTPUT ACTUAL INPUT


1 Depositing amount in Amount is deposited. Amount is deposited.
account in the name of 2nd
person.
2 Depositing amount in Amount is not Amount is not
account in the name of 2nd deposited. deposited.
person but the account no
is different

 Check whether you are able withdraws an account in the name of either of the person in
a joint account.

TEST CASE ID INPUT EXPECTED OUTPUT ACTUAL INPUT


1 Withdraw amount through Amount withdrawn Amount withdrawn
cheque in name of 1st successfully. successfully.
account holder.
2 Withdraw amount through Amount withdrawn is Amount withdrawn is
cheque in name of 2nd cancelled cancelled
account holder.

 Check whether you are able to maintain zero balance in salary account

TEST CASE ID INPUT EXPECTED OUTPUT ACTUAL INPUT


1 Withdrawal of all amount Amount withdrawn Amount withdrawn
from salary account successfully. successfully.

(Zero balance in (Zero balance in account)


account)
2 Balance is zero for last 6 Salary account is active Zero balance
months. still. not allowed for
longer time.
Salary account can be
blocked.

 Check whether you are not able to maintain zero balance (or mini balance) in non-
salary account.
TEST CASE ID INPUT EXPECTED OUTPUT ACTUAL INPUT
1 Balance = 0 in current Not allowed, minimum Minimum balance
account. balance Rs.1000 is Rs.1000 is required.
required.
2 Balance = 0 in saving Account is active still. Account is active still.
account.

 Checking successful entry of username and password.

TEST CASE ID INPUT EXPECTED OUTPUT ACTUAL INPUT


1 Valid username and Username accepted as a User accepted as a
password entered authentic user autehentic user
2 Invalid username and User rejected User rejected
password entered
3 Valid username and invalid User rejected User rejected
password entered
4 Invalid username and valid User rejected User rejected
password entered
5 Invalid username or User blocked User blocked
password entered more than
3 times

 Check whether adding beneficiary and adding funds to beneficiary is successful

TEST CASE ID INPUT EXPECTED OUTPUT ACTUAL INPUT


1 The user can add the Beneficiary is verified Beneficiary is verified
beneficiary or not and added and added
2 Select beneficiary to Intended beneficiary is Intended beneficiary is
transfer the funds to selected selected
3 Verify if the fund transfer All necessary details are All necessary detau\ils
page asked for the asked are asked
beneficiary name, IFSC
code, bank name and fund
amount and purpose of
transfer
 Check the amount is transferred in business hours or off business hours

TEST CASE ID INPUT EXPECTED OUTPUT ACTUAL INPUT


1 Check if the amount of time Beneficiary receives the Beneficiary receives the
it takes for the funds funds in real time as funds in real time as soon
tranferred between the in- soon as funds are as funds are transferred
business hours transferred by the sender by the sender
2 Check if the amount of time Funds will be transferred Funds will be transferred
it takes for the funds the next working day the next working day
transferred between the off
business hours

Conclusion: Hence, the test cases for Banking Application are created.

EXPERIEMNT NO 05
TEST PLAN DOCUMENT AND TEST CASES ON LIBRARY MANAGEMENT

Aim: Create a Test plan document for Library Management System.

Theory:

1. INTRODUCTION:
The Library Management System is an online application for assisting a librarian to managing book
library in a University. The system would provide basic set of features to add/update clients,
add/update books, search for books, and manage check-in/ check-out processes. Our test group
tested the system based on the requirement specification.
This report is the result for testing in the LMS. It mainly focuses on two problems:
1. What we will test
2. How we will test

2. OBJECTIVE AND TASKS:

Objectives
The objective is to test Library Management System, that performs the basic functionality of
providing a user account, with the features of issuing a book, extending the issue period of the
issued book etc.

Tasks
1. GUI Test
2. Database test
3. Basic Functional test
4. Update/delete student
5. Check-in book

3. SCOPE:
General
1. This is the interactive part of the LMS, the test is carried out to test its user friendliness.
2. This test is to check the connectivity with the database that stores client data in the library
database.
3. This test is to check basic functions such as, searching for a book, issuing a book, updating
book information and checkin/checkout processes.
4. This test is to check whether the client information is updated/deleted in/from the library
database.
5. This test is carried out to check whether the librarian is able to issue the desired book for the
client.

Plan Strategy:
1. Here, a set of sample users are selected to see whether the GUI is user friendly with all the
operations being done without making the user confused.
2. Here, if the librarian is issuing a book for the student then that entry for book in a particular
user account must be reflected in the database.
3. Here, the basic foundations like, searching for a book, issuing a book, updating book
information and check-in\check-out process is being performed well or not.
4. Here, if the librarian is deleting or updating a client in the library database, the proper
deletion and updation operation is being performed.
5. Here, if the librarian is issuing a book for the student then that bookID must be present in
that student account.

4. TESTING STRATEGY:
The testing strategy is to design ‘n’ number of test cases and test the various modules of the Library
Management System, for this approach a sample set of users are selected and are allowed to use the
system, so that they can find out the difficulties, faults, defects and errors they are facing with the
system.
For testing, the tool used is Winrunner. WinRunner software was an automated functional GUI
testing tool that allowed a user to record and playback user interface (UI) interactions as test scripts.

5. System Testing:
Software testing is a critical element of software quality assurance and represents the ultimate
review of specifications, designs and coding. The testing phase involves the testing of system using
various test data; Preparation of test data plays a vital role in the system testing. After preparation
the test data, the system under study is tested.
Those test data errors were found and corrected by the following testing steps and corrections are
recorded for future references. Thus a series testing is performed on the system before it is ready for
implementation.

The various types of testing on the systems are:


● Unit testing
● Integrated testing
● Validation testing
● Output testing
● User acceptance testing

a. Unit Testing:
Unit testing focuses on verification effort on the smallest unit of software design module. Using the
unit test plans prepared in the design phase of the system as a guide, important control paths are
tested to uncover errors within the boundary of the modules. The interfaces of each of the modules
under consideration are also tested. Boundary conditions were checked. All independent paths were
exercised to ensure that all the statements in the module are executed at least once and all error-
handling paths were tested. Each unit was thoroughly tested to check if it might fall in any possible
situation. This testing was carried out during the programming itself. At the end of this testing
phase, each unit was found to be working satisfactorily, as regarded to the expected out from the
module.

b. Integration Testing:
Data can be across an interface. One module can have an adverse effect on another sub’s function.
When combined may not produce the desired major function; global data structure can present
problems. Integration testing is a systematic technique for constructing tests to uncover errors
associated with the interface. All modules are combined in the testing step. Then the entire program
was tested as a whole.

c. Validation Testing:
At the culmination of integration testing, software is completely assembled as a package.
Interfacing errors have been uncovered and corrected and final series of software test-validation
testing begins. Validation testing can be defined in many ways, but a simple definition is that
validation succeeds when the software functions in manner that is reasonably expected by the
consumer. Software validation is achieved through a series of black box tests that demonstrate
conformity with requirements. After validation test has been conducted, one of two condition exists.
● The function or performance characteristics confirm to specification that are accepted.
● A validation from specification is uncovered and a deficiency created.
Deviation or errors discovered at this step in this project is corrected prior to completion of the
project with the help of user by negotiating to establish a method for resolving deficiencies. Thus
the proposed system under consideration has been tested by using validation testing and found to be
working satisfactorily.

d. Output Testing:
After performing the validation testing, the next step is output testing of the proposed system, since
the system is useful if it does not produce the required output in specific format required by them
tests the output generator displayed on the system under consideration. Here the output is
considered in two ways: - one is onscreen and other is in printed format. The output format on the
screen is found to be correct as the format was designed in the system design phase according to the
user needs. As far as the hard copies are considered it goes in terms with user requirements. Hence
output testing does not result in any correction in the system.

e. User Acceptance Testing:


User acceptance of the system is the key factor is the success of any system. The system under
consideration is tested for user acceptance by constantly keeping in touch with prospective system
and user at the time of developing and making changes whenever required.

6. HARDWARE STRATEGIES
Hardware to be tested:
1. Computers
2. Modems
3. Bar code reader

7. ENVIRONMENT REQUIREMENTS
The testing environment should contain a desktop PC with all the necessary softwares (.net, adobe
flash player, etc.) installed in the system.
The most important thing is the testing environment should contain a persistent internet connection
so that all the read, write, update, delete operations can be committed successfully into the database.
The environment should also have a bar code reader that can read the bar code of the book(s) being
issued or returned.

8. FEATURES TO BE TESTED

1. Add Book(s):
In this feature it is checked whether the entry of book ID in Database is
made or not.

2. Return Book(s):
In this feature it is tested whether the book issued by a student or user is
returned properly or not which means the database should remove that
particular Book ID from the student’s account.

3. Issue Book(s):
In this it is tested whether a particular book is issued to a student or not by
making an entry of issued Book ID in that student account.

4.Delete Record of Issued Book(s):


This is to test whether the issued Book ID is removed from the system,
indicating that a particular book is issued and Book with that ID is no
more available in the Library.

5.View Record of Issued Book(s):


This is to check list of all the Books Issued by the student or user.

9. RESOURCES/ROLES AND RESPONSIBILITIES


Specify the staff members who are in the test project and what their roles are going to be (for
example, Mary Brown(User) compile Test Cases for Acceptance Testing). Identify groups
responsible for managing, designing, preparing, executing, and resolving the test activities as well
as related issues. Also identify groups responsible for providing the test environment. These groups
may include developers, testers, operations staff, testing services, etc.

10. SCHEDULES
Test Plan:
This software explains Test Cases for Library management system. Software testing is a critical
element of software quality assurance and represents the ultimate review of specification, design
and coding. Testing presents an interesting of a system using various test data. Preparation of the
test data plays a vital role in the system testing. After the preparation the test data, the system under
study is tested those test data. Errors were found and corrected by using the following testing steps
and corrections are recorded for future references. Thus, series of testing is performed on the system
before it is already for implementation.

The development of software systems involves a series of production activities where opportunities
for injection of human errors are enormous. Errors may begin to occur at the very inception of the
process where the objectives may be erroneously or imperfectly specified as well as in later design
and development stages. Because of human in ability to perform and communicate with perfection,
software development is followed by assurance activities.
Quality assurance is the review of software products and related documentation for completeness,
correctness, reliability and maintainability. And of course it includes assurances that the system
meets the specification and the requirements for its intended use and performance, The various
levels of quality assurance are described in the following subsections.

a. DEPENDENCIES
This Library Management System is highly dependent on the Librarian for the entry of all book-id’s
in the Library Management System. This book-id will also be later used to check the availability of
the book in the library. This also helps in issuing the book to a particular student through the
barcode scanning method. If the entry is not made in the system then the book cannot be issued.

b. RISKS/ASSUMPTIONS
The risk in Library Management System is that when there is power failure the state of the database
should remain consistent that means the screen which lastly appeared before power failure occurred.
The database should also hold the data as it is. For eg. The librarian is making entry of books in the
system suddenly power failure occurred then the data which was filled by the librarian should
appear on the screen as it is. No data loss should occur.

c. TOOLS
For testing, the tool used is WinRunner. WinRunner software was an automated functional GUI
testing tool that allowed a user to record and playback User Interface (UI) interactions as test
scripts.

TEST SCHEDULE:

Actual End Actual Start Estimated End Estimated Particulars


Times Times Times Start Times

20 PM 8 AM 18 PM 10 AM Login

20 PM 8 AM 18 PM 10 AM Book
Trans.

Report Gen.

Test Case -:
LOGIN FORM:

Test Result Expected Result Test Case

Successful Software should display main Enter valid name and


window password & click on login
button
Successful Software should not display Enter invalid
main window

BOOK ENTRY FORM:

Test Expected Result Test Case


Result

Successful At first user have to fill all fields with proper data, On the click of
if any error like entering text data instead of ADD button
number or entering number instead of text is found
then it gives proper message otherwise Adds
Record to the Database.

Successful This deletes the details of book by using On the click of


Accession no. DELETE button

Successful Modified record are updated in databases by On the click of


clicking UPDATE button. UPDATE button

Successful Displays the details of book for entered Accession On the click of
no. , otherwise gives proper Error message. SEARCH button

Successful Clears all fields. On the click of


CLEAR button

Successful Exits the current book details form. On the click of


EXIT button

Successful Display the next form On the click of


NEXT button

BOOK RETURN FORM:


Test Results Expected Result Test Case

Successful At first user have to fill all fields with proper data, On the click of
if any error like entering text data instead of ADD button
number or entering number instead of text is
found then it gives proper message otherwise
Adds Record to the Database

Successful Which deletes the details of book by using On the click of


Register number DELETE button

Successful Modified records are Updated in Database by On the click of


clicking UPDATE button UPDATE button

Successful Displays the details of returning book. On the click of


Otherwise gives proper Error message SEARCH button

Successful Clears all fields On the click of


CLEAR button

Successful Exit the current book details form On the click of


EXIT button

Successful Display the next form On the click of


NEXT button

USER ACCOUNT FORM:


Test Expected Result Test Case
Result

Successful At first user have to fill all fields with proper data, On the Click of
if any error like entering text data instead of ADD button
number or entering number instead of text is
found then it gives proper message otherwise
Adds Record to the database

Successful This deletes the details of student by using On the Click of


Register no. DELETE button

Successful Modified records are updated in database by On the Click of


clicking UPDATE button UPDATE button

Successful Displays the details of book for entered Register On the Click of
no. Otherwise gives proper Error message SEARCH
button

Successful Clears all fields On the Click of


CLEAR button

Successful Exit the current book details form On the Click of


EXIT button

Successful Display the next form On the Click of


NEXT button

BOOK ISSUE FORM:


Test Result Expected Result Test Case

Successful At first user have to fill all fields with proper On the click of
data, if any error like entering text data instead of ADD button
number or entering number instead of text is
found then it gives proper message otherwise
Adds Record to the database
Successful This deletes the details of student by using On the Click of
Register no. DELETE button

Successful Modified records are updated in database by On the Click of


clicking UPDATE button UPDATE button

Successful Displays the details of book for entered Register On the Click of
no. Otherwise gives proper Error message SEARCH button

Successful Clears all fields On the Click of


CLEAR button

Successful Exit the current book details form On the Click of


EXIT button

Successful Display the next form On the Click of


NEXT button

BOOK RETURN FORM:


Test Result Expected Result Test Case

Successful At first user have to fill all fields with proper data, On the click of
if any Error like entering text data instead of ADD button
number or entering number instead of text is found
then it gives proper message otherwise Adds
Record to the Database

Successful Which deletes the details of book by using On the Click of


Register no. DELETE button

Successful Modified records are Updates to database by On the Click of


clicking UPDATE button. UPDATE button

Successful Displays the details of book returned book... On the Click of


Otherwise gives proper Error message SEARCH button

Successful Clears all fields On the Click of


CLEAR button

Successful Exit the current book details form On the Click of


EXIT button

Successful Display the next form On the Click of


NEXT button
LIBRARY MANAGEMENT SYSTEM
Conclusion: Here we have successfully created test plan document for Library Management
System.
EXPERIMENT NO 06

CASE STUDY: STUDY OF TESTING TOOLS (TEST RAIL, RATIONAL FUNCTIONAL


TESTER)

Aim : Case Study on Testing tool (TestRail, WinRunner and Rational Functional Tester).

Theory:

I. TESTRAIL
TestRail is a web-based test case management tool. It is used by testers, developers and team leads
to manage, track and organize software testing efforts. TestRail allows team members to enter test
cases, organize test suites, execute test runs and track their results, all from a modern and easy to
use web interface.
FEATURES OF TEST RAIL
1. Modern Test Management : Modern test management for your team in a central place.
2. Seamless Integration : Integrate with bug trackers, automated tests and more.
3. Easily Track Results : Execute your tests and track results that matter.
4. Increased Productivity : Fast and easy to use for a productive, happy team.
5. Powerful Reports & Metrics : Actionable reports, metrics and real-time insights.
6. Scalable and Customizable : Cloud or download, highly customizable & much more.

ADVANTAGES OF TEST RAIL


a. Manage test cases, suites and test runs
TestRail enables you to create, manage and organize test cases and suites within an optimized user
interface and application structure.
b. Boosting testing productivity
TestRail's todo lists, filters and email notifications help coordinate test runs and increase the
productivity and responsibility of testers. The goal is to make sure that every team member knows
his tasks at all times and that team leads can assign new tasks to testers depending on their
workload.
c. Real-time insights into your testing progress
To make important project decisions, it is critical to have access to detailed information about the
testing progress and test results. Questions such as “How many percent of a test run have we
successfully completed?”, “How are we progressing on the upcoming milestone?” or “Which tests
have been executed in the past 24 hours?” can only be answered efficiently by using a
comprehensive test case management software such as TestRail, and TestRail makes these details
readily available.
d. Organize and track software testing efforts
The organization and coordination of multiple parallel tests, be it for different projects or releases,
is often complex and time-consuming. To not lose track of your testing efforts, TestRail helps you
manage important software-specific data and structures such as project milestones and makes it
easy to integrate with bug tracking tools.

STEPS FOR USING TESTRAIL

1. The dashboard
After logging in to TestRail, the first page you usually see is the dashboard. The dashboard provides
you with an overview of available projects, recent project activities and your todos. When you
navigate to a project (by clicking on a project title), you switch to the project view and land on the
project's overview page, showing project details such as test suites, active test runs, project activity
and so on. Whenever you need to switch to another project, just return to the dashboard by clicking
the link in the upper left corner.

2. Test cases and suites


A test case in TestRail consists of a description of the test's prerequisites, a list of test steps and the
expected result. A test case can ideally be verified by a single tester in a short period of time and
confirms a specific functionality, documents a task or verifies a project artifact.
In TestRail, test cases are organized into test suites. A test suite is a collection of test cases and is
often created for specific project modules or areas. How you organize your test suites depends on
the size of your project. If you have a lot of test cases for a project module, it is recommended to
further break down your test suites and create suites for specific features or functionality. Ideally, a
test suite consists of 50-1000 test cases.

To further organize test cases, test cases of a suite can be grouped into so-called sections. Sections
are used to organize test cases into groups to make it easier for testers to identify related cases.
For example, if you use multiple test cases to verify a specific application dialog or web page, these
test cases should be grouped in a section. Depending on how complex your project is and how fine-
grained your test cases are, a section should ideally consist of 10-50 test cases.
3. Test runs and results
To run a test and enter test results for the cases you added, you start a test run for a particular test
suite. While a test suite is just like a plan that specifies how an application is tested, a test run is an
actual test you are conducting. For most projects you will most likely start multiple test runs for a
particular test suite over time. For example, if you are releasing multiple versions of a software
program, you might want to conduct a test run for each new release. Likewise, you can have
multiple test runs for a particular test suite active at the same time. This can make sense if you want
to execute a particular test suite for multiple configurations (such as different operating systems).
You can then start a test run for each different configuration you want to test against.
When you start a new test run (e.g. by clicking the Run a Test button in the toolbar of a test suite),
you can choose to either include all cases of a test suite or select the cases manually. If you
include all cases in a test run, new cases that you add to the test suite are also automatically added
to the run.

A run consists of individual tests for each case that you add. By default, each test has one of five
different statuses that are signaled in TestRail by specific colors. You can add a test result and
change the status of a test either by clicking the Add Result button on the test page, or by changing
it directly on the run page.
The following test statuses are available by default:
 Untested
By default, new tests have the status Untested. Once a test result has been added to a test, it
can never receive the Untested status again.
 Passed
A test is marked as Passed when a tester verified the test steps and the expected results.
 Failed
A tester marks a test as Failed if one of the specified test steps resulted in an error or if the
expected result differs from the actual test result.
 Retest
If a developer or tester determines that a test should be tested again, she marks the test as
Retest. E.g., if a test originally failed and the developer fixed the problem, the developer can
mark it to be retested.

 Blocked
The Blocked status is used to signal that a test cannot be executed currently because of some
external dependency (such as a bug that needs to be fixed before being able to complete to
test). It is often used in combination with the Retest status.
Once a test run has been completed, you can close it from the run's edit page. Tests of a closed run
cannot be edited or changed, making it ideal for archiving test runs. Additionally, if you change any
of the associated cases' attributes (such as the expected result), the change won't be applied to the
closed and archived run.

4. Projects and milestones


Projects are the main organizational unit in TestRail. It is generally recommended to create a
TestRail project for every real software project you want to manage within TestRail. All other data
such as test suites, runs, test results, milestones etc. are directly associated with a specific project.
See the following illustration to see how the different entities relate to each other:

You can also add your project milestones to TestRail. A milestone can be any project milestone you
deem to be important, such as a planned public software release, an internal test version or a new
beta release for an important customer. Once you have added your milestones to TestRail, you can
assign test runs to specific milestones. Assigning test runs to milestones has the advantage that you
can easily track the milestones' test results and progress separately. Especially if you are working
on multiple milestones in parallel or if you have many test runs active at the same time, managing
milestones within TestRail is a great help.
5. Test plans and configurations
When you need to manage multiple test runs and configurations for a single project, TestRail's test
plans come in handy. A test plan allows you to start multiple test runs at once, either if you have
many test suites or if you want to test against multiple configurations (where a configuration can be
anything you need to test your project against, such as different operating systems or web
browsers).
To create a test plan, simply click the Add Test Plan button from the Test Runs & Results page.
Now just select one or more test suites from the sidebar to add them to the plan. Just like you do
with a single test run, you can configure all properties of the test runs such as the name, the cases
you want to include and so on.

You often have to test a specific test run against multiple configurations such as operating systems
or web browser versions. To make it easier to create a separate test run for each configuration
combination, you can specify and select all configurations for your test runs within a plan. To do
this, simply click the Select Configurations link of a run and select or add your configurations.

6. Todos and notifications


Tests can be assigned to team members. You can either assign tests when a run is created or do so
afterwards from the run or test pages. Once a test has been assigned to a user, the test appears on the
user's todo list. Every user has its own todo list for each project she's working on, while the
Dashboard provides a quick way to see the user's todos for all projects. Another relevant feature are
email notifications. Email notifications help test owners to learn about test changes made by other
users.

7. Tracking progress and activity


Besides making it easier to manage test suites and enter test results, providing an easy way for all
team members to track the test progress is one of TestRail's most useful features. You can view the
test results and testing activity of runs, milestones and entire projects on the individual resource
pages.
You can choose between the status, activity and progress view on the test run and milestone pages
from the sidebar, while you can switch between the project history and test results on the project's
overview page. Additional reporting features can be found on the Reports tab.

II. WIN RUNNER

HP WinRunner 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 QuickTest 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 WinRunner 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 WinRunner versions 7.5, 7.6,
8.0, 8.2, 9.2—suggesting migration to HP Functional Testing software as a replacement.

Steps For Using WinRunner


Using Rapid Test Script wizard
Start->Program Files->Winrunner->winruner
 Select the Rapid Test Script Wizard (or) create->Rapid Test Script wizard
 Click Next button of welcome to script wizard
 Select hand icon and click on Application window and Cilck Next button
 Select the tests and click Next button
 Select Navigation controls and Click Next button
 Set the Learning Flow(Express or Comprehensive) and click Learn button
 Select start application YES or NO, then click Next button
 Save the Startup script and GUI map files, click Next button
 Save the selected tests, click Next button
 Click Ok button
 Script will be generated.then run the scripts. Run->Run from top
 Find results of each script and select tools->text report in Winrunner test results.

How to Run the Tests Using WinRunner


WinRunner run commands: User can run the tests in three modes:
 Verify run mode, to check the application
 Debug run mode, to debug the test script
 Update run mode, to update the expected results
Verify
User can use the Verify mode to check the application. WinRunner compares the current response of the
application to its expected response. Any discrepancies between the current and expected responses are
captured and saved as verification results.

Debug
User can Use the Debug mode to help to identify bugs in a test script. Running a test in Debug mode is the
same as running a test in Verify mode, except that debug results are always saved in the debug folder.
Because only one set of debug results is stored, the Run Test dialog box does not open automatically when
the user run a test in Debug mode. When finishing running a test in Debug mode, the Test Results window
does not open automatically. But the user can see the result.

Update
Use the Update mode to update the expected results of a test or to create a new expected results folder.
Before running a test in Verify mode, user must have expected results for the checkpoints created. If the
user needs to update the expected results of the test, user must run the test in Update mode. User can update
the expected results for a test in one of two ways:
 By globally overwriting the full existing set of expected results by running the entire test using a
Run command.
 By updating the expected results for individual checkpoints and synchronization points using the
Run from Arrow command or a Step command.

Conclusion: Hence, we studied the testing tool TestRail and WinRunner.


EXPERIMENT NO 07
CASE STUDY: STUDY OF WEB TESTING TOOL

Aim: Study of web testing tool: Selenium

Theory:

Selenium is a set of different software tools each with a different approach to supporting test automation.
Most Selenium QA Engineers focus on the one or two tools that most meet the needs of their project,
however learning all the tools will give you many different options for approaching different test
automation problems. The entire suite of tools results in a rich set of testing functions specifically geared
to the needs of testing of web applications of all types. These operations are highly flexible, allowing
many options for locating UI elements and comparing expected test results against actual application
behavior. One of Selenium’s key features is the support for executing one’s tests on multiple browser
platforms.
Selenium first came to life in 2004 when Jason Huggins was testing an internal application at Thought
Works. Being a smart guy, he realized there were better uses of his time than manually stepping through
the same tests with every change he made. He developed a Javascript library that could drive
interactions with the page, allowing him to automatically rerun tests against multiple browsers. That
library eventually became Selenium Core, which underlies all the functionality of Selenium Remote
Control (RC) and Selenium IDE.
Selenium IDE Download and Installation
Before taking off, there is one thing that needs to be in place prior to the installation; Mozilla Firefox.
You can download it from here => Mozilla Firefox download.
Step #1: Selenium IDE download: Open the browser (Firefox) and enter the URL
– http://seleniumhq.org/ . This would open the official Selenium head quarter website. Navigate to the
“Download” page; this page embodies all the latest releases of all the selenium components. Refer the
following figure.

Step #2: Move under the selenium IDE head and click on the link present. This link represents the latest
version of the tool in the repository. Refer the following figure.
Step #3: As soon as we click on the above link, a security alert box would appear so as to safeguard
our system against potential risks. As we are downloading the plug-in from the authentic website, thus
click on the “Allow” button.

Step #4: Now Firefox downloads the plug-in in the backdrop. As soon as the process completes,
software installation window appears. Now click on the “Install Now” button.

Step #5: After the installation is completed, a pop up window appears asking to re-start the Firefox.
Click on the “Restart Now” button to reflect the Selenium IDE installation.

Step #6: Once the Firefox is booted and started again, we can see selenium IDE indexed under menu bar
-> Web Developer -> Selenium IDE.

Step #7: As soon as we open Selenium IDE, the Selenium IDE window appears.
Features of Selenium IDE

#1. Menu Bar

Menu bar is positioned at the upper most of the Selenium IDE window. The menu bar is typically
comprised of five modules.
A) File Menu

File Menu is very much analogous to the file menu belonging to any other application. It allows user to:
 Create new test case, open existing test case, save the current test case.
 Export Test Case As and Export Test Suite As in any of the associated programming
language compatible with Selenium RC and WebDriver. It also gives the liberty to the user
to prefer amid the available unit testing frameworks like jUnit, TestNG etc. Thus an IDE
test case can be exported for a chosen union of programming language, unit testing
framework and tool from the selenium package.
 Export Test Case As option exports and converts only the currently opened Selenium IDE
test case.
 Export Test Suite As option exports and converts all the test cases associated with the
currently opened IDE test suite.
 Close the test case.

The Selenium IDE test cases can be saved into following format:
 HTML format
The Selenium IDE test cases can be exported into following formats/programming languages.
 java (IDE exported in Java)
 rb (IDE exported in Ruby)
 py (IDE exported in Python)
 cs (IDE exported in C#)
B) Edit Menu

Edit menu provides options like Undo, Redo, Cut, Copy, Paste, Delete and Select All which are
routinely present in any other edit menu. Amongst them, noteworthy are:
 Insert New Command – Allows user to insert the new command/test step anywhere within
the current test case.
 Insert New Comment – Allows user to insert the new comment anywhere within the current
test case to describe the subsequent test steps.
C) Actions Menu

Actions Menu equips the user with the options like:


 Record – Record options fine tunes the Selenium IDE into the recording mode. Thus, any
action made by the user on the Firefox browser would be recorded in IDE.
 Play entire test suite – The option plays all the Selenium IDE test cases associated with
the current test suite.
 Play current test case – The option plays the current Selenium IDE test case that has been
recorded/created by the user.
 Pause / Resume – User can Pause/Resume the test case at any point of time while
execution.
 Toggle Breakpoint – User can set one or multiple breakpoint(s) to forcefully break the
execution at any particular test step during execution.
 Set / Clear Start Point – User can also set start point at any particular test step for
execution. This would enable user to execute the test case from the given start point for the
subsequent runs.
 To deal with the page/element loads, the user can set the execution speed from fastest to
lowest with respect to the responsiveness of the application under test.
D) Options Menu

Options menu privileges the user to set and practice various settings provided by the Selenium IDE.
Options menu is recommended as one of the most important and advantageous menu of the tool.
Options Menu is primarily comprised of the following four components which can be sub-divided into
the following:

Options
Selenium IDE Options dialog box
To launch Selenium IDE Options dialog box, follow the steps:
1. Click on Options Menu
2. Click on the Options
A Selenium IDE Options dialog box appears. Refer the following figure.
Selenium IDE Options dialog box aids the user to play with the general settings, available formats,
available plug-ins and available locators types and their builders.

Selenium IDE Plugins


Plug-ins tab displays the supported Firefox plug-ins installed on our instance of Selenium IDE. There
are a number of plug-ins available to cater different needs, thus we can install these add-ons like we do
other plug-ins. One of the recently introduced plug-in is “File Logging”. In the end of this tutorial, we
will witness how to install and use this plug-in.
With the standard distribution, Selenium IDE comes with a cluster of following plug-ins:
 Selenium IDE: Ruby Formatters
 Selenium IDE: Python Formatters
 Selenium IDE: Java Formatters
 Selenium IDE: C# Formatters
These formatters are responsible to convert the HTML test cases into the desired programming formats.
------------

Formats
Formats option allows user to convert the Selenium IDE test case (selenese commands) into desired
format.
E) Help Menu
As Selenium has a wide community and user base, thus various documentations, release notes, guides
etc. are handily available. Thus, the help menu lists down official documentation and release notes to
help the user.

2. Base URL Bar


Base URL bar is principally same as that of an address bar. It remembers the previously visited
websites so that the navigation becomes easy later on.

Now, whenever the user uses “open” command of Selenium IDE without a target value, the base URL
would be launched on to the browser.

Accessing relative paths


To access relative paths, user simply needs to enter a target value like “/download” along with the
“open” command. Thus, the base URL appended with “/downloads”
(http://docs.seleniumhq.org/resources) would be launched on to the browser. The same is evident in the
above depiction.

3. Editor
Editor is a section where IDE records a test case. Each and every user action is recorded in the editor in
the same order in which they are performed.

The editor in IDE has two views, namely:


1) Table View
It is the default view provided by Selenium IDE. The test case is represented in the tabular format.
Each user action in the table view is a consolidation of “Command”, “Target” and “Value” where
command, target and value refers to user action, web element with the unique identification and test
data correspondingly. Besides recording it also allows user to insert, create and edit new Selenese
commands with the help of the editor form present in the bottom.
2) Source View

The test case is represented in the HTML format. Each test step is considered be a row <tr> which is a
combination of command, target and value in the separate columns <td>. Like any HTML document,
more rows and columns can be added to correspond to each Selenese command.

5. Test case pane


At the instance we open Selenium IDE interface, we see a left container titled “Test case” containing an
untitled test case. Thus, this left container is entitled as Test case pane.
Test case pane contains all the test cases that are recorded by IDE. The tool has a capability of opening
more than one test case at the same time under test case pane and the user can easily shuffle between
the test cases. The test steps of these test cases are organized in the editor section.
Selenium IDE has a color coding ingredient for reporting purpose. After the execution, the test case in
marked either in “red” or “green” color.
• Red color symbolizes the unsuccessful run i.e. failure of the test case.
• Green color symbolizes the successful run of the test case
• It also layouts the summary of the total number of test cases executed with the number of failed
test cases.
• If we execute a test suite, all the associated test cases would be listed in the test case pane. Upon
execution, the above color codes would be rendered accordingly.
Conclusion: The Selenium Tool is studied.

EXPERIMENT NO 08
CASE STUDY: STUDY OF BUG TRACKING TOOL

Aim: Study of bug tracking tool: Bugzilla

Theory:

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

 Advanced search capabilities


 E-mail Notifications
 Modify/file Bugs by e-mail
 Time tracking
 Strong security
 Customization
 Localization
How to log-in to Bugzilla
Step 1) To create an account in Bugzilla or to login into the existing account go to New
Account or Log in option in the main menu.

Step 2) now, enter your personal details to log into Bugzilla

1. User ID
2. Password
3. And then click on "Log in"

Step 3) You are successfully logged into Bugzilla system


Creating a Bug-report in Bugzilla

Step 1) To create a new bug in Bugzilla, visit the home-page of Bugzilla and click
on NEW tab from the main menu

Step 2) In the next window

1. Enter Product
2. Enter Component
3. Give Component description
4. Select version,
5. Select severity
6. Select Hardware
7. Select OS
8. Enter Summary
9. Enter Description
10. Attach Attachment
11. Submit

NOTE: The mandatory fields are marked with *.


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

1. Large text box


2. URL
3. Whiteboard
4. Keywords
5. Tags
6. Depends on
7. Blocks
8. Attachments

Step 5) In the same window if you scroll down further. You can select deadline date and also
status of the bug.Deadline in Bugzilla usually gives the time-limit to resolve the bug in
given time frame.

Create Graphical Reports

Graphical reports are one way to view the current state of the bug database. You can run
reports either through an HTML table or graphical line/pie/bar-chart-based one. The idea
behind graphical report in Bugzilla is to define a set of bugs using the standard search
interface and then choosing some aspect of that set to plot on the horizontal and vertical axes.
You can also get a 3-dimensional report by choosing the option of "Multiple Pages".
Reports are helpful in many ways, for instance if you want to know which component has the
largest number of bad bugs reported against it. In order to represent that in the graph, you can
select severity on X-axis and component on Y-axis, and then click on generate report. It will
generate a report with crucial information.
The graph below shows the Bar chart representation for the Bugs severity in
component "Widget Gears". In the graph below, the most severe bug or blockers in
components are 88 while bugs with normal severity are at top with 667 numbers.

Likewise, we will also see the line graph for %complete Vs Deadline
Step 1) To view your report in a graphical presentation,
 Click on Report from Main Menu
 Click on the Graphical reports from the given option

Step 2) Let's create a graph of % Complete Vs Deadline

In here on the vertical axis we chose % Complete and on our horizontal axis we
chose Deadline. This will give the graph of amount of work done in percentage against the
set-deadline.
Now, set various option to present reports graphically

1. Vertical Axis
2. Horizontal Axis
3. Multiple Images
4. Format- Line graph, Bar chart or Pie chart
5. Plot data set
6. Classify your bug
7. Classify your product
8. Classify your component
9. Classify bug status
10. Select resolution
11. Click on generate report

The image of the graph will appear somewhat like this

Browse Function

Step 1) To locate your bug we use browse function, click on Browse button from the main
menu.

Step 2) As soon as you click on browse button a window will open saying "Select a product
category to browse" as shown below, we browse the bug according to the category.
 After clicking the browse button
 Select the product "Sam's Widget" as such you have created a bug inside it
Step 3) It opens another window, in this click on component "widget gears". Bugzilla
Components are sub-sections of a product. For instance, here our product is SAM'S
WIDGET whose component is WIDGET GEARS.

Step 4) when you click on the component, it will open another window. All the Bugs created
under particular category will be listed over-here. From that Bug-list, choose your Bug#ID to
see more details about the bug.

It will open another window, where information about your bug can be seen more in detail. In
the same window, you can also change the assignee, QA contact or CC list.

How to use Simple search option in BugZilla


Bugzilla provides two ways of searching bugs, they are Simple Search and Advance
Search methods.

Step 1) We will first learn the "Simple Search" method. Click on search button from the
main menu and then follow these steps
1. Click on "Simple Search" button
2. Choose the status of the Bug – choose Open if you are looking the bug in Open status and
closed for bug in closed status
3. Choose your category and component, and you can also put keywords related to your bug
4. Click on the search
Step 2) Here we will search for both option open and closed status, first we have selected
closed status for bug and clicked search button.

For closed status, it fetched 12 bugs.

Step 3) Likewise we have searched for Open status as well, and it has fetched 37 bugs
related to our queries.

Also, at the bottom of the screen you have various options like how you want to see your
bug - an XML format, in Long format or just Time summary. Apart from that you can
also use other option like send mail to bug assignee, change several bugs at once or
change column of the screen, etc.

How to use Advance Search in BugZilla

Step 1) After Simple search we will look into Advanced Search option for that you have to
follow the following steps.

1. Click on advanced search option


2. Select option for summary, how you want to search
3. Enter the keyword for your bug- for example, Widget gears twisted
4. Select the category of your Bug under classification, here we selected Widget
5. Choose your product under which your Bug was created- Sam's Widget
6. Component- Widget gears
7. Status- Confirmed
8. Resolution
Step 2) Once you select all the option, click on search button. It will detect the bug you
created

The advance search will find your bug, and it will appear on the screen like this

How to use preferences in BugZilla

Preferences in Bugzilla is used to customize the default setting made by Bugzilla as per our
requirement. There are mainly five preferences available
 General Preferences
 E-mail Preferences
 Saved Searches
 Account Information
 Permissions

General Preferences

For general preferences, you have various option like changing Bugzilla general
appearance, position of the additional comment box, automatically add me to cc, etc.
Here we will see how to change the general appearance of the Bugzilla.
There are many changes you can do which are self-explanatory, and you can choose the
option as per your requirement.
Step 1)

 To set the background Skin of Bugzilla


 Go to Bugzilla general preference (Skin)
 Select the option you want to see as a change and submit the change ( DuskàClassic )
 A message will appear on the window saying changes have been saved, as soon as you
submit the changes

After the skin preference is changed to Classic from Dusk, the back-ground color of the
screen appears white

Likewise, for other default settings changes can be done.


E-mail preferences

E-mail preferences enable you to decide how to receive the message and from whom to
receive the messages.
Step 1) To set the e-mail preferences

1. Click on e-mail services


2. Enable or disable the mail to avoid receiving notification about changes to a bug
3. Receiving mail when someone asks to set a flag or when someone sets a flag you asked for
4. When and from whom you want to receive mail and under which condition. After marking
your option at the end, submit the changes.
Saved Searches Preference

Saved searches preference gives you the freedom to decide whether to share your bug or not
to share.
Step 1) Click on saved searches, it will open window with the option like editbugs, don't
share, can confirm, etc. Choose the option as per your need.

Step 2) We can run our bug from "Saved Searches".

 Go to Saved Searches under preference


 Click on the "Run" button

As soon as you run your search from Saved Searches it opens your bug as shown below

Step 3) In the same window we can also choose specific users with whom we want to share
the search by marking or unmarking the checkbox against the users

CONCLUSION: Hence the Bugzilla tool is studied.


EXPERIMENT NO 09
CASE STUDY: STUDY OF TEST MANAGEMENT TOOL

AIM: Study of test management tool: Test Director

THEORY:
Test Director simplifies and organizes test management by giving you systematic control over the
testing process. It helps you create a framework and foundation for your testing workflow. Test
Director helps you maintain a project database of tests that cover all aspects of your application's
functionality. Every test in your project is designed to fulfill a specified testing requirement of
your application. To meet the various goals of a project, you organize the tests in your project
into unique groups. Test Director provides an intuitive and efficient method for scheduling and
executing test sets, collecting test results, and analyzing the data.
Test Director also features a sophisticated system for tracking software defects, enabling you to
monitor defects closely from initial detection until resolution. By linking Test Director to your
e-mail system, defect tracking information can be shared by all software development, quality
assurance, and customer support and information systems personnel. Test Director guides you
through the requirements specification, test planning, test execution, and defect tracking phases of
the testing process. By integrating all the tasks involved in software testing, it helps ensure that
your customers receive the highest quality software.

The Test Management Process

Test management with Test Director involves four phases:

Specify Requirements: Analyze your application and determine your


testing requirements.
Plan Tests: Create a test plan, based on your testing requirements.
Execute Tests: Create test sets and perform test runs.

Track Defects: Report defects detected in your application and track how
repairs are progressing.
Starting Test Director

You can launch Test Director on your workstation from your Web browser.

To start Test Director:

1 Open your Web browser and type your Test Director URL (http://[Server name]/[virtual
Directory name]/default.htm). Contact your system administrator if you do not have the
correct path.

2 Click the Test Director link.


The first time you run Test Director, the software is downloaded to your computer.
Subsequently, Test Director automatically carries out a version check. If it detects a newer
version, it downloads it to your machine. Once the Test Director version has been checked
and updated if necessary, the Test Director Login window opens.
3 In the Domain list, select a domain. You can select the default domain called DEFAULT.
This domain includes the Test Director Demonstration project called Test Director Demo. If
you are not sure which domain to select, contact your Test Director administrator.
4 In the Project list, select a project. If the projects you want does not appear in the Project list
refer to the Test Director knowledge base you can select the Test Director Demonstration
project called Test Director Demo.

5 In the User ID box, type or select your user name. If you do not know your user name,
contact your system administrator. Note that the User ID list is client machine-dependent, so
you need to type your user name the first time you log in to Test Director.
6 In the Password box, type in the password assigned to you by your system administrator. (If
you are the first person to log in as admin, you do not need a password the first time you log
in.)
7 Click the Login button. Test Director opens and displays the module (Requirements, Test
Plan, Test Lab, Defects, and Collaboration) in which you last worked during your previous
Test Director session.

8 To exit and return to the Test Director Login window, click the Logout button located on the
upper-right side of the window.

REQUIREMENTS PHASE

Filtering Records

You can filter Test Director data to display only those records meeting the criteria that you
define. You can assign a single item (such as "Failed") or a logical expression (such as
"Passed or Failed") to a filter. Only records meeting all the criteria of the filter appear in the
grid or tree. You can also define multiple filters. For example, you can define the Status
filter as "Failed" and the Tester filter as "David or Mark". Test Director Displays only failed
test runs performed by David or Mark.

To define a filter:

1 Click the appropriate Set Filter/Sort button. The Filter dialog box opens and displays the
Filter tab.
2 To set a filter condition for a specific column, click the corresponding Filter Condition box.
3 Define the filter condition. If applicable, select items from the list. You can add operators to
create a logical expression.
4 Click OK to close the Select Filter Condition dialog box.
5 To add cross filters, click the advanced link. For more information, see
"Advanced/Cross Filtering Records," on page 30.
6 Click OK to close the Filter dialog box.
Test Director applies the filter(s) and displays the filter description. For a grid, Test Director
also displays the condition in the grid filter box, which appears under each column name.

To attach a file:

1 In the Attachments dialog box, click the File button. The Open dialog box opens.
2 Choose a file name and click Open. The file name appears in the Attachments list,
together with the size and date modified. An icon for the application associated with
the file appears next to the file name.
3 In the Description box, add any comments related to the attached file.

Creating the Testing Requirements Outline

The Quality Assurance manager uses the testing scope to determine the overall testing
requirements for the application under test. She/he defines requirement topics and assigns them
to the QA testers in the test team. Each QA tester uses Test Director to record the requirement
topics they are responsible for. Requirement topics are recorded in the Requirements module
by creating a requirements tree. The requirements tree is a graphical representation of your
requirements specification, displaying the hierarchical relationship between different
requirements.
For example, consider a flight reservation application that lets you manage flight scheduling,
passenger bookings, and ticket sales. The QA manager may define your major testing
requirements as: login operations, database operations, send fax operations, check security
capabilities, graph and reports operations, UI checking operations, and help. For the complete
example, refer to the Test Director Demo project.

Defining Requirements

For each requirement topic, a QA tester creates a list of detailed testing requirements in the
requirements tree. For example, the requirement topic Application Security may be broken
down into the following requirements: Each requirement in the tree is described in detail, and
can include any relevant attachments. The QA tester assigns the requirement a priority level
which is taken into consideration when the test team creates the test plan.

Analyzing your Requirements Specification

The QA manager reviews the requirements, ensuring that they meet the testing scope
defined earlier. She/he assigns the requirement a Reviewed status once it is approved.

TEST PLANNING

Creating a Requirements Tree

You specify requirements by creating a requirements tree.

To create a requirements tree:

1 Click the New Requirement button on the Requirements module toolbar. Alternatively,
choose Requirements> New Requirement. Test Director adds a new requirement to the tree
with a default name New Requirement.
2 Type a name for the new requirement and press Enter. Note that a requirement name cannot
include the following characters: \ ^ *.
3 Add details for the requirement.
4 In the Description pane, type a description of the requirement.
5 Click the Attachments button, or choose View> Attachments, to add an attachment to the
new requirement. An attachment can be a file, URL, snapshot of your application, an image
from the Clipboard, or system information. Test Director places a clickable attachment icon
next to the requirement name in the requirements tree
6 Click the Tests Coverage button, or choose View> Tests Coverage, to add tests coverage
for the requirement. Tests coverage defines the test or tests in the test plan tree that address
the requirement and enable you to link you’re testing requirements to tests. You can only
define tests coverage after you have created tests during test planning.

7 Add additional requirements to the tree:


➤ Click the New Requirement button to add the next requirement underneath the
previous one, at the same hierarchical level.
➤ Click the New Child Requirement button to add the next requirement underneath the
previous one, at a lower hierarchical level.

Creating a Test Plan Tree

You define a hierarchical framework for your test plan by creating a test plan tree.

To create a test plan tree:

1 Click the New Folder button, or choose Planning> New Folder. The New Folder dialog
box opens.
2 In the Folder Name box, type a name for the subject. Note that a folder name cannot
include the characters \ or ^. Click OK. The new subject folder appears under the Subject
entry in the test plan tree.
3 In the Description tab, type a description of the subject.
4 Click the Attachments tab to add an attachment to the new folder if necessary. An
attachment can be a file, URL, snapshot of your application, an image from the Clipboard, or
system information.
5 Create as many additional subjects at the main level as you want.
6 Choose a main subject folder from the test plan tree to create a subfolder underneath it.
7 Click New Folder and repeat steps 2 to 6.
TEST EXECUTION

Creating Test Sets

Start by creating test sets and choosing which tests to include in each set. A test set is a group
of tests in a Test Director project database designed to achieve specific testing goals. In the
sample flight reservation application, you could create a set of sanity tests that checks the
basic functionality of the application. You could include, for example, tests that check the
login mechanism, and tests that open, create, and fax orders (flight reservations).

Scheduling Test Runs

Test Director enables you to control the execution of tests in a test set. You can set
conditions, and schedule the date and time for executing your tests. You can also set the
sequence in which to execute the tests. For example, run test2 only after test1 has finished,
and run test3 only if test1 passed.
Running Tests Manually

Once you have defined test sets, you can begin executing the tests. When you run a test
manually, you execute the test steps you defined in test planning. You pass or fail each step,
depending on whether the application's actual results match the expected output.
For example, suppose you are testing the process of booking a flight in the sample flight
reservation application. You open the application, create a new order, and book a flight,
following the instructions detailed by the test steps.

Running Tests Automatically

Once you have defined test sets, you can begin executing the tests. You can select all the tests
in a test set or specific tests. Your selection can include both automated and manual tests.
When you run an automated test, Test Director opens the selected testing tool automatically,
runs the test, and exports the test results to Test Director. When you run a manual test, an e-
mail is sent to a designated tester, requesting him or her to run the manual test.

Analyzing Test Results

Following a test run, you analyze test results. Your goal is to identify failed steps and to
determine whether a defect has been detected in your application, or if the expected results
of your test need to be updated. Validate test results regularly by viewing run data and by
generating Test Director reports and graphs.
DEFECT TRACKING

Adding Defects

When you find a defect in the application under test, you submit a defect to the Test Director
project. The project stores defect information in a defect repository that can be accessed by
authorized users, such as members of the development, quality assurance, and support teams.
For example, suppose you are testing a flight reservation application. You just ran a test set
that checks the Fax Order functions. One of the test runs revealed a defect in the "Send
Signature with order" function. You would submit a defect to the project. Note that you can
associate this new defect with the test you ran for future reference.

Reviewing New Defects

Review all new defects in the project and decide which ones to fix. This task is usually
performed by the quality assurance or project manager. Change the status of a new defect to
Open, and assign it to a member of the development team. You can also locate similar defects.
If duplicate defects appear in the project, change their status to either Closed or Rejected, or
delete them from the project.

Repairing Open Defects

Fix the Open defects. This involves identifying the cause of the defects, and modifying and
rebuilding the application. These tasks are performed by software developers. When a defect
is repaired, assign it the status Fixed.
For example, suppose the defect detected in the flight reservation application's Fax Order
functions was repaired in a new software build. You would update the effect status from Open
to Fixed.

Testing a New Application Build

Run tests on the new build of the application. If a defect does not reoccur, assign it the status
Closed. If a defect is detected again, assign it the status Reopen, and return to the previous
stage, "Repairing Open Defects." This task is usually performed by the Quality Assurance or
project manager.

Analyzing Defect Data

You view data from defect reports to see how many defects were repaired, and how many still
remain open. As you work, you can save settings that are helpful in the defect-tracking
process, and reload them as needed. Reports and graphs enable you to analyze the progress of
defect repairs, and how long defects have been residing in a project.

GENERATING REPORTS

Test Director Reports display information about test requirements coverage, the test plan, test
runs, and defect tracking. Test Director Reports help you assess the progress of defining
requirements and tests coverage, the test plan, test runs, and defect tracking. Use reports to
assist in determining testing priorities, defect repair schedules, and in setting software release
dates. You can generate reports at any time during the testing process. Reports can be
generated from each Test Director module. You can display reports using their default
settings, or you can customize them. When customizing a report, you can apply filters and
sort conditions, and determine the layout of the fields in the report. You can further
customize the report by adding sub-reports. You can save the settings of your reports as
favorite views and reload them as needed. You can also save your reports as text files or
HTML documents. Test Director enables you to generate reports from the Requirements
module, Test Plan module, Test Lab module, and Defects module.

CONCLUSION: Hence the TEST DIRECTOR tool is studied.


EXPERIMENT NO 10
CASE STUDY: STUDY OF OPEN SOURCE TESTING TOOL

AIM: Study of Open Source Testing Tool: Test Link

THEORY:

AIM: Study of any open source-testing tool (e.g. Test Link)


THEORY:
Test-link is most widely used web based open source test management tool. It synchronizes both
requirements specification and test specification together. User can create test project and
document test cases using this tool. With Test-Link you can create an account for multiple users
and assign different user roles. Admin user can manage test cases assignment task.
It supports both automated and manual execution of Test cases. The testers can generate Test
Plan and Test Report in a fraction of the time with this tool. It supports test reports in various
formats like Excel, MS word, and HTML formats. Apart from these, it also supports integration
with many popular defect tracking system like JIRA, MANTIS, BUGZILLA, TRAC, etc. Since
it is a web based tool, multiple users can access its functionality at the same time with their
credentials and assigned roles.

Advantages of Test Link

It supports multiple projects


Easy export and import of test cases
Easy to integrate with many defect management tools
Automated test cases execution through XML-RPC
Easy filtration of test cases with version, keywords, test case ID and version
Easy to assign test cases to multiple users
Easy to generate test plan and test reports in various formats
Provide credentials to multiple users and assign roles to them

Installation Steps:-

Here are the steps needed for successful installation:

Unpack the release file into directory inside your document root

For installing the DB you can either choose the command line tools available in your
MySQL installation or any MySQL Database Client.

Create a new empty MySQL database.

mysql>create database testkink;


Install the sql into the newly created database.

mysql -u <user> -p<password> <dbname>


<<testlinkdir>/install/sql/testlink_create_tables.sql

e.g.: "mysql -u testlink -ppass testlink


</var/www/html/testlink/install/sql/testlink_create_tables.sql"

Edit <testlinkdir>/config.inc.php to match your configuration. See Configuration


for more.
On Linux or UNIX you must change the permissions of the templates_c directory to be
writable by the webserver. From the TestLink root directory run

chmod 777 gui/templates_c

Log into TestLink! Default credentials are:

user: admin; pass: admin

Login to Test Link

Step 1: Open the Testlink home-page and enter the login details

1. Enter the userID – admin


2. Enter the password
3. Click on the login tab

Creating a Test Project

Step 1: In the main window click on Test Project Management, it will open another window
Step 2: Click on tab "create" to create a new project.

Step 3: Enter all the required fields in the window like category for test project, name of the
project, prefix, description, etc. After filling all necessary details, click on tab "Create" at the end
of the window.

Creating a Test Plan

Test plan holds the complete information like scope of testing, milestone, test suites and
test cases. Once you have created a Test Project, next step is to create Test plan.
Step 1: From the home-page, click on Test Plan Management from home-page
Step 2: It will open another page, at the bottom of the page click on a tab "Create"

Step 3: Fill out all the necessary information like name, description, create from existing test
plan, etc. in the open window, and click on "create tab"

Step 4: Guru 99 Test Plan is created successfully

Creating a Testcase
Test case holds a sequence of test steps to test a specific scenario with expected result.
Below steps will explain how to create a test-case along with test steps.
Step 1: Click on the test suite folder on the left side of the panel under folder tree structure
Step 2: Click on the setting icon in the right side panel. List of test case operations will be
displayed on the right side panel
Step 3: New window will open, to create test cases click on create button in test-case operations

Step 4: Enter the details in the test case specification page

Step 5: After entering the details, click on "create" button to save the details. The test-case for
Guru99 is created successfully
Step 6: Click on test-case from the folder as shown above, it will open a window. Click on
"create steps" button in test case. It will open a test case step editor

Step 7) It will open another window on the same page, in that window you have to enter the
following details

1. Enter the step-action for your test case


2. Enter the details about the step action
3. Click save it and add another step action OR click save and exit tab if there is no more test step
to add
Step 8) Once you save and exit the test step, it will appear like this

Assigning test case to test plan


For test case to get execute, it should be assign to test plan. Here we will see how we can
assign a test-case to test plan.

Step 1) Click on the setting icon on the test panel. It will show the list of operations.

Step 2) Click on "Add to Test Plans"

Step 3) New window will open, search your project "Guru99"

1. Mark the check box against your test plan


2. Click on add button
This will add your test case to your Test Plan.

Creating Users and Assigning Roles in TestLink


Testlink provides User management and authorization features.

Step 1: From the Testlinks home-page, click on users/roles icon from the navigation bar

Step 2: Click Create

Step 3: Fill out all the users details and click the "Save" button
Here in the list we can see the users have been created

Step 4: Allotting test project role to the user,

1. Click on "Assign Test Project Roles" tab


2. Choose the project name
3. Select the users role from the drop down

Writing Requirements:

Step 1: From the navigation bar select the "Requirements Link", it opens the Requirement page.

Step 2: From the requirement page, on the right side of the panel click on "create" button

Step 3: A new window will open, enter all the details like

a. Document ID
b. Title name
c. Requirement description
d. And Click "Save" button

For the type, you can choose the option from the drop-down- here we chose "User Requirement
Specification"

Step 4: It should create Requirement specification and displayed on the left side panel under
project "Guru99".
Step 5: Select the setting button from requirements specification home-page. It will open another
window.
Step 6: Click "Create" tab under Requirement Operations.

Step 7: Fill out all the specified details and click the "Save" button
a. Enter the document ID
b. Enter the title name
c. Enter the description
d. Enter the status-whether it's in draft, rework, review, not testable, etc. Here we
chose valid
e. Enter the type – user interface, non-functional, informational, feature, etc. Here
we chose use case
f. Enter the number of test cases needed
g. Enter "Save" button at the end

Note: To add more requirements you can mark the check-box and click save button

On the left side of the panel, we can see that requirement is added.

Assigning requirement to test-cases

In Testlink, Requirement can be connected to test cases. It is very crucial feature in order
to track test coverage based on requirements. In test reports, you can verify which requirements
are not covered and act on them to apend in test suites for maximum test coverage
Step 1: From test specification section open any single test case and click on requirement icon

Step 2: To assign requirements specification to test case you have to follow the following steps

1. Scroll the drop down box to select the requirements specification


2. Mark the requirement check box
3. Click on "assign" tab

After clicking on "assign" tab, a window will appear stating "Assigned Requirement."
Executing a test case
In TestLink, we can run a test case and change execution status of a test case. Status of a
test-case can be setto "blocked" "Passed", or "failed". Initially, it will be in "not run" status but
once you have updated it, it cannot be altered to "not run" status again.
Step 1: From the navigation bar click on the "Test Execution" link. It will direct you to the Test
Execution Panel.

Step 2: Pick the Test case you want to run from the left side panel

Step 3: Once you have selected the test cases, it will open a window.

Step 4: Follow the following steps

1. Enter the notes related to test case executed


2. Select its status

Step 5: On the same page, you have to fill similar detail about the execution of test-case. Fill the
details, select the status and then click on "save execution".
Generating Test Reports
Test link supports various test report formats like

HTML
MS Word
MS excel
OpenOffice Writer
OpenOffice calc

Step 1: From the navigation bar, click on Test Reports option

Step 2: From the left side panel, select "Test Report" link

Step 3: To generate a report follow the following steps

1. Mark and unmark the option you want to highlight in your test report
2. click on your project folder

The test report will look like this


Export Test case/ Test Suite

Testlink provides the features to export test projects/test suites in your Testlink and then you can
import them into another Testlink project on different server or system. In order to do that you
have to follow the following step

Step 1: Choose the test case you want to export in the Test specification page

Step 2: Now on the right-hand side of the panel click on the setting icon, it will display all
the operations that can be performed on the test case.
Step 3: Click the "export" button

Step 4: It will open another window, mark the option as per requirement and click on the export
tab
Following XML is generated

Importing Test case/ Test suite

Step 1: Select the Test suite folder inside which you want to import the test case

Step 2: Click on the setting icon on the right hand-side of the panel, it will display all the
operations that can be executed on the test suite/test case
Step 3: Click on the import button in the test case operations list as

Step 4: Browse and attach the xml test case file that you have exported from test link and click
on upload button.
1. Use the browse option to attach the XML test case file that you have exported from
testlink
2. Click on upload file

When you upload a file, it will open window stating import test cases

Step 5: Test case will be uploaded and displayed on the right-hand side of the panel

CONCLUSION: Hence we studied open source-testing tool Test Link

You might also like