Software Testing

Unit No.1
In general, testing is finding out how well something works. In terms of human beings, testing
tells what level of knowledge or skill has been acquired. In computer hardware and software
development, testing is used at key checkpoints in the overall process to determine whether
objectives are being met.
Software Testing:
is the act of examining the artifacts and the behavior of the software under test by validation and
verification? Software testing can also provide an objective, independent view of the software to
allow the business to appreciate and understand the risks of software implementation.
Software Testing is a method to check whether the actual software product matches expected
requirements and to ensure that software product is Defect free.
It involves execution of software/system components using manual or automated tools to
evaluate one or more properties of interest. The purpose of software testing is to identify errors,
gaps or missing requirements in contrast to actual requirements.
Software Errors:
An error is a deviation from accuracy or correctness” and “A software bug is an error, flaw,
failure, or fault in a computer program or system that causes it to produce an incorrect or
unexpected result, or to behave in unintended ways “.
• Reasons:
Error is a variance of the actual result from the expected result.
Errors are a category of software bugs.
Errors can be introduced as result of incomplete or inaccurate requirements or due to human data
entry problems.
Software Errors:
1) Functionality Errors:
Functionality is a way the software is intended to behave. Software has a functionality error if
something that you expect it to do is hard, awkward, confusing, or impossible.
E.x.
Expected Functionality for Cancel button is that the ‘Create new project’ window should close
and none of the changes should be saved (i.e. no new project must be created). If the Cancel
button is not clickable then it is a functionality error
2) Communication Errors:
These errors occur in communication from software to end-user. Anything that the end user
needs to know in order to use the software should be made available on screen.
Few examples of communication errors are – No Help instructions/menu provided, features that
are part of the release but are not documented in the help menu, a button named ‘Save’ should
not erase a file etc.
3) Missing command errors:
This happens to occur when an expected command is missing. See this screenshot:
E.X.:-Cancel’ option/button is not provided to the user, this is a missing command error.
4) Syntactic Error:
Syntactic errors are misspelled words or grammatically incorrect sentences and are very evident
while testing software GUI. Please note that we are NOT referring to syntax errors in code. The
compiler will warn the developer about any syntax errors that occur in the code
5) Error handling errors:
Any errors that occur while the user is interacting with the software needs to be handled in a
clear and meaningful manner. If not, it is called as an Error Handling Error.
Take a look at this image. The error message gives no indication of what the error actually is. Is
it missing mandatory field, saving error, page loading error or is it a system error? Hence, this is
an ‘Error Handing Error’.

