STQA
STQA
STQA
STQA Lab
(ETCS - 453)
Aim:
Write a program to find whether a number is prime or not. To determine the nature of roots of a
quadratic equation, its input is triple of +ve integers (say a,b,c) and values may be from the
interval[1,100] The program output may have one of the following:-
Theory:
BVA(Boundary value analysis)is a black box test design technique and it is used to find the
errors at boundaries of input domain rather than finding those errors in the center of input The
basic boundary value analysis technique can be generalized in two ways: by the number of
variables, and by the kinds of ranges. Generalizing the number of variables is easy: if we have a
function of n variables, we hold all but one at the nominal values, and let the remaining variable
assume the min, min+, nom, max- and max values, and repeat this for each variable. Thus for a
function of n variables, boundary value analysis yields 4n + 1 test cases.
In the above program consider the value 1(minimum), 2(just above Minimum), 50 (Nominal),
99(Just below Maximum) and 100(Maximum). Total No. of test cases will be 4*3+1=13
If a, b, and c denote the three integer in quadratic equation a(x2)+bx+c=0 then Calculate
discriminant d=(b*b)-4*a*c
Source Code:
import cmath
print("Enter the values of variable for the standard Quadratic equation ax^2 + bx + c = 0")
a = int(input("Enter Value of a: "))
b = int(input("Enter Value of b: "))
c = int(input("Enter Value of c: "))
print('The real roots of the equation "{0}x^2 + {1}x + {2} = 0" are {3} and {4}\n'.format(a, b, c,
root1.real, root2.real))
print('The imaginary roots of the equation "{0}x^2 + {1}x + {2} = 0" are {3} and {4}'.format(a,
b, c, root1.imag, root2.imag))
Output:
Test Cases:
Boundary Value analysis: The basic idea of boundary value analysis is to use input variables at
their maximum, just above minimum, normal value, just below maximum and maximum.
In this program, we consider the value as 0 (minimum), 1(just above minimum), 50 (normal), 99
(just below maximum) and 100 (maximum).
Maximum of 4n+1 test cases
9 50 100 50 Real and Equal Roots Real and Equal Roots Pass
The method of carrying out robustness testing follows a set of conventions. A set of invalid
inputs or an odd/stressful environment is set up. Sometimes it so happens that on providing
certain inputs the program may crash . It becomes significant to capture those errors and rectify it
in accordance with the requirement specifications.
Hence suitable test cases are developed to perform testing in an appropriate test environment.
Total number of test cases generated in robust testing are 6*N +1 due to min-1 , min , min+1 ,
mid , max -1 , max and max+1.
Robustness testing ensures that a software system qualifies as the end product for which it was
meant for, hence serving the right purpose. As we know that a complete software system
comprises various components, such kind of testing ensures reducing cost and time required for
efficient delivery of a software system.
So robustness testing is carried out somewhat like this- a combination of valid and invalid inputs
is passed to the system and checked for the performance . So a system is tested and validated
under different conditions.
Aim:
To determine the type of triangle. Its input is triple of +ve integers (say x,y,z) and the values may
be from interval[1,l00].The program output may be one of the following [Scalene, Isosceles,
Equilateral, Not a Triangle]. Perform BVA, Equivalence Class Testing (Using Input Domain and
Output domain). Which Technique is best for the given problem statement. Give reasons.
Theory:
Boundary Value Analysis (BVA) is a black box software testing technique where test cases are
designed using boundary values. BVA is based on the single fault assumption, also known as
critical fault assumption which states that failures are rarely the product of two or more
simultaneous faults. Hence while designing the test cases for BVA we keep all but one variable
to the nominal value and allowing the remaining variable to take the extreme value.
Source Code:
In this program, we consider the value as 0 (minimum), 1(just above minimum), 50 (normal), 99
(just below maximum) and 100 (maximum).
The method of carrying out robustness testing follows a set of conventions. A set of invalid
inputs or odd/stressful environment is set up. Sometimes it so happens that on providing certain
inputs the program may crash . It becomes significant to capture those errors and rectify it in
accordance with the requirement specifications.
Hence suitable test cases are developed to perform testing in an appropriate test environment.
Total number of test cases generated in robust testing are 6*N +1 due to min-1 , min , min+1 ,
mid , max -1 , max and max+1.
So robustness testing is carried out somewhat like this- a combination of valid and invalid inputs
is passed to the system and checked for the performance . So a system is tested and validated
under different conditions.
Result:
BVA and Robust testing was performed for given conditions and verified.
EXPERIMENT – 3
Aim:
Equivalence Class Partitioning In the lecture, we used the example of an app that classified Risk
Exposure (RE) as High, Moderate, or Low on the basis of Risk Probability (RP) and Risk Impact
(RI).
Consider the following specification for such an app:
1) the app accepts two integers, RP and RI, as input,
2) both RP and RI must be in the range [1, 5],
3) if either input is not an integer, it is invalid and the app outputs “Invalid,
4) if either input is an integer outside the range specified in (2), it is invalid and the app outputs
“Out of Range”,
5) given valid inputs, the app calculates RE as the product of RP and RI, and outputs:
a. “High”, if RE is greater than 9
b. “Low” if RE is less than or equal to 2
c. “Moderate” if neither (a) nor (b) are satisfied
iv) Partition the domain of each parameter into equivalence classes, label the classes, and list
them.
v) Develop a set of test cases for the app to satisfy Each Choice Coverage of the equivalence
classes. Indicate the equivalence classes covered by each test case and, as always, include
the expected result. Notice the actual classification process is not adequately tested by
your set of test cases.
vi) To better test the classification performed by the app, partition the output domain and
develop additional test cases to cover any class not covered by your test cases in (ii).
Theory:
Risk is the probability of a negative or undesirable outcome or event. Risk is any problem that
might occur that would decrease customer, user, stakeholder perception of quality and/or project
success.
Types of risks:
There are 2 types of risks- Product Risk and Quality Risk.
1. Product risk-
When the Primary effect of a potential problem is on product quality, then the potential
problem is called Product risk. It can also be called a quality risk. Example- A defect that
can cause a system crash or monetary loss.
2. Project Risk-
When the Primary effect of a potential problem is on the overall success of the
project, those potential problems are called Project risk. They can also be called Planning
risks. Example- Staffing issues that can delay project completion.
Not all risks are equally important. There is a number of ways we can classify the level of risk.
The easiest way is to look at two factors-
2. Frequency of use.
3. Criticality of Business.
4. Possible areas with defects, etc.
1. RBT strategy matches the level of test effort to the level of risk. The higher the risk, the
more is the test effort. This applies to test execution as well as other test activities like
test designing and implementation.
2. It matches the order of testing with the level of risk. Higher risk tests tend to find more
defects or are related to more important areas in the application or maybe both. So higher
the risk, we plan the tests earlier in the cycle- both in design and execution. This helps in
building the confidence of business stakeholders as well.
3. By effort allocation and maintaining the order of testing, the quality risk gets
systematically and predictably reduced. By maintaining a traceability matrix of tests vs
risks and defects identified to risks, reporting the risk as residual risks make sense. This
allows the concerned stakeholders to decide when to stop testing i.e whenever the risk of
continuing testing exceeds the risk of testing completion.
4. If schedule reduction requires scope reduction, it is easier to decide what needs to go out.
It will always be acceptable and explainable to business stakeholders as risk levels are
agreed upon.
5. To identify risks, we need to take inputs from various sources like – Requirements
specifications, design specifications, existing application data, previous incident records,
etc. However, if this information is not readily available, we can still use this approach by
getting inputs from stakeholders for the risk identification and assessment process.
3. When the team is new to the technology platform or to the application under test.
1. The effort is allocated by test managers proportional to the risk associated with the test
item.
2. Test techniques are selected in a way that matches the rigor and extensiveness required
based on the level of risk of the test item.
3. Test activities should be carried out in reverse order of risk i.e The Highest risk item
should be tested first.
4. Prioritization and resolution of defects should be done as appropriate with the level of
risk associated.
5. During test planning and control, test managers should carry out risk control for all
significant risk items. The higher the level of risk associated, the more thoroughly it
should be controlled.
6. Reporting should be done in terms of residual risks. Example- Which tests have not run
yet? Which defects have not fixed yet?
2. Effective-
RBT is effective because your time is spent according to the risk rating and mitigation
plans. You do not spend time on items and activities which might not be very important
in the overall scheme of things.
4. Cost reduction-
A reduction in cost per quality as critical issues get fixed early in the cycle and hence
lowering the cost of change.
Solution:
i)
RP RI Equivalence Class
ii)
Result:
Problems based on the given conditions were solved and verified.
EXPERIMENT – 4
Aim:
Develop a complete limited-entry decision table for the following decision situation:
An airline offers only flights in Germany and Europe. Under special conditions a discount is
offered — a discount with respect to the normal airfare.
Rules:
• Passengers older than 2 but younger than 18 years are offered a discount of 40%
for all destinations.
Theory:
A decision table is a brief visual representation for specifying which actions to perform
depending on given conditions. The information represented in decision tables can also be
represented as decision trees or in a programming language using if-then-else and switch-case
statements.
A decision table is a good way to settle with different combination inputs with their
corresponding outputs and is also called a cause-effect table. The reason to call cause-effect table
is a related logical diagramming technique called cause-effect graphing that is basically used to
obtain the decision table.
● It provides a regular way of starting complex business rules, that is helpful for developers
as well as for testers.
● It assists in the development process with the developer to do a better job. Testing with
all combinations might be impractical.
● Any complex business flow can be easily converted into test scenarios & test cases using
this technique.
● Decision tables work iteratively which means the table created at the first iteration is used
as input tables for the next tables. The iteration is done only if the initial table is not
satisfactory.
● Simple to understand and everyone can use this method to design the test scenarios & test
cases.
● It provides complete coverage of test cases which helps to reduce the rework on writing
test scenarios & test cases.
● These tables guarantee that we consider every possible combination of condition values.
This is known as its completeness property.
Solution:
Airline Passenger Discount Policy
An airline offers only flights to India and Asia. Under special conditions, a discount is offered on
the normal airfare:
o Passengers older than 18 with destinations in India are offered a discount of 20%, as long
as the departure is not on a Monday or Friday.
o For destinations outside of India, passengers are offered a discount of 25%, if the
departure is not on a Monday or Friday.
o Passengers who stay at least 6 days at their destination receive an additional discount of
10%.
o Passengers older than 2 but younger than 18 years are offered a discount of 40% for all
destinations.
Extracting Rules
Conditions:
o Destination (India, Asia)
o Passenger Age (<= 2, > 2 && < 18, > 18
o Depart on Monday or Friday (Yes, No)
o Stay 6 days or more (Yes, No)
Actions:
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
Scenarios
Reduced Table
Decision Table:
Rule 4 Group3 Y N 0
Rule 5 Group3 Y Y 10
Result:
For each rule test-case was designed and verified.
EXPERIMENT – 5
Aim:
Theory:
A Test Plan is a detailed document that describes the test strategy, objectives, schedule,
estimation, deliverables, and resources required to perform testing for a software product. Test
Plan helps us determine the effort needed to validate the quality of the application under test. The
test plan serves as a blueprint to conduct software testing activities as a defined process, which is
minutely monitored and controlled by the test manager.
Table of Contents :
1) Introduction
2) Purpose
3) Scope
4) Testing Strategies
4.1. Unit testing
4.2 System & Integration texting
4.3. Performance testing & Stress testing
4.4. Acceptance Testing
5) features to be listed
6) Hardware requirements
7) Environment requirements
8) Test schedule
9) Risk & Mitigation
10) Tools
1. Introduction
Aviation provides the only rapid worldwide transportation network, generating economic growth,
creating jobs, and facilitating international trade and tourism. Therefore with such increasing
number it is important to provide different offers to customers to cater the need of all the age
groups.
2. Purpose
The aviation discount management tool is an online application for managing discounts and
ticket activities to various age groups. This test plan document support the following objective :
● Identify the user’s age and offer discount according to the availability
● List the recommended tools requirements.
● Recommend and describe the testing strategies to be employed.
● List the deliverable elements of the test activities.
3. Scope
The system that is to developed provides the related information on customers and system
administration
● Creating a system administrator who will be the sole user managing the system on the
backend.
● System admin can add/ delete/view/ edit the discount details
● Admin can add/delete/view/edit the tickets issued as well as discounts.
● Admin can search for the tickets issued.
4. Testing Strategies
The aim of the system testing process is to determine all the defects in the project.
5) Features to be tested
● GUI testing
● Database testing
● Basic operations add/delete/etc
● Advance operations
● BIU
6) Hardware requirements / Software requirements
● Windows -OS
● Python language
● MySQL database
● Visual studio code - IDE
7) Environment requirement
● Mainframe- Specify both the necessary and designed properties of test acquirement
● Workstations - computers provided in the libraries to be used by admins and students.
8) Risk and mitigation
Keep battery back up and avoid electricity issues
9) Tools
● Selenium
● 2 pp
Result: Successfully prepared a test plan for an aviation system.
EXPERIMENT – 6
Aim:
Study of Win Runner Testing Tool
Theory:
Win Runner is the most used Automated Software Testing Tool.
The main Features of Win Runner are
1. Developed by Mercury Interactive
2. Functionality testing tool
3. Supports C/s and web technologies such as (VB, VC++, D2K, Java, HTML,
Power Builder, Delphe, Cibell (ERP))
4. To Support .net, xml, SAP, Peoplesoft, Oracle applications, Multimedia we can use
QTP.
5. Winrunner runs on Windows only.
6. Xrunner runs only UNIX and Linux.
7. Tool developed in C on VC++ environment.
8. To automate our manual test win runner used TSL (Test Script language)
● The main Testing Process in Win Runner is
1) Learning
Recognition of objects and windows in our application by WinRunner is called learning.
2) Recording
3) Edit Script
Depending on the corresponding manual test, the test engineer inserts checkpoints into that
record script.
4) Run Script
During test script execution, WinRunner compares tester given expected values and application
actual values and returns results.
5) Analyze Results
Tester analyzes the tool given results to concentrate on defect tracking if required.
Step 1: Open a new document: File -> New (or) Select "New Test"
Step 4: Select the application to be tested by clicking on the application's title bar.
Step 6: Once all required actions are recorded, stop the recording.
Create -> Stop (or) Click on the toolbar's "Stop" button to stop the recording WinRunner
generates the script for the recorded actions
There are two modes for generating the test cases: "Global GUI map file mode" and "GUI map
file per test mode". By default, it is in "Global GUI map file mode".
In Global GUI map file mode, you have to explicitly save the information learnt by WinRunner.
WinRunner saves it in a file with the extension "gui". When you have to run a test, you need to
load the corresponding GUI map file; otherwise, it will not be able to recognize the objects in the
test case and display an error message. In GUI map file per test mode, WinRunner automatically
saves the information it has learnt from the application. It is always preferred to work in Global
GUI map file mode.
EXPERIMENT – 7
Aim:
Study of Test Management tool (QA Complete)
Theory:
QA Complete is a Test management tool that can be used for both manual and Automated
Testing. It is a tool with powerful test management capabilities that allow us to track all aspects
of software quality in an efficient manner. QA Complete supports all aspects of the 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 – This can be integrated with various automation tools, and it
allows us to track and report overall (manual and automated) Test Management efforts
at a single place
● Bug Tracker Integration – Can be integrated with various Bug tracking tools
● Shared Documents – Stores all test documents in one central location to improve
collaboration
Steps to Setup and Work on the QA Complete
To manage and produce the right test deliverables, let us assume an E-Work Sight Login Page
needs to be tested manually. The following steps and screenshots will explain how we can
manage the Test Deliverables using QA Complete Test Management Tool.
Step 2: Create a New Release as E-Work under the Release tab by clicking the Add New icon
and click the Add New Item to add an Iteration/Build
Step 3: Navigate to the Test Management Tab -> Test Library -> Add New folder
Step 4: Navigate to Test Management Tab -> Test Sets -> Create a folder (Add the ‘+’ @ left
panel) -> Create a new test set using the Add New icon -> After entering the details click the
Submit button -> Navigate to the Tests Tab and Design the steps accordingly
Step 5: To run the Test Sets -> Test Management Tool -> Test Sets -> Click the RUN icon
Step 6: Click the Start Run at the top right corner. Based on the working functionality, select the
Run Status and click the End Run option finally.
A
Step 7: If any of the steps fail in a Test Set during the run, it prompts to create a defect
automatically
Theory:
Automations allow you to run tests without user interaction on remote computers. You can
perform such tests as often as needed, for example, after a successful build or on a daily basis.
Integrate QAComplete tests with various testing tools to track results using the features provided
by the Test Library. You can automatically run necessary tests and collect results for full tracking
of your testing coverage and progress.
1. In your automated testing tool, you create tests that will perform the needed actions to
test your application or feature.
2. You pack the automated test files into a .zip archive. These can be stored in a shared
network folder or on a separate website.
Note: It is also possible to attach files directly to the test item in the Test Library.
3. You install and configure the Test Agent on the computers that you will use to preform
automated tests.
4. You associate the automated tests with tests in the Test Library.
5. (Optional) You create schedules to run tests at the time specified.
6. During the scheduled run time or when you request the test to run, the Test Agent
performs the following actions on the host:
Theory:
What is Bugzilla?
Bugzilla is an open-source issue/bug tracking system that allows developers to keep track of
outstanding problems with their products. It is written in Perl and uses the 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.
Step 5) In the same window if you scroll down further. You can select the deadline date and also
the status of the bug. The deadline in Bugzilla usually gives the time limit to resolve the bug in
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 a 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 the top with 667 numbers.
EXPERIMENT – 10
AIM
Study of any open source testing tool (Web Performance Analyzer/OSTA)
THEORY
The performance of web applications can affect business. Top engineering organizations consider
performance not as nice-to-have, but as a crucial feature of their products. Unfortunately, most
engineering teams do not regularly test the performance and scalability of their infrastructure,
and most lack the tools to properly do so. Although plenty of commercial tool options out there,
for the right organization, free and open source tools may be a good alternative or the perfect
complement to a commercial tool set.
The goal of performance testing is to understand how your applications behave under heavy load
conditions. To get started, you need to understand the baseline performance of your application
and that the performance of each transaction is unique. For example, in an ecommerce
application, a home page transaction is likely highly cached and very fast, whereas a checkout
transaction is more complicated and must talk to a payment service, shipping service, etc. To
ensure that users have a great experience, you must test the most common flows for your users
and understand performance both in the browser and on the server.To get the job done, we’ll
need server-side, client-side, and performance tools.
This web performance testing tool can be used for intranet applications and websites. WAPT is
short for Web Application Performance Tool, and it acts as a scale or analyzing tool for
measuring the output and performance of a web application and related interface. The tools help
measure the performance of any web-related interface, web service or web application. You can
use this tool to test the application performance in different environments and load conditions.
The tool provides detailed information on the virtual users and its output to the users during load
testing. It is considered by many to be one of the best and most costeffective tools for analyzing
the performance of web services. The WAPT tool can also test the compatibility of a web
application with operating systems and browsers. It can be used for testing the compatibility with
Windows applications in certain cases. However, the tool only works on Windows operating
systems.
Experiment 11
AIM : The BSE Electrical Company charges its domestic consumers using the following slab:
Identify the best suitable black box testing technique and also frame the code for the above
mentioned problem statement and find the best suitable white box testing technique.
THEORY:
Black Box Testing Technique Black box testing is a type of testing that does not require
knowledge of the internal workings of the code being tested. Instead, it focuses on the inputs and
outputs of the code, and determines whether the outputs are correct for a given set of inputs.
Some suitable black box testing techniques for the above problem statement might include:
● Equivalence partitioning: This technique divides the input data into "equivalence partitions,"
or groups of data that are expected to behave in the same way. For example, in the BSE
Electrical Company case, we might create an equivalence partition for consumers who use less
than 100 units of electricity per month, another partition for consumers who use between 100 and
200 units per month, and so on. We can then test the code using representative samples from
each partition to ensure that it is correct for all consumers within that partition.
● Boundary value analysis: This technique tests the code using input values that are at the
minimum and maximum boundaries of the expected input range. For example, in the BSE
Electrical Company case, we might test the code using input values of 0 units, 100 units, 199
units, and 200 units to ensure that it is correct at the minimum and maximum boundaries of the
input range.
White Box Testing Techniques
White Box Testing is a testing technique in which software’s internal structure, design, and
coding are tested to verify input-output flow and improve design, usability, and security. In this
we analyze the internal structures, the used data structures, internal design, code structure, and
the working of the software rather than just the functionality as in the case of black box testing.
In white box testing, the code is visible to testers, so it is also called Clear box testing, open box
testing, transparent box testing, Code-based testing, and Glass box testing.
Some suitable White Box testing techniques for the above problem might include:
Branch coverage technique is used to cover all branches of the control flow graph. It covers all
the possible outcomes (true and false) of each condition of decision point at least once. Branch
coverage technique is a white box testing technique that ensures that every branch of each
decision point must be executed.
Basis Path Testing is a white-box testing technique based on the control structure of a program
or a module. Using this structure, a control flow graph is prepared and the various possible paths
present in the graph are executed as a part of testing.
Condition coverage testing is a type of white-box testing that tests all the conditional
expressions in a program for all possible outcomes of the conditions. It is also called predicate
coverage.
Here is some example code for the BSE Electrical Company case: This code calculates the bill
for a domestic consumer based on the number of units of electricity they have used. The bill is
calculated using the following slab:
#include <iostream>
using namespace std;
int main()
{
int consumptionUnit = 0;
cout<<"Enter consumption unit: ";
cin>>consumptionUnit;
if(consumptionUnit >= 0) {
float cost = 0;
if(consumptionUnit <= 150)
cost = consumptionUnit*2;
else if(consumptionUnit <= 300)
cost = 200 + (consumptionUnit-150)*3;
else if(consumptionUnit <= 400)
cost = 300 + (consumptionUnit-300)*3.9;
else
cost = 350 + (consumptionUnit-400)*4.4;
cout<<"Energy charges: "<<cost;
}
else cout<<"Invalid Consumption!!!";
return 0;
}
OUTPUT