Stqa Lab Manual
Stqa Lab Manual
Conducted By:
Sushopti Gawade
Suresh Khandare
Samruddhi Khandare
Semester VIII
List of Experiments
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
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:
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:
Test cases:
Test case no: 1
Test case name: Positive values within range
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:
Test cases:
Test case no: 1
Test case name: Positive values within range
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
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:
Test cases:
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
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.
Program:
{
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 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
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
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)
9. Successful withdrawn
Actual output Expected output Test case name Test case ID
Transaction successful Withdrawn successful All details entered 1
correctly
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
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
Conclusion: ATM System specifications are studied and various bugs related to system are
identified.
EXPERIMENT NO 04
TEST CASES ON BANK APPLICATION
TEST CASES:
Check whether you are able to deposit an amount in the newly created account (and
thus updating the balance)
Check whether you are able to withdraw an amount in the newly created
account (after deposit) (and thus updating the balance)
Check whether company details are provided in cases of company's current account
Check whether proofs for joint account is provided in case of joint account
Check whether you are able deposit an account in the name of either of the person in
a joint account.
Check whether you are able withdraws an account in the name of either of the person in
a joint account.
Check whether you are able to maintain zero balance in salary account
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.
Conclusion: Hence, the test cases for Banking Application are created.
EXPERIEMNT NO 05
TEST PLAN DOCUMENT AND TEST CASES ON LIBRARY MANAGEMENT
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
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.
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.
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.
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:
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:
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 Displays the details of book for entered Accession On the click of
no. , otherwise gives proper Error message. SEARCH button
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 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 Displays the details of book for entered Register On the Click of
no. Otherwise gives proper Error message SEARCH
button
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 Displays the details of book for entered Register On the Click of
no. Otherwise gives proper Error message SEARCH button
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
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.
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.
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.
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.
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.
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.
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
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
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.
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.
Now, whenever the user uses “open” command of Selenium IDE without a target value, the base URL
would be launched on to the browser.
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 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.
EXPERIMENT NO 08
CASE STUDY: STUDY OF BUG TRACKING TOOL
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
1. User ID
2. Password
3. And then click on "Log in"
Step 1) To create a new bug in Bugzilla, visit the home-page of Bugzilla and click
on NEW tab from the main menu
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
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.
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
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
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.
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.
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.
Step 1) After Simple search we will look into Advanced Search option for that you have to
follow the following steps.
The advance search will find your bug, and it will appear on the screen like this
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)
After the skin preference is changed to Classic from Dusk, the back-ground color of the
screen appears white
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
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.
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
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.
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.
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.
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.
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.
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
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.
You define a hierarchical framework for your test plan by creating 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
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).
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.
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.
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.
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.
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.
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.
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.
THEORY:
Installation Steps:-
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.
Step 1: Open the Testlink home-page and enter the login details
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.
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"
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 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
Step 1) Click on the setting icon on the test panel. It will show the list of operations.
Step 1: From the Testlinks home-page, click on users/roles icon from the navigation bar
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
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.
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
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 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 2: From the left side panel, select "Test Report" link
1. Mark and unmark the option you want to highlight in your test report
2. click on your project folder
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
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