6) Calculation Errors:
These errors occur due to any of the following reasons:
• Bad logic
• Incorrect formulae
• Data type mismatch
• Coding errors
• Function call issues , etc.
In 1999, NASA lost its Mars climate orbiter because one of the subcontractors NASA employed
had used English units instead of the intended metric system, which caused the orbiter’s thrusters
to work incorrectly. Due to this bug, the orbiter crashed almost immediately when it arrived at
Mars.
7) Control flow errors:
The control flow of a software describes what it will do next and on what condition.
For example, consider a system where user has to fill in a form and the options available to user
are: Save, Save and Close, and Cancel. If a user clicks on ‘Save and Close’ button, the user
information in the form should be saved and the form should close. If clicking on the button does
not close the form, then it is a control flow error.
Testing Objectives:
• To find any defects or bugs that may have been created when the software was being
developed
• To increase confidence in the quality of the software
• To prevent defects in the final product
• To ensure the end product meets customer requirements as well as the company
specifications
• To provide customers with a quality product and increase their confidence in the
company
• Testing Principles:
• Optimal testing – it's not possible to test everything so it's important to determine the
optimal amount. The decision is made using a risk assessment. This assessment will
uncover the area that is most likely to fail and this is where testing should take place.
• Pareto Principle – this principle states that approximately 80% of problems will be found
in 20% of tests. However, there is a flaw in this principle in that repeating the same tests
over and over again will mean no new bugs will be found.
• Review and Revise – repeating the same tests will mean that the methods will eventually
become useless for uncovering new defects. To prevent this from happens only requires
the tests to be reviewed and revised on a regular basis. Adding new tests will help to find
more defects.
• Defects that are present – testing reduces the probability of the being a defect in the final
product but does not guarantee that a defect won't be there. And even if you manage to
make a product that's 99% bug free, the testing won't have shown whether the software
meets the needs of clients.
• Meeting customer needs – testing a product for the wrong requirements is foolhardy.
Even if it is bug free it may still fail to meet customer requirements.
• Test early – it's imperative that testing starts as soon as possible in the development of a
product.
• Test in context – test a product in accordance with how it will be used Software is not
identical and will be developed to meet a certain need rather than a general one. Different
techniques, methodologies, approach and type of testing can be used depending on the
applications planned use.
Software Testing Fundamentals (STF):
STF: testing: The practice of investigating a software / system under test so as to ensure that it is
of the highest quality.
Why Software Testing?
Software that does not work correctly can lead to many problems such as:
Delay / Loss of time
Futility / Loss of effort
Wastage / Loss of money
Shame / Loss of business reputation
Injury or death
The three main goals of Software Testing are:
Defect Detection: Find defects / bugs in the software during all stages of its development (earlier,
the better).
Defect Prevention: As a consequence of defect detection, help anticipate and prevent defects
from occurring at later stages of development or from recurring in the future.
User Satisfaction: Ensure customers / users are satisfied that their requirements (explicit or
implicit) are met.
The three main goals of Software Testing are:
Defect Detection: Find defects / bugs in the software during all stages of its development (earlier,
the better).
Defect Prevention: As a consequence of defect detection, help anticipate and prevent defects
from occurring at later stages of development or from recurring in the future.
User Satisfaction: Ensure customers / users are satisfied that their requirements (explicit or
implicit) are met.
Software review:
• A software review is an effective way of filtering errors in a software product.
• Reviews conducted at each of these phases i.e., analysis, design, coding, and testing
reveal areas of improvement in the product.
• Reviews also indicate those areas that do not need any improvement.
• We can use software reviews to achieve consistency and uniformity across products.
• Reviews also make the task of product creation more manageable.
• Software review:
• Some of the most common software review techniques are:
i. Inspection
ii. Walkthrough
iii. Code review
iv. Formal Technical Reviews (FTR)
v. Pair programming
Formal Technical Review:
Software review:
A software review is an effective way of filtering errors in a software product. Reviews
conducted at each of these phases i.e., analysis, design, coding, and testing reveal areas of
improvement in the product. Reviews also indicate those areas that do not need any
improvement. We can use software reviews to achieve consistency and uniformity across
products. Reviews also make the task of product creation more manageable. Some of the most
common software review techniques are:
i. Inspection
ii. Walkthrough
iii. Code review
iv. Formal Technical Reviews (FTR)
v. Pair programming
Formal technical review (FTR):
1. A formal technical review is a software quality assurance activity performed by
software engineers.
2. In addition, the FTR serves as a training ground, enabling junior engineers to observe
the different approaches to software analysis, design, and implementation.
3. The objectives of FTR are
i. To uncover errors in function, logic, or implementation for representation of
software.
ii. To verify that software under review meets its requirements.
iii. To ensure that the software has been represented according to predefined
standards.
iv. To achieve software that is developed in a uniform manner. v. To make projects
more manageable.
Steps required to conduct a successful FTR:
1. The review meeting
 Every review meeting should be conducted by considering the following constraints:
a. Short duration Advance preparation
b. Involvement of people
c. walkthrough
 Rather than attempting to review the entire design; is conducted for modules or for a
small group of modules.
 The focus of the FTR is on the work product (a software component to be review).
The review meeting is attend by the review leader., all reviewers, and the producer.
 One of the reviewers becomes a recorder who records all the important issues raised
during the review. When errors are discovere, the recorder notes each error.
  At the end of the review, the attendees decide whether to accept the product or not,
with or without modification.
2. Review reporting and record-keeping
 During the FTR, the reviewer actively records all the issues that have been raised.
 At the end of the meeting, these all raised issues are consolidating and a review issues
list is prepare.
Finally, a formal technical review summary report is produce.
3. Review guidelines
 Guidelines for the conducting of formal technical review must be establish in advance.
 These guidelines must be distribute to all reviewers, agree upon, and then followed.
Software Testing Life Cycle:
Software Testing Life Cycle (STLC) is a sequence of specific activities conducted during the
testing process to ensure software quality goals are met. STLC involves both verification and
validation activities. Contrary to popular belief, Software Testing is not just a single/isolate
activity, i.e. testing. It consists of a series of activities carried out methodologically to help
certify your software product. STLC stands for Software Testing Life Cycle.

Requirement Phase Testing

