Software Testing and Quality Assurance ETCS - 453
Software Testing and Quality Assurance ETCS - 453
QUALITY ASSURANCE
ETCS -453
Maharaja Agrasen Institute of Technology, PSP area, Sector – 22, Rohini, New Delhi – 110085
(Affiliated to Guru Gobind Singh Indraprastha University, New Delhi
PRACTICAL RECORD
Practical Details
A) Experiments according to ITC lab syllabus prescribed by GGSIPU
INDEX
S.No EXPERIMENT NAME DATE SIGNATURE
Theory :
Adhoc testing is an informal testing type with an aim to break the system. This
testing is usually an unplanned activity. It does not follow any test design
techniques to create test cases. In fact is does not create test cases altogether!
This testing is primarily performed if the knowledge of testers in the system under
test is very high. Testers randomly test the application without any test cases or
any business requirement document. Ad hoc Testing does not follow any
structured way of testing and it is randomly done on any part of application. Main
aim of this testing is to find defects by random checking. Adhoc testing can be
achieved with the testing technique called Error Guessing.Error guessing can be
done by the people having enough experience on the system to "guess" the most
likely source of errors.
Some Advantages –
1.Ad-hoc testing gives freedom to the tester to apply their own new ways of
testing the application which helps them to find out more number of defects
compared to the formal testing process.
2.This type of testing can be done at anytime anywhere in the Software
Development Life cycle (SDLC) without following any formal process.
3.This type of testing is not only limited to the testing team but this can be done
by the developer while developing their module which helps them to code in a
better way.
Some Disadvantages –
1.Since ad-hoc testing is done without any planning and in unstructured way so
recreation of bugs sometime becomes a big trouble.
2.The test scenarios executed during the ad-hoc testing are not documented so
the tester has to keep all the scenarios in their mind which he/she might not be
able to recollect in future.
3.Ad-hoc testing is very much dependent on the skilled tester who has thorough
knowledge of the product it cannot be done by any new joiner of the team.
The testing with no proper test cases and planning is known as adhoc testing. It is
generally performed at the end of the project completion before submission.
Here were are performing a type of adhoc testing called pair testing where there
are two teaters as a pair while one is writing test cases , other will be performing
the test
Source Code
TEST CASE SCENARIO 1:-
AREA CODE:-
Blank or three digit number
TEST CASE1:
ANALYSIS:-defects found
TEST CASE3:
INPUT EXPECTED OUTPUT ACTUAL RESULT
RESULT
Ab1 Not accepted Not accepted Not accepted
TEST CASE3:
Viva Question
Q1. What is Test bed and Test data ?
The test execution environment configured for testing. Test bed consists of
specific hardware, software, Operating system, network configuration, the
product under test, other system software and application software. Data
created or selected to satisfy the execution preconditions and inputs to
execute one or more test cases
Q6:On what basis you can map the success of Automation testing?
Simple BVA
Problem Statement-
Consider an automated banking application. The user can dial the bank from a PC,
provide a 6-digit password and follow with a series of keyword commands that
activate the banking function. The software for the application accepts the data.
Test Cases-
Input
Expected Actual
Area Result
Prefix Suffix Password Command Output Output
Code
600 5500 Dgd3gs deposit Valid Valid Valid
Worst BVA
Problem Statement-
Consider an automated banking application. The user can dial the bank from a PC,
provide a 6-digit password and follow with a series of keyword commands that
activate the banking function. The software for the application accepts the data.
Test Cases-
Input
Expected Actual
Area Result
Prefix Suffix Password Command Output Output
Code
Blank 200 1000 Zx2vbn checkstatus Valid Valid Valid
Blank 200 1001 Zx2vbn withdrawal Valid Valid Valid
Blank 200 5500 Qazw3x checkstatus Valid Valid Valid
Blank 200 9998 Sfwq78 deposit Valid Valid Valid
Blank 200 9999 Abc5ef withdrawal Valid Valid Valid
Blank 201 1000 Zx2vbn withdrawal Valid Valid Valid
Blank 201 1001 Zx2vbn checkstatus Valid Valid Valid
Robust BVA
Problem Statement-
Consider an automated banking application. The user can dial the bank from a PC,
provide a 6-digit password and follow with a series of keyword commands that
activate the banking function.
Test Cases-
Input
Input
Expected Actual
Area Result
Prefix Suffix Password Command Output Output
Code
199 999 zsss22 Deposit Invalid Invalid Invalid
199 1000 Ftgy67 Withdrawal Invalid Invalid Invalid
I1 : { A:Blank & P:3-digit number not beginning with 1 & S:4-digit number }
I2 : { A:Blank & P:3-digit number beginning with 1 & S:4-digit number }
I3 : { A:3-digit number & P:3-digit number not beginning with 1 & S:4-digit number }
I4 : { A:3-digit number & P:3-digit number beginning with 1 & S:4-digit number }
I5 : { A:3-digit number & P:3-digit number & S<4-digit number }
I6 : { A:3-digit number & P:3-digit number & S>4-digit number }
I7 : { A:3-digit number & P<3-digit number & S:4-digit number }
I8 : { A:3-digit number & P<3-digit number & S<4-digit number }
I9 : { A:3-digit number & P<3-digit number & S>4-digit number }
I10 : { A:3-digit number & P>3-digit number & S:4-digit number }
I11 : { A:3-digit number & P>3-digit number & S<4-digit number }
I12 : { A:3-digit number & P>3-digit number & S>4-digit number }
I13 : { A<3-digit number & P:3-digit number & S:4-digit number }
I14 : { A<3-digit number & P:3-digit number & S<4-digit number }
I15 : { A<3-digit number & P:3-digit number & S>4-digit number }
I16 : { A<3-digit number & P<3-digit number & S:4-digit number }
I17 : { A<3-digit number & P<3-digit number & S<4-digit number }
I18 : { A<3-digit number & P<3-digit number & S>4-digit number }
I19 : { A<3-digit number & P>3-digit number & S:4-digit number }
I20 : { A<3-digit number & P>3-digit number & S<4-digit number }
I21 : { A<3-digit number & P>3-digit number & S>4-digit number }
I22 : { A>3-digit number & P:3-digit number & S:4-digit number }
I23 : { A>3-digit number & P:3-digit number & S<4-digit number }
I24 : { A>3-digit number & P:3-digit number & S>4-digit number }
I25 : { A>3-digit number & P<3-digit number & S:4-digit number }
I26 : { A>3-digit number & P<3-digit number & S<4-digit number }
I27 : { A>3-digit number & P<3-digit number & S>4-digit number }
I28 : { A>3-digit number & P>3-digit number & S:4-digit number }
I29 : { A>3-digit number & P>3-digit number & S<4-digit number }
I30 : { A>3-digit number & P>3-digit number & S>4-digit number }
Input Result
Area Expected Actual
Prefix Suffix Password Command
Code Output Output
211 2121 Zsss22 Deposit Valid Valid Valid
111 2121 ftuy78 Withdrawal Invalid Invalid Invalid
454 556 6566 Abd5ds Deposit Valid Valid Valid
454 156 6566 aghy7s Withdrawal Invalid Invalid Invalid
454 143 500 Zsss22 Check status Invalid Invalid Invalid
454 143 99985 Yup23p Withdrawal Invalid Invalid Invalid
454 34 1322 Zsss22 Check status Invalid Invalid Invalid
Viva Question
Q1. What is Test bed and Test data ?
The test execution environment configured for testing. Test bed consists of
specific hardware, software, Operating system, network configuration, the
product under test, other system software and application software. Data
created or selected to satisfy the execution preconditions and inputs to
execute one or more test cases
Q6:On what basis you can map the success of Automation testing?
#include<iostream.h>
#include<conio.h>
void main()
{
int a,b,c,d;
clrscr();
cout<<"The Quadratic equation is of the type
a(x^2)+bx+c=0"<<endl; cout<<"Enter the value of a: "<<endl;
cin>>a;
cout<<"Enter the value of b: "<<endl;
cin>>b;
cout<<"Enter the value of c: "<<endl;
cin>>c;
d=(b*b)-4*a*c;
if((a<0)||(b<0)||(c<0)||(a>100)||(b>100)||(c>100))
cout<<"Invalid input"<<endl;
else if(a==0)
cout<<"Not a quadratic equation"<<endl;
else if (d==0)
cout<<"Roots are equal"<<endl;
else if(d<0)
cout<<"Imaginary roots"<<endl;
else
cout<<"Real Roots"<<endl;
getch();
Imaginary roots
The quadratic equation is of the type a(x^2) +bx +c = 0
Enter the value of a:
10
Enter the value of b:
40
Enter the vaule of c:
40
Boundary Value analysis: The basic idea of boundary value analysis is to use input variable
at their manimum, just above manimum, normal value, just below maximum and maximum.
#include<iostream.h>
#include<conio.h>
#include<process.h>
void main()
{
clrscr();
int ch;
char c;
float b,h,a;
1: cout<<"Enter your
choice"; cout<<"\n 1.
Triangle"; cout<<"\n 2.
Square"; cout<<"\n 3.
Rectangle"; cout<<"\n 4.
Circle"; cout<<"\n 5.
Exit\n"; cin>>ch;
switch(ch)
{
case 1: b: cout<<"\Enter the base of the triangle (1-
200)"; cin>>b;
if((b<=0)||(b>200))
{
cout<<"\n Invalid entry for base \n";
goto b;
}
break;
default : cout<<"\n Wrong Choice:";
goto 1;
}
getch();
Test cases: In Equivalence class testing, we find two types of equivalence classes; input
domain and output domain;
Input domain is formed from one valid sequence and two invalid sequences. The output domain
is obtained from different types of output of a problem.
For Triangle:
Input domain:::
I1 = {h : h<=0}
I2 = {h : H>200}
I3 = {h : 1<=h<=200}
I4 = {b : b<=0}
I5 = {b : b>200}
I6 = {b : 1<=b<=200}
Test cases:
Expected
Test case ID h b output
Input domain:::
I1={s : s<=0}
I2={s : s>200}
I3={s : 1<=s<=200}
Test cases:
Test case ID s Expected output
1. 0 Invalid input
2. 100 10000
3. 201 Invalid input
Output domain:::
For Rectangle:
Input domain:::
I1 = { l : l <=0}
I2 = { l : l>200}
I3 = { I : 1<=l <=200}
I4 = { b : b<=0}
I5 = { b : b>200}
I6 = { b : 1<=b<=200}
Test cases:
Expected
Test case ID l b output
1. 0 100 Invalid input
2. 100 100 10000
3. 201 100 Invalid input
4. 100 0 Invalid input
5. 100 100 10000
6. 100 201 Invalid input
Output domain:::
For Circle:
Input domain:::
I1 = {r: r<=0}
I2 = {r : r>200}
I3 = { r: 1<=r<=200}
Test cases:
Test Cases r Expected output
1. 0 Invalid input
2. 100 31400
3. 201 Invalid input
Output domain:
SOLUTION – i)
RP RI Equivalence
Class
RP<1 1<=RP<=5 Invalid
RP>5 1<=RP<=5 Invalid
1<=RP<=5 RP<1 Invalid
1<=RP<=5 RP>5 Invalid
Non Integer 1<=RP<=5 Invalid
Non Integer RP<1 Invalid
Non Integer RP>5 Invalid
RP<1 Non Integer Invalid
RP>5 Non Integer Invalid
1<=RP<=5 Non Integer Invalid
1<=RP<=5 1<=RP<=5 Valid
Solution
ii)
RP RI Equivalence Test Test Expected
Class Case Case Output
RP RI
RP<1 1<=RP<=5 Invalid 0 3 Out of Range
RP>5 1<=RP<=5 Invalid 7 2 Out of Range
1<=RP<=5 RP<1 Invalid 3 -1 Out of Range
1<=RP<=5 RP>5 Invalid 4 23 Out of Range
Non Integer 1<=RP<=5 Invalid 23.4 3 Invalid
Non Integer RP<1 Invalid A 0 Invalid
Non Integer RP>5 Invalid Hello 17 Invalid
RP<1 Non Integer Invalid -45 3.2 Invalid
RP>5 Non Integer Invalid 60 Xyz Invalid
1<=RP<=5 Non Integer Invalid 2 * Invalid
1<=RP<=5 1<=RP<=5 Valid 2 3 Moderate
Solution iii)
Test Case Test Case Expected
RP RI Output
4 3 High
1 1 Low
3 2 Moderate
Experiment 3 (B)
Solution
Extracting Rules
If all the conditions and actions from the scenario are extracted, you can
summarize it as follows:
Conditions:
o Travel Free
o 0% discount
o 10% discount
o 20% discount
o 40% discount
Number of rules: 2 values * 3 values * 2 values * 2 values = 24 rules
Now we dump the result in a simple table to visualize a combination of all these
conditions.
Scenarios
Reduced Table
Now we can define the aging groups as shown in the following definition:
o Group1 : <=2
o Group2 : 3-18
o Group3 : >18
It is simpler when we prepare a model to help make a decision. It would
encapsulate all conditions:
Rule 4 Group3 Y N 0
Rule 5 Group3 Y Y 10
Group1 100
Germany Group2 Y 40
Germany Group2 N 50
Group3 Y N 0
Group3 Y Y 10
Germany Group3 N Y 30
Germany Group3 N N 20
Europe Group2 Y Y 50
Europe Group2 Y N 40
Europe Group2 N Y 75
Europe Group2 N N 65
Europe Group3 N Y 35
Europe Group3 N N 25
Experiment 4
FLOWCHART -
Tests depend on your particular interface (blackbox testing) as well as on your particular
implementation (glassbox testing). For a stack, some things I would expect to test:
Input:
Test case 1: initialize [empty], push [filled], push, push, push [full]
Test case 2: initialize [empty], push [filled], top, pop [empty], delete
SOLUTION-
FORMULA V(G) = edges – node +2p
FIRST GRAPH
EDGES 12
NODE 09
12-9 +2(1) = 5 ANSWER
SECOND GRAPH
EDGES 13
NODE 10
13-10+2(1) =5 ANSWER
COMBINED GRAPH
EDGES 25
NODE 19
25-19+2(2) = 10
Experiment 5 (B)
Aim: Calculate the value of 𝒂𝒃 . Perform Decision Table based testing on it.
#include<iostream.h>
#include<conio.h>
#include<math.h>
void main()
{
clrscr();
int a,b;
float c;
char ch;
cout<<endl<<c;
cout<<"\n Want to enter again?
(y/n)"; cin>>ch;
if((ch=='y')||(ch=='y'))
goto 1;
getch();
Test cases: Decision Table Based testing is useful for describing situations in which a number
of combination of actions are taken for different conditions. There are four parts of a decision
table; condition stub, action stub, condition entries and action entries.
Test case ID A B Expected output
1. 2 3 +ve result
2. -1 3 -ve result
3. -2 -4 +ve result
4. 0 1 Result is 0
5. 0 0 Domain Error
6. -1 -0.6 Result is 1
C1 a = 0, b = 0
C2 a = -ve, b = +ve
C3 a = +ve, b = -ve
C4 a = -ve, b = -ve
C5 a = +ve, b = +ve
C6 a = 0,b = integer
C7 b = 0, a = integer
A1 : Domain error
A2 : Negative output
A3 : output =1
A4 : positive output
A5 : output = 0
Condition R1 R2 R3 R4 R5 R6 R7 R8
C1 T - - - - - - -
C2 - T - - - - - -
C3 -- - - T - - - -
C4 - - -- - T - - -
C5 - - - - - T - -
C6 - - - - - - T -
C7 - - - - - - - T
C8 - - T - - - - -
Action
A1 X
A2 X X
A3 X
A4 X X X
A5 X
The output for the above program is:
To measure what fraction of code has been exercised by a test suite, several types of code
coverage criteria may be used. Five basic types are:
• ConditionCoverage: For Boolean logical operators (AND, OR), the individual Boolean sub-
expressions are evaluated in every possible combination of TRUE and FALSE
• RelationalCoverage: For relational operators (>, <, >=, <=) the equal condition is treated
as a separate branch
• Path Coverage: Every possible path is executed at least once
Statement Coverage Testing
A statement coverage testing strategy calls for testing each statement in a routine at least once.
Pick a test case and plot its path though the control flow graph. Note each statement that is
exercised by the test case. Continue to pick test cases until all statements along the control flow
graph are covered.
Test Case 1 (CeilingValue = 650000; BusinessType = ‘F’; Commercial = ‘N’) covers statements 5,
6, 6’, 6’’, 7, and 10 (highlighted in color in the pseudo-code and in the control flow graph).
Test Case 2 (CeilingValue = 3000; BusinessType = ‘F’; Commercial = ‘N’) covers statements 5, 6,
9, 10, exercising remaining uncovered statement 9 (also highlighted in color). Statement
coverage is achieved with Test Cases 1 and 2.
The truth value of BusinessType = ‘F’ will only be checked if the truth value of CeilingValue >=
650000 is true. If CeilingValue >= 650000 is false, there is no need to check the truth value
of BusinessType = ‘F’ since the entire expression is guaranteed to be false. Likewise, the truth
value of Commercial = ‘N’ will only be checked if the truth value of BusinessType = ‘F’ is true.
Test Case 1 (CeilingValue = 650000; BusinessType = ‘F’; Commercial = ‘N’) covers edges 5-6, 6-
6’, 6’-6’’, 6’’-7, and 7-10 (highlighted in color in the pseudo-code and in the control flow graph).
Test Case 2 (CeilingValue = 3000; BusinessType = ‘F’; Commercial = ‘N’) covers edges 5-6, 6-9,
and 9-10, exercising the remaining required uncovered edge from statement 6: 6-9 (also
highlighted in color). Edges 6’-9 and 6’’-9 are associated with short-circuit operators, so they are
not required to complete edge coverage.Edge coverage is achieved with Test Cases 1 and 2.
Test Case 1 (CeilingValue = 650000; BusinessType = ‘F’; Commercial = ‘N’) covers conditions 5,
6(T), 6’(T), 6’’(T), 7, 10 (highlighted in color in the pseudo-code and in the control flow graph).
Test Case 2 (CeilingValue = 3000; BusinessType = ‘F’; Commercial = ‘N’) covers conditions 5,
6(T), 9, 10 (also highlighted in color). Two additional test cases are needed to cover the FALSE
conditions for Edges 6’-9 and 6’’-9 to complete condition coverage.
Test Case 3 (CeilingValue = 650000; BusinessType = ‘NP’; Commercial = ‘N’) covers conditions 5,
6(T), 6’(F), 9, 10.
Test Case 4 (CeilingValue = 650000; BusinessType = ‘F’; Commercial = ‘Y’) covers conditions 5,
6(T), 6’(T), 6’’(F), 9, 10. Edge coverage is now achieved with Test Cases 1, 2, 3 and 4.
Relational coverage is thus a stronger form of edge coverage since it is saying that for any
conditional you should have at least three test cases: x >y, x<y, x==y. If you combine relational
coverage with condition coverage, you will have the strongest form of edge coverage possible.
Test Case 1 (CeilingValue = 650000; BusinessType = ‘F’; Commercial = ‘N’) covers the relation “x
= y”, while
Test Case 2 (CeilingValue = 3000; BusinessType = ‘F’; Commercial = ‘N’) covers the relation “x <
y”. New
Test Case 5 (CeilingValue = 700000; BusinessType = ‘F’; Commercial = ‘N’) is required to cover
the relation “x > y”. Relational coverage is achieved with Test Cases 1, 2 and 5.
Mathematically, the cyclomatic complexity of a module is defined in terms of the nodes and
edges of a control flow graph containing the basic elements of the module. The complexity is
defined as:
M = E – N + 2P
where:
M = cyclomatic complexity
For the control flow graph in this article, the function begins executing at node 5 and exits at
node 10. For this graph, there are 7 nodes (5, 6, 6’, 6’’, 7, 9, 10) and 9 edges (5-6, 6-6’, 6’-6’’,
6’’-7, 7-10, 6-9, 6’-9, 6’’-9), so N = 7, E = 9, P = 1, and M = E – N +2P = 4. The function has a
cyclomatic complexity of 4.
According to the above methodology, an adequate white-box testing strategy for this function
should have at least 4 test cases. The condition coverage testing strategy above, with four test
cases which exercise all of the logic path conditions, is consistent with this path coverage testing
methodology.
EXPERIMENT – 7
AIM –Study of Selenium – an open source testing tool.
INTRODUCTION
Selenium is a portable software-testing framework for web applications. Selenium provides a
playback (formerly also recording) tool for authoring tests without the need to learn a
test scripting language (Selenium IDE). It also provides a test domain-specific
language(Selenese) to write tests in a number of popular programming languages,
including C#, Groovy, Java, Perl, PHP, Python, Ruby and Scala. The tests can then run
against most modern web browsers. Selenium deploys on Windows, Linux, and OS
X platforms. It is open-source software, released under the Apache 2.0 license: web
developers can download and use it without charge.
HISTORY
Selenium was originally developed by Jason Huggins in 2004 as an internal tool
at ThoughtWorks. Huggins was later joined by other programmers and testers at
ThoughtWorks, before Paul Hammant joined the team and steered the development of the
second mode of operation that would later become "Selenium Remote Control" (RC). The
tool was open sourced that year.
In 2005 Dan Fabulich and Nelson Sproul (with help from Pat Lightbody) made an offer to
accept a series of patches that would transform Selenium-RC into what it became best known
for. In the same meeting, the steering of Selenium as a project would continue as a committee,
with Huggins and Hammant being the ThoughtWorks representatives.
In 2007, Huggins joined Google. Together with others like Jennifer Bevan, he continued with
the development and stabilization of Selenium RC. At the same time, Simon Stewart at
ThoughtWorks developed a superior browser automation tool called WebDriver. In 2009,
after a meeting between the developers at the Google Test Automation Conference, it was
decided to merge the two projects, and call the new project Selenium WebDriver, or Selenium
2.0.
In 2008, Philippe Hanrigou (then at ThoughtWorks) made "Selenium Grid", which provides a
hub allowing the running of multiple Selenium tests concurrently on any number of local or
remote systems, thus minimizing test execution time. Grid offered, as open source, a similar
capability to the internal/private Google cloud for Selenium RC. Pat Lightbody had already
made a private cloud for "HostedQA" which he went on to sell to Gomez, Inc.
The name Selenium comes from a joke made by Huggins in an email, mocking a competitor
named Mercury, saying that you can cure mercury poisoning by taking selenium supplements.
The others that received the email took the name and ran with it.
COMPONENTS
Selenium is composed of several components with each taking on a specific role in aiding the
development of web application test automation.
Selenium IDE
Selenium IDE is a complete integrated development environment (IDE) for Selenium tests. It
is implemented as a Firefox Add-On, and allows recording, editing, and debugging tests. It
was previously known as Selenium Recorder. Selenium-IDE was originally created by Shinya
Kasatani and donated to the Selenium project in 2006. It is little-maintained and is compatible
with Selenium RC, which was deprecated.
Scripts may be automatically recorded and edited manually providing autocompletion support
and the ability to move commands around quickly. Scripts are recorded in Selenese, a special
test scripting language for Selenium. Selenese provides commands for performing actions in a
browser (click a link, select an option), and for retrieving data from the resulting pages.
The Selenium IDE for Firefox stopped working after the Firefox 55 upgrade and will be no
longer maintained.
Selenium client API
As an alternative to writing tests in Selenese, tests can also be written in various programming
languages. These tests then communicate with Selenium by calling methods in the Selenium
Client API. Selenium currently provides client APIs
for Java, C#, Ruby, JavaScript and Python.
With Selenium 2, a new Client API was introduced (with WebDriver as its central
component). However, the old API (using class Selenium) is still supported.
Selenium WebDriver
Selenium WebDriver is the successor to Selenium RC. Selenium WebDriver accepts
commands (sent in Selenese, or via a Client API) and sends them to a browser. This is
implemented through a browser-specific browser driver, which sends commands to a browser,
and retrieves results. Most browser drivers actually launch and access a browser application
(such as Firefox, Chrome, Internet Explorer, or Microsoft Edge); there is also an Html
Unit browser driver, which simulates a browser using Html Unit.
Unlike in Selenium 1, where the Selenium server was necessary to run tests, Selenium
WebDriver does not need a special server to execute tests. Instead, the WebDriver directly
starts a browser instance and controls it. However, Selenium Grid can be used with
WebDriver to execute tests on remote systems (see below). Where possible, WebDriver uses
native operating system level functionality rather than browser-based JavaScript commands to
drive the browser. This bypasses problems with subtle differences between native and
JavaScript commands, including security restrictions.
In practice, this means that the Selenium 2.0 API has significantly fewer calls than does the
Selenium 1.0 API. Where Selenium 1.0 attempted to provide a rich interface for many
different browser operations, Selenium 2.0 aims to provide a basic set of building blocks from
which developers can create their own Domain Specific Language. One such DSL already
exists: the Watir project in the Ruby language has a rich history of good design. Watir-
webdriver implements the Watir API as a wrapper for Selenium-Webdriver in Ruby. Watir-
webdriver is created entirely automatically, based on the WebDriver specification and the
HTML specification.
As of early 2012, Simon Stewart (inventor of WebDriver), who was then with Google and
now with Facebook, and David Burns of Mozilla were negotiating with the W3C to make
WebDriver an internet standard. In July 2012, the working draft was released. Selenium-
Webdriver (Selenium 2.0) is fully implemented and supported in Python, Ruby, Java, and C#.
Selenium Remote Control
Selenium Remote Control (RC) is a server, written in Java, that accepts commands for the
browser via HTTP. RC makes it possible to write automated tests for a web application in any
programming language, which allows for better integration of Selenium in existing unit test
frameworks. To make writing tests easier, Selenium project currently provides client drivers
for PHP, Python, Ruby, .NET, Perl and Java. The Java driver can also be used
with JavaScript (via the Rhino engine). An instance of selenium RC server is needed to launch
html test case - which means that the port should be different for each parallel run. However,
for Java/PHP test case only one Selenium RC instance needs to be running continuously.
Selenium Remote Control was a refactoring of Driven Selenium or Selenium B designed by
Paul Hammant, credited with Jason as co-creator of Selenium. The original version directly
launched a process for the browser in question, from the test language of Java, .Net, Python or
Ruby. The wire protocol (called 'Selenese' in its day) was reimplemented in each language
port. After the refactor by Dan Fabulich, and Nelson Sproul (with help from Pat Lightbody)
there was an intermediate daemon process between the driving test script, and the browser.
The benefits included the ability to drive remote browsers, and the reduced need to port every
line of code to an increasingly growing set of languages. Selenium Remote Control completely
took over from the Driven Selenium code-line in 2006. The browser pattern for 'Driven'/'B'
and 'RC' was response/request, which subsequently became known as Comet.
With the release of Selenium 2, Selenium RC has been officially deprecated in favor of
Selenium WebDriver.
Selenium Grid
Selenium Grid is a server that allows tests to use web browser instances running on remote
machines. With Selenium Grid, one server acts as the hub. Tests contact the hub to obtain
access to browser instances. The hub has a list of servers that provide access to browser
instances (WebDriver nodes), and lets tests use these instances. Selenium Grid allows running
tests in parallel on multiple machines, and to manage different browser versions and browser
configurations centrally (instead of in each individual test).
The ability to run tests on remote browser instances is useful to spread the load of testing
across several machines, and to run tests in browsers running on different platforms or
operating systems. The latter is particularly useful in cases where not all browsers to be used
for testing can run on the same platform.
VIVA VOCE
Q1. What is Selenium? What is the latest version of selenium?
Selenium is a free (open-source) automated testing framework used to validate web
applications across different browsers and platforms. You can use multiple programming
languages like Java, C#, Python etc to create Selenium Test Scripts. Testing done using the
Selenium testing tool is usually referred to as Selenium Testing. Selenium 4 is the lastest
version of selenium
• Step – Helps step into each specific command in the test script.
Theory -WinRunner is a program that is responsible for the automated testing of software.
WinRunner is a Mercury Interactive‘s enterprise functional testing tool for
Microsoft windows applications.
WinRunner Uses:
1. With WinRunner sophisticated automated tests can be created and run on an application.
2. A series of wizards will be provided to the user, and these wizards can create tests in
an automated manner.
3. Another impressive aspect of WinRunner is the ability to record various interactions, and
transform them into scripts. WinRunner is designed for testing graphical user interfaces.
4. When the user make an interaction with the GUI, this interaction can be
recorded. Recording the interactions allows to determine various bugs that need
to be fixed.
5. When the test is completed, WinRunner will provide with detailed information
regarding the results. It will show the errors that were found, and it will also give
important information about them. The good news about these tests is that they
can be reused many times.
6. WinRunner will test the computer program in a way that is very similar to normal user
interactions. This is important, because it ensures a high level of accuracy and realism.
Even if an engineer is not physically present, the Recover manager will troubleshoot
any problems that may occur, and this will allow the tests to be completed without
errors.
7. The Recover Manager is a powerful tool that can assist users with various scenarios.
This is important, especially when important data needs to be recovered.
The goal of WinRunner is to make sure business processes are properly carried
out. WinRunner uses TSL, or Test Script Language.
WinRunner Testing Modes
Context Sensitive
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, WinRunner writes a unique description of each
selected object to a GUI map.
The GUI map consists of files maintained separately from your test scripts. If the user
interface of your application changes, you have to update only the GUI map, instead of hundreds
of tests. This allows you to easily reuse your Context Sensitive test scripts on future versions of
your application.
To run a test, you simply play back the test script. WinRunner emulates a user by moving
the mouse pointer over your application, selecting objects, and entering keyboard input.
WinRunner reads the object descriptions in the GUI map and then searches in the application
being tested for objects matching these descriptions. It can locate objects in a window even if
their placement has changed.
Analog
Analog mode records mouse clicks, keyboard input, and the exact x- and y-coordinates
traveled by the mouse. When the test is run, WinRunner retraces the mouse tracks. Use Analog
mode when exact mouse coordinates are important to your test, such as when testing a drawing
application.
The first stage is to create the GUI map so WinRunner can recognize the GUI objects in
the application being tested. Use the RapidTest Script wizard to review the user interface of
your application and systematically add descriptions of every GUI object to the GUI map.
Alternatively, you can add descriptions of individual objects to the GUI map by clicking objects
while recording a test.
2. Create Tests
3. Debug Tests
Run tests in Debug mode to make sure they run smoothly. One can set breakpoints,
monitor variables, and control how tests are run to identify and isolate defects. Test results are
saved in the debug folder, which can be discarded once debugging is finished. When WinRunner
runs a test, it checks each script line for basic syntax errors, like incorrect syntax or missing
elements in If, While, Switch, and For statements. We can use the Syntax Check options (Tools
>Syntax Check) to check for these types of syntax errors before running your test.
4. Run Tests
Tests can be run in Verify mode to test the application. Each time WinRunner encounters
a checkpoint in the test script, it compares the current data of the application being tested to
the expected data captured earlier. If any mismatches are found, WinRunner captures them as
actual results.
5. View Results
Following each test run, WinRunner displays the results in a report. The report details all
the major events that occurred during the run, such as checkpoints, error messages, system
messages, or user messages. If mismatches are detected at checkpoints during the test run, we
can view the expected results nd the actual results from the Test Results window. In cases of
bitmap mismatches, one can also view a bitmap that displays only the difference between the
expected and actual results.
We can view results in the standard WinRunner report view or in the Unified report view.
The WinRunner report view displays the test results in a Windows-style viewer. The Unified
report view displays the results in an HTML-style viewer (identical to the style used for QuickTest
Professional test results).
6. Report Defects
If a test run fails due to a defect in the application being tested, one can report
information about the defect directly from the Test Results window.
This information is sent via e-mail to the quality assurance manager, who tracks the
defect until it is fixed.
Before you begin creating tests, you should familiarize yourself with the
WinRunner main window.
The first time you start WinRunner, the Welcome to WinRunner window and the
―What‘s New in WinRunner‖ help open. From the Welcome window you can create a new
test, open an existing test, or view an overview of WinRunner in your default browser.
CASE TOOLS & SOFTWARE TESTING LAB MANUAL
If you do not want this window to appear the next time you start WinRunner, clear the
Show on Startup check box. To show the Welcome to WinRunner window upon startup from
within WinRunner, choose Settings > General Options, click the Environment tab, and select the
Show Welcome screen check box.
The Standard toolbar provides easy access to frequently performed tasks, such
as opening, executing, and saving tests, and viewing test results.
Standard Toolbar
The User toolbar displays the tools you frequently use to create test scripts. By default,
the User toolbar is hidden. To display the User toolbar, choose Window > User Toolbar. When
you create tests, you can minimize the WinRunner window and work exclusively from the
toolbar. The User toolbar is customizable. You choose to add or remove buttons using the
Settings > Customize User Toolbar menu option. When you re-open WinRunner, the User
toolbar appears as it was when you last closed it. The commands on the Standard toolbar and
the User toolbar are described in detail in subsequent lessons.
Note that you can also execute many commands using softkeys. Softkeys are keyboard
shortcuts for carrying out menu commands. You can configure the softkey combinations for your
keyboard using the Softkey Configuration utility in your WinRunner program group. For more
information, see the ―WinRunner at a Glance‖ chapter in your WinRunner User’s Guide.
Now that you are familiar with the main WinRunner window, take a few minutes to
explore these window components before proceeding to the next lesson.
Test window title bar, with the name of the open test
Test script, with statements generated by recording and/or programming in
TSL, Mercury Interactive‘s Test Script Language
Execution arrow, which indicates the line of the test script being executed during a
test run, or the line that will next run if you select the Run from arrow option
Insertion point, which indicates where you can insert or
edit text
Experiment 9
Aim: Study of Test Management tool (QA Complete)
QA Complete
• Test management tool that can be used for both manual
and automated Testing
• Tool that allow us to track all aspects of software quality in
an efficient manner
• Supports all aspects of test process and ensures the delivery
of high quality software.
Benefits
• QA Complete can be integrated with any number of tools
• Customizable as per the tester’s needs
• Requirements and tests can be traced to defect effectively
• Reports and Dashboards are the key features of QA
Complete
Features
• Test Case Management – Simple Test Case structuring also
allows for focused metrics and clear status report
• Test Environment Management – Various environments are
linked to individual test cases for effective Test Coverage(
across different platforms, operating systems, and devices)
• Defect and Issue Management – Mainly tracks
the resolution process of bugs for each release and
automatically creates bugs when test cases fail.
• Test Automation Integration – Can be integrated with
various automation tools, and it allows us to track and
report overall (manual and automated)
• Bug Tracker Integration – Can be integrated with various
Bug tracking tools
• Shared Documents – Stores all test documents in one
central location to improve collaboration
Step 1: Log into QA Complete Tool
This open bug-tracker enables users to stay connected with their clients or
employees, to communicate about problems effectively throughout the
data-management chain.
Step 1) Use the following link for your handons. To create an account in Bugzilla
or to login into the existing account go to New Account or Log in option in the
main menu.
Step 2) Now, enter your personal details to log into Bugzilla
1. User ID
2. Password
Step 1) To create a new bug in Bugzilla, visit the home-page of Bugzilla and
click on NEW tab from the main men
Step 2) In the next window
1. Enter Product
2. Enter Component
4. Select version,
5. Select severity
6. Select Hardware
7. Select OS
8. Enter Summary
9. Enter Description
11. Submit
NOTE: The above fields will vary as per your customization of Bugzilla
NOTE: The mandatory fields are marked with *.
Summary
Description
Are mandatory
If you do not fill them you will get a screen like below
Step 4) Bug is created ID# 26320 is assigned to our Bug. You can also add additional
information to the assigned bug like URL, keywords, whiteboard, tags, etc. This extra-
information is helpful to give more detail about the Bug you have created
• Large text box
• URL
• Whiteboard
• Keywords
• Tags
• Depends on
• Blocks
• Attachments
Step 5) In the same window if you scroll down further. You can select deadline
date and also status of the bug. Deadline in Bugzilla usually gives the time-limit
to resolve the bug in given time frame.
Create Graphical Reports
Graphical reports are one way to view the current state of the bug database. You
can run reports either through an HTML table or graphical line/pie/bar-chart-based
one. The idea behind graphical report in Bugzilla is to define a set of bugs using
the standard search interface and then choosing some aspect of that set to plot on
the horizontal and vertical axes. You can also get a 3-dimensional report by
choosing the option of "Multiple Pages".
Reports are helpful in many ways, for instance if you want to know which component
has the largest number of bad bugs reported against it. In order to represent that in the
graph, you can select severity on X- axis and component on Y-axis, and then click on
generate report. It will generate a report with crucial information.
The graph below shows the Bar chart representation for the Bugs severity in
component "Widget Gears". In the graph below, the most severe bug or blockers
in components are 88 while bugs with normal severity is at top with 667 number.
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
1. Vertical Axis
2. Horizontal Axis
3. Multiple Images
4. Format- Line graph, Bar chart or Pie chart
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 1) We will first learn the "Simple Search" method. Click on search button
from the main menu and then follow these steps
3. Choose your category and component, and you can also put
keywords related to your bug
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.
In next step, we will demonstrate one of this function change column of the screen, through
which we will learn how to add or remove the column to the existing column.
Step 1) Click on the Change Column as shown in above screen-shot. It will open a new window
where you have to follow these steps.
Select any given option from the column you want to appear in the main screen - here we have
selected % complete
Click on the arrow button, it will move % complete column from Available Column to the
Selected column
These steps will move the selected column from left to right.
The % complete is moved from left to right as shown below, and once we
click on change columnit will appear in the main screen
Before- Search result screen before using "Change Column" option-
You can see % complete column added to the extreme right in the
existing column in the main screen, which was not their previously.
NOTE: Likewise you can remove or add any column you want.
Step 1) After Simple search we will look into Advanced Search option for that
you have to follow the following steps.
3. Enter the keyword for your bug- for example, Widget gears twisted
4. Select the category of your Bug under classification, here we selected Widget
5. Choose your product under which your Bug was created- Sam's Widget
7. Status- Confirmed
8. Resolution
Step 2) Once you select all the option, click on search button. It will detect
the bug you created
The advance search will find your bug, and it will appear on the screen like
How to use preferences in BugZilla
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)
Select the option you want to see as a change and submit the
change ( Dusk Classic )
A message will appear on the window saying changes have been saved,
as soon as you submit the changes
After the skin preference is changed to Classic from Dusk, the back-ground color
of the screen appears white
Likewise, for other default settings changes can be done.
E-mail preferences
E-mail preferences enable you to decide how to receive the message and
from whom to receive the messages.
Step 1) To set the e-mail preferences
1. Click on e-mail services
2. Enable or disable the mail to avoid receiving notification about changes to
a bug
3. Receiving mail when someone asks to set a flag or when someone sets a
flag you asked for
4. When and from whom you want to receive mail and under which
condition. After marking your option at the end, submit the changes.
Saved Searches Preference
Saved searches preference gives you the freedom to decide whether to share
your bug or not to share.
Step 1) Click on saved searches, it will open window with the option like editbugs,
don't share, canconfirm, etc. Choose the option as per your need.
Step 2) We can run our bug from "Saved Searches".
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