S. No.

List of Practical Page Sign

No.
1 A program written in C- language for Matrix Multiplication 1
fails Introspect the causes for its failure and write down the
possible reasons for its failure.

2 Write programs in C- Language to demonstrate the 4

working of the following a. constructs: i) do.. .while ii)
while….do iii) if…else iv) switch v) for

3 A program written in C- language for Matrix Addition 12

´Introspect the causes for its failure and write down the
possible reasons for its failure.

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

5 Write the test cases for GMAIL 15

6(a) Study of Any Testing Tool( Win Runner) 17, 19
Create a script by recording in Context Sensitive mode
that tests the process of opening
an order in the Flight Reservation application.

6(b) Purpose of this exercise is to Study Synchronizing test 20

7 Study of any web testing tool (e.g. Selenium) 21

8 Study of Any Test Management Tool (Test Director , 24

BUGBIT)

9 Study of Any Bug Tracking Tool (Bugzilla) 26

10 Study of any open source testing tool (Test Link) 30

Index
 Page |1

Experiment-1

Objective:

A program written in c language for matrix multiplication fails ―Introspect the causes for its
failure and write down the possible reasons for its failure.

Program logic:

1. Read the no. of rows (r1) and cols (c1) of a matrix a[3][3].
2. Read the no. of rows (r2) and cols. (c2) of matrix b[3][3].
3. If c1=r2 then display matrix multiplication is possible otherwise display impossible
4. If c1=r2 then read the elements into both the matrices a andb.
5. Initialize a resultant matrix c[3][3] with 0.
6. Calculate c[i][j] = c[i][j] + a[i][k] * b[k][j].
7. Display the resultant matrix

Procedure:

1. Create : Open editor vi x.c write a program after that press ESC and: wq for save and
Quit.
2. Compile: gcc x.c.
3. Execute: . / a.out.

Source code :

#include<stdio.h>
#include<conio.h>
void main()
{
int a[3][3],b[3][3],c[3][3],i,j,k,m,n,p,q;
clrscr();
printf(―Enter matrix no.of rows & cols);
scanf(―%d%d‖,&m,&n);
printf(― Enter 2matrix no.of rows & cols‖) ;
scanf(―%d%d‖,&p,&q);
printf("\n enter the matrix elements"); for(i=0;i<m;i++)
{
for(j=0;j<n;j++)
{
scanf("%d",&a[i][j]);
}
}
 Page |2

printf("\n a matrix is\n"); for(i=0;i<m;i++)

{
for(j=0;j<n;j++)
{
printf("%d\t",a[i][j]);
}
printf("\n");
}
for(i=0;i<p;i++)
{
for(j=0;j<q;j++)
{
scanf("%d\t",&b[i][j]);
}
}
printf("\n b matrix is\n"); for(i=0;i<p;i++)
{
for(j=0;j<q;j++)
{
printf("%d\t",b[i][j]);
}
printf("\n");
}
for(i=0;i<m;i++)
{
for(j=0;j<q;j++)
{
c[i][j]=0; for(k=0;k<n;k++)
{
c[i][j]=c[i][j]+a[i][k]*b[k][j];
}
}
}
for(i=0;i<m;i++)
{
for(j=0;j<q;j++)
{
printf("%d\t",c[i][j]);
}
printf("\n");
}
getch();
}
 Page |3

Input and output

Input Actual Output
Matrix1:
111
111
111 33 3
Matrix2: 3 3 3
111 33 3
111
111

Test cases:
Test case no: 1
Test case name: Equal no. of rows & cols
Input Expected output Actual output Remarks
Matrix1 rows & cols= 3
3
Matrix2 rows & cols= 3
3
Matrix1:
111 333 333
111 3 3 3 3 3 3 Success
111
Matrix2: 333 333
111
111
111

Test case no: 2

Test case name: Cols of 1stmatrix is not equal to rows of 2nd matrix.
Input Expected output Actual output Remarks
Matrix1 rows & cols= 2 2 Operation can‘t be fail
Matrix2 rows & cols= 3 2 performed

Input Expected output Actual output Remarks

Matrix1 rows & cols= 2 2 fail
Matrix2 rows & cols= 2 2
1234567891 2222222222
2234567891 2222222221
234567891 22222221533
213242424 56456475457
 Page |4

Experiment-2

Objective
Write programs in C- Language to demonstrate the working of the following a. constructs: i)
do.. .while ii) while….do iii) if…else iv) switch v) for

Program logic:

1. do …while
declare i,
intialize n to 5 and j to 0.
read i value .
loop :
if (i%2== 0)
print i as even number. And increment i and j value.
otherwise print i as odd number . and increment i and j value .
if i>0 and j<n go to loop

2. while
declare i,
intialize n to 5 and j to 0.
read i value .
loop : if i>0 and j<n.
if i%2 == 0 print i as even number and increment i and j value.
otherwise print i as odd number and increment i and j value .
go to loop

3. if….else
declare i value.
read i value .
if i%2== 0 print i as even number.
otherwise odd number.

4. switch
declare a,b,c.
read i value.
print enter a,b values .
read a,b values . switch ( case value = i)
if case value = 1
c is sum of a and b
if case value =2
 Page |5