Requirement Phase Testing also known as Requirement Analysis in which test team studies the
requirements from a testing point of view to identify testable requirements and the QA team may
interact with various stakeholders to understand requirements in detail. Requirements could be
either functional or non-functional. Automation feasibility for the testing project is also done in
this stage.
Activities in Requirement Phase Testing
 Identify types of tests to be performed.
 Gather details about testing priorities and focus.
 Prepare Requirement Traceability Matrix (RTM).
 Identify test environment details where testing is supposed to be carried out.
 Automation feasibility analysis (if required).
Deliverables of Requirement Phase Testing
 RTM
 Automation feasibility report. (if applicable)
Test Planning in STLC
Test Planning in STLC is a phase in which a Senior QA manager determines the test plan
strategy along with efforts and cost estimates for the project. Moreover, the resources, test
environment, test limitations and the testing schedule are also determined. The Test Plan gets
prepared and finalized in the same phase.
Test Planning Activities
 Preparation of test plan/strategy document for various types of testing
 Test tool selection
 Test effort estimation
 Resource planning and determining roles and responsibilities.
 Training requirement
Deliverables of Test Planning
 Test plan /strategy document.
 Effort estimation document.
Test Case Development Phase
The Test Case Development Phase involves the creation, verification and rework of test cases
& test scripts after the test plan is ready. Initially, the Test data is identified then created and
reviewed and then reworked based on the preconditions. Then the QA team starts the
development process of test cases for individual units.
Test Case Development Activities
  Create test cases, automation scripts (if applicable)
 Review and baseline test cases and scripts
 Create test data (If Test Environment is available)
Deliverables of Test Case Development
 Test cases/scripts
 Test data
Test Environment Setup
Test Environment Setup decides the software and hardware conditions under which a work
product is tested. It is one of the critical aspects of the testing process and can be done in parallel
with the Test Case Development Phase. Test team may not be involved in this activity if the
development team provides the test environment. The test team is required to do a readiness
check (smoke testing) of the given environment.
Test Environment Setup Activities
 Understand the required architecture, environment set-up and prepare hardware and
software requirement list for the Test Environment.
 Setup test Environment and test data
 Perform smoke test on the build
Deliverables of Test Environment Setup
 Environment ready with test data set up
 Smoke Test Results.
Test Execution Phase
Test Execution Phase is carried out by the testers in which testing of the software build is done
based on test plans and test cases prepared. The process consists of test script execution, test
script maintenance and bug reporting. If bugs are reported then it is reverted back to
development team for correction and retesting will be performed.
Test Execution Activities
 Execute tests as per plan
 Document test results, and log defects for failed cases
 Map defects to test cases in RTM
 Retest the Defect fixes
 Track the defects to closure
Deliverables of Test Execution
 Completed RTM with the execution status
 Test cases updated with results
 Defect reports
Test Cycle Closure
Test Cycle Closure phase is completion of test execution which involves several activities like
test completion reporting, collection of test completion matrices and test results. Testing team
members meet, discuss and analyze testing artifacts to identify strategies that have to be
implemented in future, taking lessons from current test cycle. The idea is to remove process
bottlenecks for future test cycles.
Test Cycle Closure Activities
 Evaluate cycle completion criteria based on Time, Test coverage, Cost,Software, Critical
Business Objectives, Quality
 Prepare test metrics based on the above parameters.
 Document the learning out of the project
 Prepare Test closure report
 Qualitative and quantitative reporting of quality of the work product to the customer.
 Test result analysis to find out the defect distribution by type and severity.
Deliverables of Test Cycle Closure
 Test Closure report
 Test metrics

White Box Testing:

• white box testing which also known as glass box is testing, structural testing, clear box
testing, open box testing and transparent box testing.
• It tests internal coding and infrastructure of a
• In this type of testing programming skills are required to design test cases.
• The primary goal of white box testing is to focus on the flow of inputs and outputs
through the software
• Developers do white box testing, then send the application or the software to the testing
team
Types of White Box Testing:
1. Statement Coverage Testing:
Checks whether every line (statement) of code is executed at least once.
Example
if (marks >= 40)
[Link]("Pass");
else
[Link]("Fail");
Test Case:
marks = 50
Result:
Executes the "Pass" statement.
2. Branch (Decision) Coverage Testing
Checks whether every decision (True and False) is tested.
Exampleif (age >= 18)
[Link]("Eligible");
else
[Link]("Not Eligible");
Test Cases
age = 20 → True branch
age = 15 → False branch
ResultBoth branches are tested.
3. Condition Coverage Testing
Checks whether each condition becomes True and False at least once.
Example
if (marks >= 40 && attendance >= 75) [Link]("Allowed");
Test Cases
Marks Attendance Result
50 80 True, True
35 80 False, True
50 70 True, False
Result:Each condition is tested for both True and False.
4. Multiple Condition Coverage Testing:
Tests all possible combinations of multiple conditions.
Example
if (A && B)
Test Cases
A B
True True
True False
False True
False False
ResultAll possible combinations are tested.
5. Path Coverage Testing
Checks every possible execution path in the program.
Example
A Login System may have these paths:
Correct username and password
Wrong password
Wrong username
Empty fields
Account locked
Result:
Every path is tested.
6. Loop Testing:
Checks whether loops work correctly for different numbers of iterations.
Example
for(int i = 1; i <= n; i++)
{
[Link](i);
}
Test Cases
n = 0 → Loop does not execute
n = 1 → Executes once
n = 5 → Executes five times
n = 1000 → Executes many times
Result:Loop works correctly in all cases.
7. Data Flow Testing
Checks whether variables are declared, assigned, and used correctly.
Correct Example
int total;
total = price * quantity;
[Link](total);
Incorrect Example
int total;
[Link](total);
Result:
The variable should be assigned a value before it is used.
8. Control Flow Testing
Checks the sequence of execution in a program.
Example:
Online Shopping System
User makes payment.
Order is updated.
Confirmation email is sent.
Result:
The steps should execute in the correct order.
9. Mutation Testing:
Small changes (mutations) are made in the code to check whether test cases can detect
errors.
Original Code
if (a > b)
Mutated Code
if (a >= b)
Result:
If test cases detect the change → Mutation is Killed (Good Testing)
If test cases do not detect the change → Mutation Survives (Need Better Test Cases)
9. Mutation Testing:
Small changes (mutations) are made in the code to check whether test cases can detect
errors.
Original Code
if (a > b)
Mutated Code
if (a >= b)
Result:
If test cases detect the change → Mutation is Killed (Good Testing)
If test cases do not detect the change → Mutation Survives (Need Better Test Cases)

Black Box Testing

Black box testing is a technique of software testing which examines the functionality of software
without peering into its internal structure or coding. The primary source of black box testing is a
specification of requirements that is stated by the customer.
In this method, tester selects a function and gives input value to examine its functionality, and
checks whether the function is giving expected output or not. If the function produces correct
output, then it is passed in testing, otherwise failed
Types of Black Box Testing
“Every Boy Drinks Sweet Uplifting Energy-EBDSUE”
1. Equivalence Partitioning (EP):
Input values are divided into valid and invalid groups (partitions).
One value is selected from each group for testing.
Example
Age allowed: 18–60 years
Test Input Partition Expected Result
25 Valid Accepted
15 Invalid Rejected
 65 Invalid Rejected
Benefit: Reduces the number of test cases.
2. Boundary Value Analysis (BVA)
Tests the boundary (edge) values, where errors are most likely to occur.
Example
Age allowed: 18–60 years
Test values:
17 → Invalid
18 → Valid
19 → Valid
59 → Valid
60 → Valid
61 → Invalid
Benefit: Finds errors at the limits of the input range.
3. Decision Table Testing
Used when the output depends on multiple conditions.
Example
Login System
Username Password Result
Correct Correct Login Successful
Correct Wrong Invalid Password
Wrong Correct Invalid Username
Wrong Wrong Login Failed
Benefit: Covers all possible combinations of conditions.
4. State Transition Testing
Checks how the system behaves when it moves from one state to another.
Example
ATM PIN Entry
State 1 → Enter PIN
Correct PIN → Access Account
Wrong PIN (3 times) → Card Blocked
Benefit: Ensures correct behavior during state changes.
5. Use Case Testing
Tests the software according to real user actions.
Example:
Online Shopping
Login
Search Product
Add to Cart
Make Payment
Order Confirmed
Benefit: Verifies complete user scenarios.
6. Error Guessing
The tester uses experience to guess where errors might occur.
Possible test cases:
Empty username
Empty password
Special characters
Very long input
Negative values
Benefit: Finds defects that formal techniques may miss.
Following table shows by using BBT these testing is performed.
Gray Box Testing
Gray Box Testing is a software testing technique in which the tester has partial knowledge of
the internal code or system design but tests the software mainly from the user's point of view.
It is a combination of White Box Testing and Black Box Testing.
White Box Testing → Tester knows everything about the code.
Black Box Testing → Tester knows nothing about the code.
Gray Box Testing → Tester knows some information about the code or database.
Example:Gray Box Testing
Online Shopping Website
The tester knows:
Products are stored in the Product Database.
The Cart Module is connected to the Payment Module.
The tester checks:
Add a product to the cart.
Make payment.
Verify that the order is stored correctly in the database.
Since the tester has some knowledge of the system's internal design but does not examine every
line of code, this is Gray Box Testing.