c is difference of a and b
if case value = 3
c is multiplication of a and b.
if case value = 4
c is division of a and b .

5. for loop
declare i value.
read i value .
loop initialize i to 1 if i<=5
print i as even number
else
print as odd number.
increment i value

Procedure:
1. Create : Open editor vi x.c write a program after that press ESC and: wq for save and
Quit.
2. Compile: gcc x.c.
3. Execute: . / a.out.

Source code:

1. do…while

#include <stdio.h>
void main ()
{
int i, n=5,j=0;
printf(“enter a no”);
scanf(“%d”,&i);
do
{ if(i%2== 0)
{
rintf("%d", i);
printf("is a even no.");
i++;
j++;
}
else
{
printf("%d", i);
 Page |6

printf("is a odd no.\n");

i++;
j++;
}
}
while(i>0&&j<n);
getch();

2. while

#include<stdio.h>
#include <conio.h>
void main ()
{
int i,n=5,j=1;
printf(―enter a no‖);
scanf(“%d”,&i);
while (i>0 && j<n)
{ if(i%2== 0)
{
printf(“%d”,i);
printf(“is a even number”);
i++; j++;
}
else
{
printf(“%d”,i);
printf(“its a odd number”);
i++;
j++;
}
}
getch();

3. if….else

#include<stdio.h>
#include <conio.h>
void main ()
{
int I,c;
printf(“enter a number “);
scanf(“%d” ,&i); if(i%2==0)
 Page |7

{
printf(“%d” ,i);
printf({“s a even number”);
}
else
{
printf(“%d”,i);
printf(“is a odd number”);
}
}

4. switch

#include<stdio.h>
#include <conio.h>
void main()
{
int a,b,c;
printf(“1.add/n 2.sub /n 3.mul /n 4.div /n enter your choice”);
scanf(“%d‖”, &i);
printf(“enter a,b values”);
scanf(“%d%d” ,&a,&b);
switch(i)
{
case 1: c=a+b;
printf(“the sum of a & b is: %d”,c);
break;
case 2: c=a-b;
printf(”the diff of a & b is: %d” ,c);
break;
case 3: c=a*b;
printf(“the mul of a & b is: %d”,c);
break;
case 4: c=a/b;
printf(“the div of a & b is: %d‖ ,c);
break:;
default:
printf(“enter your choice”);
break;
}
getch();
}

5. for
 Page |8

#include<stdio.h>
#include <conio.h>
main()
{
int i;
printf(“enter a no”);
scanf(“%d‖”,&i);
for(i=1;i<=5;i++)
{ if(i%2== 0)
{
printf(“%d”, i);
printf(“is a even no”);
i++;
}
else
{
printf(“%d”, i);
printf(“is a odd no”);
i++;
}
}
getch();
}

Input/output

1. do…while

INPUT ACTUAL OUTPUT

2 2 is even number
3 is odd number
4 is even number
5 is odd number
6 is even number

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

Input Expected output Actual output Remarks

2 2 is even number 2 is even number
3 is odd number 4 3 is odd number 4
 Page |9

is even number is even number

5 is odd number 5 is odd number Success
6 is even number 6 is even number

Test case no: 2

Test case name: Negative values within a range

Input Expected output Actual output Remarks

2 -2 is even number -2 is an even number fail
-3 is odd number
-4 is even number
-5 is odd number
-6 is even number

Test case no: 3

Test case name: Out of range values testing

Input Expected output Actual output Remarks

1234567891222222222222 123456789122222222213 234567891222222215 fail

2. while

Input Actual output

2 2 is even number
3 is odd number
4 is even number
5 is odd number
6 is even number

Test cases:

Test case no: 1

Test case name: Positive values within range

Input Expected output Actual output Remarks

2 2 is even number 2 is even number success
3 is odd number 3 is odd number
4 is even number 4 is even number
5 is odd number 5 is odd number
6 is even number 6 is even number

Test case no:2

Test case name: Negative values within a range
 P a g e | 10

Inp Expected output Actual output Remarks

ut
- -2 is even number -2 is an even number fail
2 -3 is odd number
-4 is even number
-5 is odd number
-6 is even number

Test case no: 3

Test case name: Out of range values testing
Input Expected output Actual output Remarks
1234567891222222222222 123456789122222222213 234567891222222215 fail

1. if …else
Input Actual output
2 2 is even number
3 is odd number
4 is even number
5 is odd number
6 is even number

Test cases:
Test case no: 1

Test case name: Positive values within range

Input Expected output Actual output Remarks
2 2 is even number 2 is even number success
3 is odd number 3 is odd number
4 is even number 4 is even number
5 is odd number 5 is odd number
6 is even number 6 is even number

Test case no:2

Test case name: Negative values within a range.

Input Expected output Actual output Remarks

-2 -2 is even number -2 is an even number fail
-3 is odd number
-4 is even number
-5 is odd number
-6 is even number

Test case no: 3

Test case name: Out of range values testing
Input Expected output Actual output Remarks
1234567891222222222222 123456789122222222213 234567891222222215 fail
 P a g e | 11

2. switch

Input Actual output

Enter Ur choice: 1
Enter a, b Values: 3, 2 The sum of a & b is:5

Enter Ur choice: 2 The diff of a & b is: 1

Enter a, b Values: 3, 2

Enter Ur choice: 3 The Mul of a & b is: 6

Enter a, b Values: 3, 2

Enter Ur choice: 4 The Div of a & b is: 1

Enter a, b Values: 3, 2
 P a g e | 12

Experiment-3

Objective
A program written in C- language for Matrix Addition´Introspect the causes for its failure and
write down the possible reasons for its failure.

Addition of Two Matrices

#include <stdio.h>
int main()
{
int m, n, c, d, first[10][10], second[10][10], sum[10][10];
printf("Enter the number of rows and columns of 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 elements of second matrix\n");
for (c = 0; c < m; c++)
for (d = 0 ; d < n; d++)
scanf("%d", &second[c][d]);
printf("Sum of entered matrices:- \n");
for (c = 0; c < m; c++)
{ for (d = 0 ; d < n; d++) {
sum[c][d] = first[c][d] + second[c][d];
printf("%d\t", sum[c][d]);
}
printf("\n");
}
return 0;
}

output:
enter the number of row=2
enter the number of column=2
enter the first matrix element= 1 2 3 4
enter the second matrix element= 1 2 3 4
multiply of the matrix=2 4
6 8
Failure cases:
output:
Enter the size of a: 2 3
 P a g e | 13

Enter the size of b: 2 3

Matrix addition is not possible.
Reason to fail: to do addition of matrices the number of columns in matrix ―a[] should be
equal t number of rows in matrix ―b‖.

Enter the size of a: p q

Enter the size of b: q s
Matrix multiplication is not possible.
Reason to fail: to do addition of matrices the number of columns in matrix ―a‖ should be
equal t number of rows in matrix ―b‖, and rows & columns should be integer values.

Enter the size of a:

Enter the size of b:
Matrix multiplication is not possible.
Reason to fail: to do addition of matrices the number of columns in matrix ―a‖ should be
equal tonumb r of rows in matrix ―b‖, and rows & columns should be integer values.

Enter the size of a:

Enter the size of b:
Matrix multiplication is not possible.
Reason to fail: size of buffer will be not be sufficient to handle this addition.

Enter the size of a: -1 -2

Enter the size of b: -2 3
Matrix addition is not possible.
Reason to fail: to do addition of matrices the number ofcolumns in matrix ―a‖ should be
equal to number of rows in matrix ―b‖, and rows& columns should be positive integer
values.
 P a g e | 14

Experiment-4

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

BUGS IN ATM SYSTEM:

 Machine is accepting ATM card.

 Machine is rejecting expired card.
 Successful entry of PIN number.
 Unsuccessful operation due to enter wrong PIN number 3 times.
 Successful selection of language.
 Successful selection of account type.
 Unsuccessful operation due to invalid account type.
 Successful selection of amount to be withdrawn.
 Successful withdrawal.
 Expected message due to amount is greater than day limit.
 Unsuccessful withdraw operation due to lack of money in ATM.
 Expected message due to amount to withdraw is greater than possiblebalance.
 Unsuccessful withdraw operation due to click cancel after insert card.
 P a g e | 15

Experiment-5

Objective
Write the test cases for GMAIL

Test Case for Gmail – Inbox Functionality

1. Verify that a newly received email is displayed as highlighted in the Inbox section.
2. Verify that a newly received email has correctly displayed sender email Id or name, mail
subject and mail body (trimmed to a single line).
3. Verify that on clicking the newly received email, the user is navigated to email content.
4. Verify that the email contents are correctly displayed with the desired source formatting.
5. Verify that any attachments are attached to the email and are downloadable.
6. Verify that the attachments are scanned for viruses before download.
7. Verify that all the emails marked as read are not highlighted.
8. Verify that all the emails read as well as unread have a mail read time appended at the
end on the email list displayed in the inbox section.
9. Verify that count of unread emails is displayed alongside ‘Inbox’ text in the left sidebar
of Gmail.
10. Verify that unread email count increases by one on receiving a new email.
11. Verify that unread email count decreases by one on reading an email (marking an email
as read).
12. Verify that email recipients in cc are visible to all users.
13. Verify that email recipients in bcc are not visible to the user.
14. Verify that all received emails get piled up in the ‘Inbox’ section and get deleted in
cyclic fashion based on the size availability.
15. Verify that email can be received from non-Gmail email Ids like – yahoo, Hotmail etc.

Test Cases for GMail – Compose Mail Functionality

1. Verify that on clicking ‘Compose’ button, a frame to compose a mail gets displayed.
2. Verify that user can enter email Ids in ‘To’, ‘cc’ and ‘bcc’ sections and also user will get
suggestions while typing the emailds based on the existing emailIds in user’s email list.
3. Verify that the user can enter multiple comma-separated emailIds in ‘To’, ‘cc’ and ‘bcc’
sections.
4. Verify that the user can type Subject line in the ‘Subject’ textbox.
5. Verify that the user can type the email in the email-bodysection.
6. Verify that users can format mail using editor-options provided like choosing font-
family, font-size, bold-italic-underline, etc.
7. Verify that the user can attach file as an attachment to the email.
8. Verify that the user can add images in the email and select the size for the same.
9. Verify that after entering emailIds in either of the ‘To’, ‘cc’ and ‘bcc’ sections, entering
Subjectline and mail body and clicking ‘Send’ button, mail gets delivered to intended
receivers.
 P a g e | 16

10. Verify that sent mails can be found in ‘Sent Mail’ sections of the sender.
11. Verify that mail can be sent to non-gmail emailIds also.
12. Verify that all sent emails get piled up in the ‘Sent Mail’ section and get deleted in cyclic
fashion based on the size availability.
13. Verify that the emails composed but not sent remain in the draft section.
14. Verify the maximum number of email recipients that can be entered in ‘To’, ‘cc’ and
‘bcc’ sections.
15. Verify the maximum length of text that can be entered in the ‘Subject’ textbox.
16. Verify the content limit of text/images that can be entered and successfully delivered as
mail body.
17. Verify the maximum size and number of attachment that can be attached with an email.
18. Verify that only the allowed specifications of the attachment can be attached with an
email/
19. Verify that if the email is sent without Subject, a pop-up is generated warning user about
no subject line. Also, verify that on accepting the pop-up message, the user is able to
send the email.
 P a g e | 17

Experiment 6
Objective
Study of Any Testing Tool (Win Runner)

Study of win runner testing tool:

1. Win Runner is a program that is responsible for the automated testing of
software.
2. Win Runner is a Mercury Interactive enterprise functional testing tool for
Microsoft windows applications.

Importance of automated testing:

1. Reduced testing time Consistent test procedures
2. Reduces QA cost
3. Improved testing productivity

Win runner uses:

1. Win Runner uses TSL, or Test Script Language. The goal of Win Runner is to make
sure business processes are properly carried out.
2. Another impressive aspect of Win Runner is the ability to record various interactions,
and transform them into scripts. Win Runner is designed for testing graphical user
interfaces. When the user make an interaction with the GUI, this interaction can be
recorded. Re-cording the interactions allows determining various bugs that need to be
fixed. When the test is completed, Win Runner will provide with detailed information
regarding the results.

Win runner testing modes

1. Context Service: Context Sensitive mode records your actions on the application
being tested in terms of the GUI objects you select (such as windows, lists, and
buttons), while ignoring the physical location of the object on the screen. Every time
you perform an operation on the application being tested, a TSL statement describing
the object selected and the action performed is generated in the test script. As you
record, Win Runner writes a unique description of each selected object to a GUI map.
2. Analog: Analog mode records mouse clicks, keyboard input, and the exact x and y
coordinates travelled by the mouse. When the test is run, Win Runner retraces the
mouse tracks. Use Analog mode when exact mouse coordinates are important to your
test, such as when testing a drawing application.

Using win runner window

Before you begin creating tests, you should familiarize yourself with the Win Runner main
window.
To start Win Runner:
 P a g e | 18

Choose Programs>Win Runner>Win Runner on the Start menu.

The first time you start Win Runner, the Welcome to Win Runner window and the What’s
New in Win Runner help open. From the Welcome window you can create a new test, open
an existing test, or view an overview of Win Runner in your default browser. If you do not
want this window to appear the next time you start Win Runner, clear the Show on Startup
check box. To show the Welcome to Win Runner window upon startup from within Win
Runner, choose Settings > General Options, click the Environment tab, and select the
Show Welcome screen checkbox.

The Main Win Runner Window

The main Win Runner window contains the following key elements:
 Win Runner title bar
 Menu bar, with drop-down menus of Win Runner commands
 Standard toolbar, with buttons of commands commonly used when running a test
 User toolbar, with commands commonly used while creating a test
 Status bar, with information on the current command, the line number of the insertion
point and the name of the current results folder
 The Standard toolbar provides easy access to frequently performed tasks, such as
opening, executing, and saving tests, and viewing test results
 P a g e | 19

Experiment 6A
Create a script by recording in Context Sensitive mode that tests the process of opening an
order in the Flight Reservation application. You will create the script

1. Start Win Runner.

If Win Runner is not already open, choose Programs > Win Runner > Win Runner on the
Start menu.

2. Open a new test.

If the Welcome window is open, click the New Test button. Otherwise, choose File > New. A
new test window opens in Win Runner.

3. Start the Flight Reservation application and log in.

Choose Programs > Win Runner > Sample Applications > Flight 1A on the Start menu. In the
Login window, type your name and the password mercury, and click OK. The name you type
must be at least four characters long. Position the Flight Reservation application and Win
Runner so that they are both clearly visible on your desktop.

4. Start recording in Context Sensitive mode.

In WinRunner, choose Create > Record—Context Sensitive or click the Record button on the
toolbar. From this point on, Win Runner records all mouse clicks and keyboard input. Note
that the text, ―Rec|| appears in blue above the recording button. This indicates that you are
recording in Context Sensitive mode. The status bar also informs you of your current
recording mode.

5. Open order #3.

In the Flight Reservation application, choose File > Open Order. In the Open Order dialog
box, select the Order No. check box. Type 3 in the adjacent box, and click OK. Watch how
Win Runner generates a test script in the test window as you work.

6. Stop recording.
In Win Runner, choose Create > Stop Recording or click the Stop button on the toolbar.

7. Save the test.

Choose File > Save or click the Save button on the toolbar. Save the test as lesson3 in a
convenient location on your hard drive. Click Save to close the Save Test dialog box. Note
that Win Runner saves the lesson3 test in the file system as a folder, and not as an individual
file. This folder contains the test script and the results that are generated when you run the
test.

Output: Win Runner Test Results window is open and displays the test results.
 P a g e | 20

Conclusion: Recording in Context Sensitive mode is cleared and test results are also seen.

Experiment 6B
Aim: Purpose of this exercise is to Study Synchronizing test

Synchronizing test
When you run tests, your application may not always respond to input with the same speed.
For example, it might take a few seconds:
1. To retrieve information from a database
2. For a window to pop up
3. For a progress bar to reach 100%
4. For a status message to appear

Input: Creating a test

In this first exercise you will create a test that opens a new order in the Flight Reservation
application and inserts the order into a database.
1. Start Win Runner and open a new test.
If Win Runner is not already open, choose Programs > Win Runner > Win Runner on the
Start menu. If the Welcome window is open, click the New Test button. Otherwise, choose
File > New. A new test window opens.
2. Start the Flight Reservation application and log in.
Choose Programs > Win Runner > Sample Applications > Flight 1A on the Start menu. In the
Login window, type your name and the password mercury, and click OK. Reposition the
Flight Reservation application and Win Runner so that they are both clearly visible on your
desktop.
3. Start recording in Context Sensitive mode.
Choose Create > Record Context Sensitive or click the Record button on the tool bar.Win
Runner will start recording the test.
4. Create a new order.
Choose File > New Order in the Flight Reservation application.
5. Fill in flight and passenger information.
6. Insert the order into the database.
Click the Insert Order button. When the insertion is complete, the ―Insert Done‖ message
appears in the status bar.
7. Delete the order.
Click the Delete Order button and click Yes in the message window to confirm the deletion.
8. Stop recording.
Choose Create > Stop Recording or click the Stop button.
9. Save the test.
Choose File > Save. Save the test as lesson4 in a convenient location on your hard drive.
Click Save to close the Save Test dialog box.
 P a g e | 21

Output: Win Runner Test Results window is open and displays the test results.
Conclusion: Importance of Synchronizing test is cleared and test results are also seen.

Experiment 7
Selenium
Objective
Study of any web testing tool (Selenium)

Study of Selenium web testing tool:

1. Selenium is a robust set of tools that supports rapid development of test automation for
web- based applications. Selenium provides a rich set of testing functions specifically geared
to the needs of testing of a web application. These operations are highly flexible, allowing
many options for locating UI elements and comparing expected test results against actual
application behaviour.
2. One of Selenium’s key features is the support for executing one’s tests on multiple browser
platforms.
3. Selenium Components
4. Selenium is composed of three major tools. Each one has a specific role in aiding the
development of web application test automation.

Selenium-RC provides an API (Application Programming Interface) and library for each of
its supported languages: HTML, Java, C#, Perl, PHP, Python, and Ruby. This ability to use
Selenium-RC with a high-level programming language to develop test cases also allows the
automated testing to be integrated with a project’s automated build environment.

Selenium-Grid
Selenium-Grid allows the Selenium-RC solution to scale for large test suites or test suites that
must be run in multiple environments. With Selenium-Grid, multiple instances of Selenium-
RC are running on various operating system and browser configurations; Each of these when
launching register with a hub. When tests are sent to the hub they are then redirected to an
available Selenium-RC, which will launch the browser and run the test. This allows for
running tests in parallel, with the entire test suite theoretically taking only as long to run as
the longest individual test.

1. Tests developed on Firefox via Selenium-IDE can be executed on any other supported
browser via a simple Selenium-RC command line.
2. Selenium-RC server can start any executable, but depending on browser security set-tings
there may be technical limitations that would limit certain features.

Flexibility and Extensibility

Selenium is highly flexible. There are multiple ways in which one can add functionality to
Selenium’s framework to customize test automation for one’s specific testing needs. This is,
 P a g e | 22

perhaps, Selenium’s strongest characteristic when compared with proprietary test automation
tools and other open-source solutions. Selenium-RC support for multiple programming and
scripting languages allows the test writer to build any logic they need into their automated
testing and to use a preferred programming or scripting language of one’s choice.
Selenium-IDE allows for the addition of user-defined user extensions for creating additional
commands customized to the user’s needs. Also, it is possible to re-configure how the
Selenium- IDE generates its Selenium-RC code. This allows users to customize the generated
code to fit in with their own test frameworks. Finally, Selenium is an Open Source project
where code can be modified and enhancements can be submitted for contribution.

Test Suites
A test suite is a collection of tests. Often one will run all the tests in a test suite as one
continuous batch job. When using Selenium -IDE, test suites also can be defined using a
simple HTML file. The syntax again is simple. An HTML table defines a list of tests where
each row defines the file system path to each test. An example tells it all.
<html>
<head>
<title>Test Suite Function Tests – Priority 1</title></head>
<body>
<table>
<tr><td><b>Suite Of Tests</b></td></tr>
<tr><td><a href=‖./Login.html‖>Login</a></td></tr>
<tr><td><a href=‖./SearchValues.html>‖ Test Searching for Values</a></td></tr>
<tr><td><a href=‖./SaveValues.html‖>Test Save</a></td></tr>
</table></body>
</html>
A file like this would allow running the tests all at once, one after another, from the
Selenium-IDE.
Test suites can also be maintained when using Selenium-RC. This is done via programming
and can be done a number of ways. Commonly Junit is used to maintain a test suite if one is
using Selenium-RC with Java. Additionally, if C# is the chosen language, Nun it could be
employed. If using an interpreted language like Python with Selenium-RC than some simple
programming would be involved in setting up a test suite. Since the whole reason for using
Sel-RC is to make use of programming logic for your testing this usually isn’t a problem.

Few typical Selenium commands.

1. open – opens a page using a URL.

2. click/clickAndWait – performs a click operation, and optionally waits for a new page to
load.
 P a g e | 23

3. verifyTitle/assertTitle – verifies an expected page title.

4. verifyTextPresent – verifies expected text is somewhere on the page.
5. verifyElementPresent – verifies an expected UI element, as defined by its HTML tag, is
present on the page.
6. verifyText – verifies expected text and it’s corresponding HTML tag are present on the
page.
7. verifyTable – verifies a table’s expected contents.
8. waitForPageToLoad – pauses execution until an expected new page loads. Called
automatically when clickAndWait is used.
9. waitForElementPresent – pauses execution until an expected UI element, as defined by
its HTML tag, is present on the page.
 P a g e | 24

Experiment 8
Bugbit
Objective
Study of Any Test Management Tool (Test Director, BUGBIT)

Study of test director and test management tool:

Test Director is a global test management solution which provides communication,
organization, documentation and structure to the testing project.

Test Director is used for

1. Mapping Requirements to User acceptance test cases
2. Test Planning by placing all the test cases and scripts in it.
3. Manual testing by defining test steps and procedures
4. Test Execution status
5. Defect Management

The Test Director Testing Process

Test Director offers an organized framework for testing applications before they are
deployed. Since test plans evolve with new or modified application requirements, you need a
central data repository for organizing and managing the testing process. Test Director guides
through the requirements specification, test planning, test execution, and defect tracking
phases of the testing process. The Test Director testing process includes four phases:

Specifying Requirements
1. Requirements are linked to tests and defects to provide complete traceability and aid the
decision- making process
2. See what percent of requirements are covered by tests
3. 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
4. Import from Microsoft Word or third-party RM tool

Planning Tests
1. The Test Plan Manager enables to divide application according to functionality.
Application can be divided into units, or subjects, by creating a test plan tree.
2. Define subjects according to:
3. Application functionality-such as editing, file operations, and reporting
4. Type of testing-such as functional, user interface, performance, and load
5. As the tests are also linked to defects, this helps ensure compliance with testing
requirements throughout the testing process.
 P a g e | 25

Running Tests
As the application constantly changes, using test lab, run manual and automated tests in the
project to locate defects and assess quality.
1. By creating test sets and choosing which tests to include in each set, test suite can be
created? A test set is a group of tests in a Test Director Project database designed to achieve
specific testing goals.
Tests can be run manually or scheduled to run automatically based on application
dependencies

Tracking Defects
Locating and repairing application defects efficiently is essential to the testing process.
Defects can be detected and added during all stages of the testing process. In this phase you
per-form the following tasks:
1. This tool features a sophisticated mechanism for tracking software defects, enabling
Testing Team and the project Team to monitor defects closely from initial detection until
resolution
2. By linking Test Director to e-mail system, defect tracking information can be shared by all
Development and Management Teams, Testing and Wipro Software Quality Assurance
personnel.
 P a g e | 26

Experiment 9
Bugzilla
Objective
Study of any bug tracking tool (Bugzilla)

Study of Bugzilla and bug tracking tool:

Bugzilla is a Bug Tracking System that can efficiently keep track of outstanding bugs in a
product. Multiple users can access this database and query, add and manage these bugs.
Bugzilla essentially comes to the rescue of a group of people working together on a product
as it enables them to view current bugs and make contributions to resolve issues. Its basic
repository nature works out better than the mailing list concept and an organized database is
always easier to work with.

Advantage of Using Bugzilla:

1. Bugzilla is very adaptable to various situations. Known uses currently include IT support
queues, Systems Administration deployment management, chip design and development
problem tracking (both pre- and-post fabrication), and software and hardware bug tracking
for luminaries such as Redhat, NASA, Linux-Mandrake, and VA Systems. Combined with
systems such as CVS, Bugzilla provides a powerful, easy to use solution to configuration
management and replication problems.

2. Bugzilla can dramatically increase the productivity and accountability of individual

employees by providing a documented workflow and positive feedback for good
performance. Ultimately, Bugzilla puts the power in user’s hands to improve value to
business while providing a usable framework for natural attention to detail and knowledge
store to flourish.

The bugzilla utility basically allows to do the following:

1. Add a bug into the database
2. Review existing bug reports
3. Manage the content

Bugzilla is organized in the form of bug reports that give all the information needed about a
particular bug. A bug report would consist of the following fields.
1. Product–>Component
2. Assigned to
3. Status (New, Assigned, Fixed etc)
4. Summary
 P a g e | 27

5. Bug priority
6. Bug severity (blocker, trivial etc)
7. Bug reporter

Using Bugzilla:
Bugzilla usage involves the following activities Setting Parameters and Default Preferences
1. Creating a New User
2. Impersonating a User
3. Adding Products
4. Adding Product Components
5. Modifying Default Field Values
6. Creating a New Bug
7. Viewing Bug Reports

Setting Parameters and Default Preferences:

When we start using Bugzilla, we’ll need to set a small number of parameters and
preferences. At a minimum, we should change the following items to suit out particular need:
1. Set the maintainer
2. Set the mail_delivery_method
3. Set bug change policies
4. Set the display order of bug reports

To set parameters and default preferences:

1. Click Parameters at the bottom of the page.
2. Under Required Settings, add an email address in the maintainer field.
3. Click Save Changes.
4. In the left side Index list, click Email.
5. Select from the list of mail transports to match the transport we‗re using. If evaluating a
click2try application, select test. If using SMTP, set any of the other SMTP options for your
environment. Click Save Changes.
6. In the left side Index list, click Bug Change Policies.
7. Select On for comment on create, which will force anyone who enters a new bug to enter a
comment, to describe the bug. Click Save Changes.
8. Click Default Preferences at the bottom of the page.
9. Select the display order from the drop-down list next to the When viewing a bug, show
comments in this order field. Click Submit Changes.

Creating a new user

 P a g e | 28

Before entering bugs, make sure we add some new users. We can enter users very easily,
with a minimum of information. Bugzilla uses the email address as the user ID, because users
are frequently notified when a bug is entered, either because they entered the bug, because
the bug is assigned to them, or because they’ve chosen to track bugs in a certain project.

To create a new user:

1. Click users.
2. Click adds a new user.
3. Enter the login name, in the form of an email address.
4. Enter the real name, a password, and then click add.
5. Select the group access options. We’ll probably want to enable the following options in
the row titled user is a member of these groups:
6. Can confirm
7. Edit bugs
8. Edit components
9. Click update when done with setting options.

Impersonating a User:
Impersonating a user is possible, though rare, that we may need to file or manage a bug in an
area that is the responsibility of another user when that user is not available. Perhaps the user
is on vacation, or is temporarily assigned to another project. We can impersonate the user to
create or manage bugs that belong to that user.
Adding Products
We’ll add a product in Bugzilla for every product we are developing. To start with, when we
first login to Bugzilla, we’ll find a test product called TestProduct. We should delete this
and create a new product.

To add a product:
1. At the bottom of the page, click Products.
2. In the TestProduct listing, click Delete.
3. Click Yes, Delete.
4. Now click Add a product.
5. Enter a product name, such as Widget Design Kit.
6. Enter a description.

Viewing Bug Reports

Eventually, we’ll end up with thousands of bugs listed in the system. There are several ways
to view the bugs. The easiest is to click the My Bugs link at the bottom of the page. Because
we’ve only got one bug reported, we’ll use the standard Search function.

To find a bug:
1. Click Reports.
 P a g e | 29

2. Click the Search link on the page, not the one in the top menu. This opens a page titled
Find a Specific Bug.
3. Select the Status.
4. Select the Product.
5. Enter a word that might be in the title of the bug.
6. Click Search. If any bugs meet the criteria that we have entered, Bugzilla displays them in
a list summary.
7. Click the ID number link to view the full bug report.

Modifying Bug Reports

Suppose we want to change the status of the bug. We’ve reviewed it and have determined
that it belongs to one of the users we have created earlier.
 P a g e | 30

Experiment 10
Test Link
Objective
Study of any open source testing tool (Test Link).

Study of test link open source testing tool

Test link is an open source test management tool. It enables creation and organization of test
cases and helps manage into test plan. Allows execution of test cases from test link itself. One
can easily track test results dynamically, generate reports, generate test metrics, prioritize test
cases and assign unfinished tasks. It‘s a web based tool with GUI, which provides an ease to
develop test cases, organize test cases into test plans, execute these test cases and generate re-
ports. Test link exposes API, written in PHP, can help generate quality assurance dashboards.
The functions like AddTestCase ToTestPlan,
Assign Requirements, Create Test Case etc. helps create and organize test cases per test plan.
Functions like GetTestCasesForTestPlan, GetLastExecutionResult allows one to create
quality assurance dashboard. TestLink enables easily to create and manage Test cases as well
as organize them into Test plans. These Test plans allow team members to execute Test cases
and track test results dynamically, generate reports, trace software requirements, prioritize
and assign tasks. Read more about implemented features and try demo pages.

Overall structure
There are three cornerstones: Product, Test Plan and User. All other data are relations or
attributes for this base. First, definition of a couple of terms that are used throughout the
documentation.
Products and Test Plans
1. Product: A Product is something that will exist forever in TestLink. Products will under-go
many different versions throughout their lifetimes. Product includes Test Specification with
Test Cases and should be sorted via Keywords.
2. Test Plan: Test Plans are created when you‗d like to execute test cases. Test plans can be
made up of the test cases of one or many Products. Test Plan includes Builds, Test Case Suite
and Test Results.
3. User: A User has a Role that defines available Test Link features.

Test Case Categorization

Test Link breaks down the test case structure into three levels Components, Categories, and
test cases. These levels are persisted throughout the application.
 P a g e | 31

1. Component: Components are the parents of Categories. Each Component can have many
2. Categories.
3. Category: Categories are the parents of test cases. Each Category can have many test cases.
4. Test Case: Test cases are the fundamental piece of TestLink.
5. Test Specification: All Components, Categories and test cases within Product.
6. Test Case Suite: All Components, Categories and test cases within Test Plan.

Test Specification Creating Test Cases

Tester must follow this structure: Component, Category and test case. At first you create
Component(s) for your Product. Component includes Categories. Category has the similar
meaning but is second level of Test Specification and includes just Test Cases. User can also
copy or move Test Cases.

Test Cases have following parts:

1. Title: could include either short description or abbreviation (e.g. TL-USER-LOGIN)
2. Summary: should be really short; just for overview.
3. Steps: describe test scenario (input actions); can also include precondition and cleanup
information here.
4. Expected results: describe checkpoints and expected behaviour a tested Product or system.

Deleting Test Cases

Test cases, Categories, and Components may be deleted from a test plan by users with lead
permissions from the delete test cases screen. Deleting data may be useful when first creating
a test plan since there are no results. However, Deleting test cases will cause the loss of all
results associated with them. Therefore, extreme caution is recommended when using this
functionality.

Requirements relation
Test cases could be related with software/system requirements as n to n. The functionality
must be enabled for a Product. User can assign Test Cases and Requirements via link Assign
Requirements in the main screen.

Test Plans
Test plan contains name, description, collection a chosen test cases, builds, test results,
milestones, tester assignment and priority definition.

Creating a new Test Plan

Test Plans may be deleted from the Create test plan page (link Create Test Plan) by users
with lead privileges. Test plans are the basis for test case execution. Test plans are made up
of test cases imported from Products at a specific point of time. Test plans can only be
created by users with lead privileges. Test plans may be created from other test plans. This
allows users to create test plans from test cases that at a desired point in time. This may be
 P a g e | 32

necessary when creating a test plan for a patch. In order for a user to see a test plan they must
have the proper rights. Rights may be assigned (by leads) in the define User/Project
Rights section. This is an important thing to remember when users tell you they can‗t see the
project they are working on.

Test Execution
Test execution is available when:
1. A Test Specification is written.
2. A Test Plan is created.
3. Test Case Suite (for the Test Plan) is defined.
4. A Build is created.
5. The Test plan is assigned to testers (otherwise they cannot navigate to this TestPlan).
6. Select a required Test Plan in main page and navigate to the Execute test link. Left pane
serves for navigation in Test Case Suite via tree menu, filtering and define a tested build.

Test Status
Execution is the process of assigning a result (pass, fail, blocked) to a test case for a specific
build. Blocked‗test case is not possible to test for some reason (e.g. a problem in
configuration disallows to run a tested functionality).

Insert Test Results

1. Test Results screen is shown via click on an appropriate Component, Category or test case
in navigation pane. The title shows the current build and owner. The colored bar indicate
status of the test case.
2. Yellow box includes test scenario of the test case.
3. Updated Test Cases: If users have the proper rights they can go to the Update modified
testcase page through the link on main page. It is not necessary for users to update test cases
if there has been a change (newer version or deleted).

Advantages:
1. Easy in tracking test cases(search with keyword, test case id, version etc)
2. We can add our custom fields to test cases.
3. Allocating the work either test case creation/execution any kind of documents is easy
4. when a test cases is updated the previous version also can be tracked
5. We can generate results build wise
6. Test plans are created for builds and work allocations can be done.
Report, is one of the awesome functionality present in the Test link, it generates reports in
desired format like HTML/ CSV /Excel and we can create graphs too. And the above all is
done on the privileges based which is an art of the testlink and I liked this feature very much.

Example of TestLink workflow:

 P a g e | 33

1. Administrator create a Product Fast Food‖ and a user Adam with rights leader and Bela
with rights Senior tester.
2. Adam imports Software Requirements and for part of these requirements generates empty
Test cases.
3. Bela describe test scenario of these Test cases that are organized according to Components
and Categories.
4. Adam creates Keyword: Regression‖ and assigns this keyword to ten of these test cases.
5. Adam creates a Test Plan Fish & Chips, Build Fish 0.1 and add Test Cases with keywords
Regression.
6. Adam and Bela execute and record the testing with result: 5 passed, 1 failed and 4 are
blocked.
7. Developers make a new build Fish 0.2 and Bela tests the failed and blocked test cases only.
Exceptionally all these five Test cases passed.
8. Manager would like to see results. Administrator explains him that he can create account
himself on the login page. Manager does it. He has Guest rights and could see results and
Test cases. He can see that everything passed in overall report and problems in build Fish 0.1
in a report for particular Build. But he can change nothing.