Difference Between BBT and WBT

Basis Black Box Testing (BBT) White Box Testing (WBT)

Testing the software without looking Testing the software by checking the
1. Definition
at the internal code. internal code and program logic.

Functional Testing or Behavioral Structural Testing, Glass Box Testing,

2. Also Called
Testing or Clear Box Testing

Checks whether the software works Checks whether the program code
3. Focus
according to requirements. works correctly.

4. Knowledge of No programming knowledge is

Programming knowledge is required.
Code required.

5. Basis of Software requirements, Source code, program structure, and

Testing specifications, and user needs. logic.

6. Performed By Testers or QA Engineers. Developers or White Box Testers.

7. Internal Internal code is hidden from the Internal code is completely visible to
Structure tester. the tester.
Basis Black Box Testing (BBT) White Box Testing (WBT)

8. Main To verify that the software performs To verify that every part of the code
Objective the correct functions. works correctly.

9. Test Cases Code paths, conditions, loops, and

Inputs, outputs, and expected results.
Based On statements.

10. Types of Missing features, incorrect Coding errors, logical errors, loop
Defects Found functionality, interface errors. errors, security issues.

11. Testing Mostly System Testing, Integration Mostly Unit Testing and Integration
Level Testing, and Acceptance Testing. Testing.

Covers code, branches, statements, and

12. Coverage Covers software functionality.
paths.

Equivalence Partitioning, Boundary Statement Coverage, Branch Coverage,

13. Techniques
Value Analysis, Decision Table, State Path Coverage, Condition Coverage,
Used
Transition Testing. Loop Testing.

14. Time Usually takes less time because code Usually takes more time because code
Required analysis is not needed. must be examined.

Validates software from the user's

Finds hidden coding errors and
15. Advantages perspective and does not require
improves code quality and security.
coding knowledge.

Checking whether a login page Checking whether the login program

16. Example accepts correct username and correctly validates the username and
password. password in the source code.

V & V Model
The Verification and Validation (V&V) Model is a software development and testing approach
in which testing activities are planned and performed at every stage of software
development. It helps ensure that the software is built correctly and also meets the user's needs.

Definition

V&V Model is an extension of the Waterfall Model where each development phase is
associated with a corresponding testing phase.

 Verification → Checks "Are we building the product right?"

 Validation → Checks "Are we building the right product?"

1. Verification Phases

This is where the process begins. The first step is to gather and understand the customer’s needs
for the software. The goal is to define the scope of the project clearly to make sure everyone is
on the same page.
 Static analysis is performed without executing the code.
 Verifies whether the product meets the specified requirements.
There are several Verification phases in the V-Model:
I. Business Requirement Analysis
 Gather and understand customer requirements.
 Prepare Acceptance Test Plans.
II. System Design
 Create high-level and detailed system design.
 Plan System Testing.
III. Architectural Design
 Define system architecture and module interactions.
 Prepare Integration Test Cases.
IV. Module Design (LLD)
 Design internal details of each module.
 Prepare Unit Test Cases.
V. Coding
 Develop the software based on the design.
 Follow coding standards and perform code reviews.

2. Validation Phases

It involves dynamic analysis techniques (functional, and non-functional), and testing done by
executing code. Validation is the process of evaluating the software after the completion of the
development phase to determine whether the software meets the customer's expectations and
requirements.
I. Unit Testing: In Unit testing, unit test plans are executed to eliminate bugs in code or unit
level.
II. Integration testing: After completion of unit testing integration testing is performed.
In integration testing, the modules are integrated and the system is tested.
3. System Testing: System testing checks the whole application to see if everything works
properly together.
4. User Acceptance Testing (UAT): User Acceptance Testing (UAT) is performed in a user
environment that resembles the production environment