Software Testing

Module II
Software Testing
• Testing is the process of evaluating a system or its
component(s) with the intent to find that whether it satisfies
the specified requirements or not.
• This activity results in the actual, expected and difference
between their results.
• In simple words testing is executing a system in order to
identify any gaps, errors or missing requirements in contrary
to the actual desire or requirements.
• According to ANSI/IEEE 1059 standard, Testing can be
defined as “A process of analyzing a software item to
detect the differences between existing and required
conditions (that is defects/errors/bugs) and to evaluate
the features of the software item”.
 Who does testing?
• It depends on the process and the associated stakeholders of the project(s).
• In the IT industry, large companies have a team with responsibilities to evaluate the developed
software in the context of the given requirements.
• Moreover, developers also conduct testing which is called Unit Testing.
• In most cases, following professionals are involved in testing of a system within their respective
capacities:
Software Tester
Software Developer
Project Lead/Manager
End User
• Different companies have difference designations for people who
test the software on the basis of their experience and knowledge
such as Software Tester, Software Quality Assurance Engineer,
and QA Analyst etc.
 When to Start Testing
• An early start to testing reduces the cost, time to rework and error free software

that is delivered to the client.

• However, in Software Development Life Cycle (SDLC) testing can be started from

the Requirements Gathering phase and lasts till the deployment of the software.

• It also depends on the development model that is being used. For example, in

Water fall model formal testing is conducted in the Testing phase, but in

incremental model, testing is performed at the end of every

increment/iteration and at the end the whole application is tested.

• Testing is done in different forms at every phase of SDLC like during
Requirement gathering phase, the analysis and verifications of
requirements are also considered testing.

• Reviewing the design in the design phase with intent to improve the
design is also considered as testing.

• Testing performed by a developer on completion of the code is also

categorized as Unit type of testing.
 When to Stop Testing
• Unlike when to start testing it is difficult to determine when to stop testing, as
testing is a never-ending process, and no one can say that any software is 100%
tested.
Following are the aspects which should be considered to stop the testing:
❑ Testing Deadlines.
❑ Completion of test case execution.
❑ Completion of Functional and code coverage to a certain point.
❑ Bug rate falls below a certain level, and no high priority bugs are identified.
❑ Management decision.
Difference between Verification & Validation

Verification Validation
Are you building it right? Are you building the right thing?
Ensure that the software system meets all the Ensure that functionalities meet the intended
functionality. behavior.
Verification takes place first and includes the Validation occurs after verification and mainly
checking for documentation, code etc. involves the checking of the overall product.
Done by developers. Done by Testers
Have static activities as it includes the Have dynamic activities as it includes
reviews, walkthroughs, and inspections to executing the software against the
verify that software is correct or not. requirements.
It is an objective process and no subjective It is a subjective process and involves
decision should be needed to verify the subjective decisions on how well the
Software. Software works.
Difference between Testing, Quality Assurance and Quality Control
 Difference between Audit and Inspection

• Audit: A systematic process to determine how the actual testing

process is conducted within an organization or a team. Generally, it is
an independent examination of processes which are involved during
the testing of software. As per IEEE, it is a review of documented
processes whether organizations implements and follows the processes
or not. Types of Audit include the Legal Compliance Audit, Internal
Audit, and System Audit.
• Inspection: A formal technique which involves the formal or informal technical
reviews of any artifact by identifying any error or gap. Inspection includes the
formal as well as informal technical reviews. As per IEEE94, Inspection is a formal
evaluation technique in which software requirements, design, or code are
examined in detail by a person or group other than the author to detect faults,
violations of development standards, and other problems.

• Formal Inspection meetings may have following process: Planning, Overview

Preparation, Inspection Meeting, Rework, and Follow-up.
Difference between Testing and Debugging

• Testing: It involves the identification of bug/error/defect in the

software without correcting it. Normally professionals with a
Quality Assurance background are involved in the identification
of bugs. Testing is performed in the testing phase.
Difference between Testing and Debugging

• Debugging: It involves identifying, isolating and fixing the

problems/bug. Developers who code the software conduct
debugging upon encountering an error in the code. Debugging
is the part of White box or Unit Testing. Debugging can be
performed in the development phase while conducting Unit
Testing or in phases while fixing the reported bugs.
 Characteristics of Software Test

1. High probability of detecting errors: To detect maximum errors, the tester

should understand the software thoroughly and try to find the possible ways in
which the software can fail. For example, in a program to divide two numbers,
the possible way in which the program can fail is when 2 and 0 are given as
inputs and 2 is to be divided by 0. In this case, a set of tests should be
developed that can demonstrate an error in the division operator.
2. No redundancy: Resources and testing time are limited in software
development process. Thus, it is not beneficial to develop several tests, which
have the same intended purpose. Every test should have a distinct purpose.
3. Choose the most appropriate test: There can be different tests that have
the same intent but due to certain limitations such as time and resource
constraint, only few of them are used. In such a case, the tests, which are likely
to find more number of errors, should be considered.
4. Moderate: A test is considered good if it is neither too simp1e, nor too
complex. Many tests can be combined to form one test case. However this can
increase the complexity and leave many errors undetected. Hence, all tests
should be performed separately.
 Testing Types
1. . Manual Testing
• This includes the testing of the Software manually i.e. without using any automated tool or any
script.
• In this type the tester takes over the role of an end user and test the Software to identify any un-
expected behavior or bug.
• There are different stages for manual testing like unit testing, Integration testing, System testing
and User Acceptance testing.
• Testers use test plan, test cases or test scenarios to test the Software to ensure the completeness
of testing.
• Manual testing also includes exploratory testing as testers explore the software to identify errors
in it.
 2. Automation Testing

• Automation testing which is also known as “Test Automation”, is when the

tester writes scripts and uses another software to test the software.
• This process involves automation of a manual process.
• Automation Testing is used to re-run the test scenarios that were
performed manually, quickly and repeatedly.
• Apart from regression testing, Automation testing is also used to test the
application from load, performance and stress point of view.
• It increases the test coverage; improve accuracy, saves time and money in
comparison to manual testing
 Testing Methods
Black Box Testing:
• The technique of testing without having any knowledge of the interior
workings of the application is Black Box testing.
• The tester is oblivious to the system architecture and does not have access
to the source code.
• Typically, when performing a black box test, a tester will interact with the
system’s user interface by providing inputs and examining outputs without
knowing how and where the inputs are worked upon.
 Advantages:

• Well suited and efficient for large code segments.

• Code Access not required.
• Clearly separates user’s perspective from the developer’s
perspective through visibly defined roles.
• Large numbers of moderately skilled testers can test the application
with no knowledge of implementation, programming language or
operating systems.
 Disadvantages:
• Limited Coverage since only a selected number of test scenarios are
actually performed.
• Inefficient testing, due to the fact that the tester only has limited
knowledge about an application.
• Blind Coverage, since the tester cannot target specific code
segments or error prone areas.
• The test cases are difficult to design.
 White Box Testing
• White box testing is the detailed investigation of internal logic and
structure of the code.
• White box testing is also called glass testing or open box testing.
• In order to perform white box testing on an application, the tester
needs to possess knowledge of the internal working of the code.
• The tester needs to have a look inside the source code and find out
which unit/chunk of the code is behaving inappropriately.
Advantages:
• As the tester has knowledge of the source code, it becomes very easy to
find out which type of data can help in testing the application
effectively.
• It helps in optimizing the code.
• Extra lines of code can be removed which can bring in hidden defects.
• Due to the tester's knowledge about the code, maximum coverage is
attained during test scenario writing.
 Disadvantages:
• Due to the fact that a skilled tester is needed to perform white box
testing, the costs are increased.
• Sometimes it is impossible to look into every nook and corner to
find out hidden errors that may create problems as many paths will
go untested.
• It is difficult to maintain white box testing as the use of specialized
tools like code analyzers and debugging tools are required.
 Grey Box Testing

• In black box testing, we don’t have access to the internal coding, and there is no
need to understand the coding. But in white box testing, we must work with the
internal coding, structure, and algorithm.

• Grey box testing is where these two merges and the tester has partial knowledge
of the internal details of your systems and the outer details as per the
requirements.

• The testing becomes helpful in system integration testing, web application

testing, security, and business domain testing.
 Advantages

• Improved test coverage: You have to perform this testing both through the
aspect of developers and testers. Hence it will earn more test coverage and
thereby improves your product quality.

• Efficient use of resources: It’s a type of semi-transparent testing. The testers

know the working process of different components for this testing. They can
access several documents, database diagrams, flow charts, and more. Thus, the
testers can create the best test scenarios for testing.
• Early detection of defects: This testing gives the testers partial
knowledge of software codes, users’ perspectives (how to operate
the system), and how to protect them from potential
attackers. Thus adopting different knowledge, the testers identify
issues you can’t detect from other testing. As a result, the testers
detect the bugs in the early stages and the developers get enough
time to fix them.
 Disadvantages

• Limited access to internal code: You don’t need to understand the entire
internal structure and algorithm for this testing. Thus, there will be limited
access to the internal coding of the system, and sometimes it becomes
difficult to find out the root causes of the defects.
• Dependency on system knowledge: For this kind of testing, there is no
necessity to know the thorough implementation of the system. So, it
indicates a need for more knowledge of the testers about the system. Thus
testers may need help to create test cases for complex systems.
 Black-box testing Techniques

• Black box testing is a software testing method used to test a system

without having any prior knowledge of the internal structure of the
software under test.

• Instead, the focus is on how the system works as a whole.

• Specifically, this testing approach focuses on the input that goes into the
software and the output that is produced to see whether the expected
results are achieved.
• To better explain how this works, let’s look at a simple example.
• Let’s say we want to test the Calculator application on our phone. We
open the application, enter the numbers we want to calculate as well as
the operator and equal sign, and wait for the output.
• Another example would be testing a social application. Black box testing
in this case would be inputting a username and password, while the
expected output would be getting logged into the application. In both
examples, we input information and wait for the output without looking
at the code.
 Equivalence partitioning (EP)

• Equivalence partitioning is a technique that divides test objects into partitions or classes that are
treated and tested in the same way.

• This technique is used for testing a range of values, inputs, and outputs.

• There are valid and invalid equivalence partitions.

• Valid equivalence partitions contain only the valid values that are accepted by the testing object.

• In contrast, invalid equivalence partitions contain only invalid values that are rejected by the testing
object.

• When using this technique to design test cases, there are several important things that you need to
remember.
• First of all, every single value belongs only to one of the partitions. Secondly, you
must always test valid and invalid partitions. Finally, you must test invalid partitions
individually because otherwise, they will mask the results. If there is a need, you can
divide the partitions into sub-partitions.

• To achieve 100% coverage of the testing object with this technique, you must test at
least one representative member from each partition. You can do that by taking one
value from each defined valid and invalid partition. You will not increase coverage by
testing two values from the same partition.
Example of equivalence partitioning:

• The discount is calculated depending on the total amount of the shopping

cart.

• If the total amount is in the range of $100–$200, the discount is 10%. If

the total amount is in the range of $201–$500, the discount is 20%. If the
total amount is more than $500, the discount is 30%.

• In this scenario, we can identify three valid partitions and one invalid
partition for the amount under $100.
• To apply equivalence partitioning, we can take one value from
each partition: $140 from the first valid partition, $370 from
the second valid partition, $530 from the third valid partition,
and $78 from the invalid partition.

• Now we have four test cases and have achieved 100% coverage
because all defined partitions are covered.
Boundary value analysis (BVA)

• This technique is an extension of equivalence partitioning and is used to test the boundaries
of the valid and invalid partitions.

• These boundaries are breaking points that are most likely to be incorrect.

• Also, both these black box testing techniques—equivalence partitioning and boundary value
analysis—can be combined.

• There are two types of boundary value analysis, two-value and three-value boundary
analysis. We use two-value boundary analysis to test the minimum and maximum values of
the boundary. In comparison, we use three-value boundary analysis to test the values
before the boundary, at the boundary, and just above the boundary.
 Example of two-value boundary
analysis:

• Let’s look at the same discount scenario from earlier.

• The discount is calculated based on the total amount of the shopping cart.
If the total amount is in the range of $100–$200, the discount is 10%. If the
total amount is in the range of $201–$500, the discount is 20%. If the total
amount is more than $500, the discount is 30%.

• With a simple illustration, we can define the boundaries very easily.

To apply two-value boundary analysis we will test the
minimum and maximum value of each boundary: $99, $100,
$200, $201, $500, and $501. We have six test cases and we
will achieve 100% coverage by testing them because all
defined boundaries are covered.
 Example of three-value boundary
analysis:

• To apply three-value boundary analysis, we will test the following values:

$99, $100, $101, $199, $200, $201, $499, $500, and $501. This gives us
nine test cases and ensures 100% coverage, as all defined boundaries are
covered.
• If we use a combination of equivalence partitioning and boundary value
analysis in this example, we will test $78, $140, $370, and $530
(equivalence partitioning), as well as $99, $100, $200, $201, $500, and
$501 (boundary value analysis).
 Decision table testing

• The decision table testing technique is used to visually present the

different combinations of inputs and outputs and is more focused on
business rules.

• We use decision table testing in situations where different combinations of

test input conditions result in different outputs.

• With this technique, we identify the conditions and the resulting actions of
the testing object and present them in a table.
Example of decision table testing:

• Often conditions are the inputs, usually at the top, and actions are the
outputs, usually defined at the bottom of the table.

• The first column of the table is an explanation of the conditions and

actions. Every other column in the table represents one decision rule.
When the condition or action is TRUE we use Y, T, or 1. When the condition
or action is FALSE we use N, F, or 0. When the value doesn’t matter we use
– or N/A.
• The discount is calculated depending on the total amount of the shopping cart and whether the
customer is a member.

• If the total amount is more than $200 and the customer is a member, the discount is 10%.

• If the customer is not a member, there is no discount regardless of the total amount in the
shopping cart.

• To use the decision table testing technique, we first need to identify the conditions. In this case,
the conditions are the total amount in the shopping cart and whether a customer is a member or
not. Next, we need to identify all combinations of these conditions. We will mark them with Y
and N.
The next step is to identify the correct actions/outcomes for each combination. We will
use Y and N to mark them.
 State transition testing

• State transition testing is a black box testing technique that is used when a system
responds differently to the same input and depends on current conditions and
previous history.

• The previous history of the system is called the state, while an event is an
occurrence that can result in a transition.

• A state transition diagram or state transition table is a representation of the system’s

states and events that are causing transitions between states. One event can cause
different transitions to the same state.
• An example of an event would be a user entering a pin into
an ATM. The event causes a change in the state, which
results in an action from the test object.
• A possible action in this case would be the ATM screen
displaying either the available services or an error message,
depending on whether the user input is correct or not.
• We can use this technique to design test cases that can evaluate whether
the test object executes the valid transitions and blocks the invalid ones
successfully. State transition testing is used within the embedded software
industry for testing screen-based applications, such as an ATM, or for
testing any other transitional software.

• We can achieve 100% coverage by testing every transition and state at

least once.
 Example of state transition testing:

• After shopping, we put the receipt in the parking machine that calculates whether we get a
coupon for free parking.
• To get a coupon, the receipt must be in good condition and have an amount that is equal to
or greater than $200.
• First, the machine checks if the receipt is damaged. If the receipt is damaged, the machine
will reject it.
• If the receipt is not damaged, the machine checks if the total amount is equal to or greater
than $200.
• If the total amount is under $200, the receipt will be rejected. If the total amount is equal to
or greater than $200, we will get a coupon for free parking.
In this example, we have three test cases for state coverage and also three test cases for
transition coverage:
Test case 1: Enter the receipt > Receipt is damaged > Receipt is rejected.
Test case 2: Enter the receipt > Receipt is not damaged > Receipt is < $200 > Receipt is
rejected.
Test case 3: Enter the receipt > Receipt is not damaged > Total amount is => $200 > Get
coupon.
 Error Guessing

• Error guessing is a technique in which testers use their experience and

intuition to anticipate where defects might occur.
• Unlike other testing methods that rely on predefined criteria or rules, error
guessing involves making educated guesses.
• These guesses are based on past experience, common errors, and known
problem areas.
• Testers may focus on complex areas of the application that are prone to
mistakes or have a history of issues.
 Error Guessing Example
Suppose you have a bank account where you need to deposit money, but the deposit amount must be between $5000
and $7000. Using error guessing, you would try various deposit amounts, including those around the boundary values
and those outside the valid range, to identify potential issues.

For instance, you would test:

• A deposit of $4999 (just below the minimum boundary)

• A deposit of $5000 (minimum valid amount)

• A deposit of $6000 (mid-range valid amount)

• A deposit of $7000 (maximum valid amount)

• A deposit of $7001 (just above the maximum boundary)

• By testing these values, you can identify whether the system correctly accepts valid deposits. You can also
determine if it properly rejects and shows error messages on amounts outside the acceptable range.
 White Box Testing With an Example

White Box Testing is also known by other names such as:

• Clear Box Testing

• Transparent Box Testing

• Glass Box Testing

• Structural Testing

• Code-Based Testing

White Box Testing is a software testing process that includes studying an application’s core
structure and logic. It is carried out at the code level, where the tester has access to the source
code and is knowledgeable of the internal implementation of the product.
Example

Let’s consider a simple example of white box testing for a function that
calculates the area of a rectangle:
def calculate_rectangle_area(length, width):
if length <= 0 or width <= 0:
return “Invalid input: Length and width must be positive numbers.”
else:
area = length * width
return area
Now, let’s create some test cases to perform
white box testing on this function:

Test Case 1: Valid Input Test Case 4: Valid Input (Floating-Point

• Input: length = 5, width = 3 Numbers)
• Expected Output: 15 •Input: length = 4.5, width = 2.5
Test Case 2: Invalid Input (Negative Value) •Expected Output: 11.25
• Input: length = -2, width = 4 Test Case 5: Valid Input (Large Numbers)
• Expected Output: “Invalid input: Length and •Input: length = 1000, width = 10000
width must be positive numbers.” •Expected Output: 10,000,000
Test Case 3: Invalid Input (Zero Value)

• Input: length = 0, width = 6

• Expected Output: “Invalid input: Length and

width must be positive numbers.”
• In this situation, white box testing entails analyzing the function’s
core logic and creating test cases to make sure all code paths are
covered.

• In order to determine if the function operates as intended in various

contexts, test cases are designed to assess both valid and invalid
inputs.

• White box testing allows us to both confirm that the function is

correct and find any possible defects or implementation problems.
White Box Testing Techniques
 Statement Coverage:
• Statement coverage is one of the widely used software testing. It comes
under white box testing.
• Statement coverage technique is used to design white box test cases. This
technique involves execution of all statements of the source code at least
once. It is used to calculate the total number of executed statements in the
source code out of total statements present in the source code.
• Statement coverage derives scenario of test cases under the white box
testing process which is based upon the structure of the code.
Let's understand the process of calculating statement coverage by an
example:
Here, we are taking source code to create two different scenarios according
to input values to check the percentage of statement coverage for each
scenario.
Source Code Structure:
• Take input of two values like a=0 and b=1.
• Find the sum of these two values.
• If the sum is greater than 0, then print "This is the positive result."
• If the sum is less than 0, then print "This is the negative result."
1. input (int a, int b)
2. {
3. Function to print sum of these integer values (sum = a+b)
4. If (sum>0)
5. {
6. Print (This is positive result)
7. } else
8. {
9. Print (This is negative result)
10. }
11. }
Now, let's see the two different scenarios and calculation of the
percentage of Statement Coverage for given source code.
Scenario1:
If a = 5, b = 4

1. print (int a, int b) {

2. int sum = a+b;
3. if (sum>0)
4. print ("This is a positive result")
5. else
6. print ("This is negative result")
7. }
In scenario 1, we can see the value of sum will be 9 that is greater than 0
and as per the condition result will be "This is a positive result."
To calculate statement coverage of the
first scenario, take the total number of
statements that is 7 and the number of
used statements that is 5.
1.Total number of statements = 7
2.Number of executed statements = 5
Statement coverage = 5/7*100
= 500/7
= 71%
Scenario 2:
If A = -2, B = -7
1. print (int a, int b) {
2. int sum = a+b;
3. if (sum>0)
4. print ("This is a positive result")
5. else
6. print ("This is negative result")
7. }
In scenario 2, we can see the value of sum will be -9 that is less than 0
and as per the condition, result will be "This is a negative result."
To calculate statement coverage of the first scenario, take the
total number of statements that is 7 and the number of used
statements that is 6.
Total number of statements = 7
Number of executed statements = 6
Statement coverage = 6/7*100
= 600/7
= 85%
 But, we can see all the statements are covered in both scenario
and we can consider that the overall statement coverage is
100%.

So, the statement coverage technique covers dead code, unused code, and
branches.
 Branch Coverage Testing

• 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.

• However, branch coverage technique and decision coverage technique are very similar, but
there is a key difference between the two. Decision coverage technique covers all branches of
each decision point whereas branch testing covers all branches of every decision point of the
code.
• Like decision coverage, it also uses a control flow graph to
calculate the number of branches.
How to calculate Branch coverage?

• There are several methods to calculate Branch coverage, but pathfinding

is the most common method.

• In this method, the number of paths of executed branches is used to

calculate Branch coverage. Branch coverage technique can be used as
the alternative of decision coverage. Somewhere, it is not defined as an
individual technique, but it is distinct from decision coverage and
essential to test all branches of the control flow graph.
Example:

This is the basic code structure where we took

two variables X and Y and two conditions. If the
first condition is true, then print "Large" and if it
is false, then go to the next condition. If the
second condition is true, then print "Small."
Control flow graph of code structure

In the above diagram, control flow graph of code is

depicted. In the first case traversing through "Yes
"decision, the path is A1-B2-C4-D6-E8, and the
number of covered edges is 1, 2, 4, 5, 6 and 8 but
edges 3 and 7 are not covered in this path. To cover
these edges, we have to traverse through "No"
decision. In the case of "No" decision the path is A1-
B3-5-D7, and the number of covered edges is 3 and
7. So by traveling through these two paths, all
branches have covered.
 Control/Path Flow Testing
• Control flow testing is a testing technique that comes under white box testing. The aim of
this technique is to determine the execution order of statements or instructions of the
program through a control structure.

• The control structure of a program is used to develop a test case for the program. In this
technique, a particular part of a large program is selected by the tester to set the testing
path. It is mostly used in unit testing. Test cases represented by the control graph of the
program.

• Control Flow Graph is formed from the node, edge, decision node, junction node to
specify all possible execution path.
Example
Diagram- Control Flow Graph
• The above example shows eligibility criteria of age for voting where if
age is 18 or more than 18 so print message "You are eligible for voting"
if it is less than 18 then print "You are not eligible for voting."
• Program for this scenario is written above, and the control flow graph
is designed for the testing purpose.
• In the control flow graph, start, age, eligible, not eligible and stop are
the nodes, n>=18 is a decision node to decide which part (if or else) will
execute as per the given value. Connectivity of the eligible node and
not eligible node is there on the stop node.
• Test cases are designed through the flow graph of the programs to
determine the execution path is correct or not. All nodes, junction,
edges, and decision are the essential parts to design test cases.
 Decision Coverage Testing

• Decision coverage technique comes under white box testing which gives
decision coverage to Boolean values. This technique reports true and false
outcomes of Boolean expressions. Whenever there is a possibility of two or
more outcomes from the statements like do while statement, if statement
and case statement (Control flow statements), it is considered as decision
point because there are two outcomes either true or false.

• Decision coverage covers all possible outcomes of each and every Boolean
condition of the code by using control flow graph or chart.
• In this technique, it is tough to get 100% coverage because

sometimes expressions get complicated.

• Due to this, there are several different methods to report decision

coverage. All these methods cover the most important

combinations and very much similar to decision coverage.

 Example

Consider the code to apply on decision coverage technique:

1. Test (int a)
2. {
3. If(a>4)
4. a=a*3
5. Print (a)
6. }
• Scenario 1:
Value of a is 7 (a=7)The code highlighted in
yellow is executed code. The outcome of this
code is "True" if condition (a>4) is checked.

• Control flow graph when the value of a is 7.

Calculation of Decision Coverage percent:
Decision Coverage = ½*100
(Only "True" is exercised)
=100/2
= 50
Decision Coverage is 50%
Scenario 2:
Value of a is 3 (a=3)
1. Test (int a=3)
2. { if (a>4)
3. a=a*3
4. print (a)
5. }
The outcome of this code is “False” if condition (a>4) is
checked. Control flow graph when the value of a is 3
Calculation of Decision Coverage
percent:
= ½*100 (Only "False" is exercised) <br>

=100/2
= 50
Decision Coverage = 50%
Result table of Decision Coverage:
 Stress Testing

• Stress Testing is testing used to check the accessibility and

robustness of software beyond usual functional limits. It
mainly considers for critical software, but it can also be used
for all types of software applications.
• It is also known as Endurance Testing, fatigue testing or Torture Testing.

• The stress testing includes the testing beyond standard operational size, repeatedly to a breaking point,
to get the outputs.

• It highlights the error handling and robustness under a heavy load instead of correct behavior under
regular conditions.

• In other words, we can say that Stress testing is used to verify the constancy and

• dependability of the system and also make sure that the system would not crash under disaster
circumstances.

• To analyses how the system works under extreme conditions, we perform stress testing outside the
normal load.
 Objective of Stress Testing

• The primary purpose of executing the stress testing is to confirm that the software does not crash in
lacking computational resources like disk space, memory, and network request.

• The implementation of stress testing certifies that the system fails and improves effortlessly, known
as the recoverability process.

• We can use stress testing to discover hardware issues, data corruption issues.

• Stress testing will help us to identify the security weaknesses that might sneak-in throughout
constant peak load.

• It helps determine the software application's data integrity throughout the extreme load, which
implies that the data should be in a dependable state after a failure.
Why do we need to perform the Stress
Testing?
We need to perform stress testing if we encounter the following situations:
• Whenever e-commerce or online shopping sites announce a sale during
the festival may witness a spike in traffic. Or when an article is mentioned
in a top newspaper, its knowledges an unexpected flow in traffic.
• If we fail to assist this sudden traffic can result in loss of profits and status.
So, in that case, we need to execute the Stress Testing to integrate such
irregular traffic spikes.
• Stress testing is also needed to be performed for the below scenarios:

• When the system is under stress, it should display a proper error message.

• To inspect whether the system works under bizarre circumstances.

• If the system is failed under risky situations could result in huge profits loss.

• By implementing Stress Testing, we will be prepared for extreme conditions.

 Example of Stress Testing
Example 1: E-commerce website/ application
• Throughout the new product releases, sales, holidays, promotions, and festival
offers, the e-commerce application tends to get many users in a very short time.
Example 2: News website at the time of some major/viral event
• The news website will crash or slow down when a major event happens; for
example, when Michael Jackson passed away, a maximum number of news
websites are slow down, or some of them also crashed.
• To overcome this situation, we need to perform stress testing on the particular
application and be prepared to recover quickly in case of any crashes or failure.
Example 3: Education Board's result website

• Stress testing is important to perform on the education board's result

website. On the day of some results, many students, users, and applicants
will logins to the particular to check their grades.

• Therefore, the execution of stress testing helps identify the failure of the
application and evaluate the performance and recoverability when the
ultimate load occurs in a short duration or when the result is out.
 Performance Testing

It is the most important part of non-functional testing.

“Checking the behavior of an application by applying
some load is known as performance testing.”
Generally, this testing defines how quickly the server responds to the
user's request.
• While doing performance testing on the application, we will concentrate on the
various factors like Response time, Load, and Stability of the application.
• Response time: Response time is the time taken by the server to respond to the
client's request.
• Load: Here, Load means that when N-number of users using the application
simultaneously or sending the request to the server at a time.
• Stability: For the stability factor, we can say that, when N-number of users using
the application simultaneously for a particular time.
When we use performance testing?

• We will do performance testing once the software is

stable and moved to the production, and it may be
accessed by the multiple users concurrently, due to this
reason, some performance issues may occur. To avoid
these performance issues, the tester performs one
round of performance testing.
Types of Performance Testing
 Load Testing
Load testing determines the behavior of the application when multiple users use it at the same
time. It is the response of the system measured under varying load conditions.

1. The load testing is carried out for normal and extreme load conditions.

2. Load testing is a type of performance testing that simulates a real-world load on a system or
application to see how it performs under stress.

3. The goal of load testing is to identify bottlenecks and determine the maximum number of
users or transactions the system can handle.

4. It is an important aspect of software testing as it helps ensure that the system can handle
the expected usage levels and identify any potential issues before the system is deployed to
production.
• During load testing, various scenarios are simulated to test
the system’s behavior under different load conditions. This
can include simulating a high number of concurrent users,
simulating numerous requests, and simulating heavy
network traffic. The system’s performance is then measured
and analyzed to identify any bottlenecks or issues that may
occur.
 Scalability Testing

• Scalability Testing is a non-functional testing method that

measures performance of a system or network when the number
of user requests are scaled up or down.
• The purpose of Scalability testing is to ensure that the system can
handle projected increase in user traffic, data volume,
transaction counts frequency, etc. It tests system ability to meet
the growing needs.
 Why do Scalability Testing

• Scalability testing lets you determine how your application scales

with increasing workload.
• Determine the user limit for the Web application.
• Determine client-side degradation and end user experience under
load.
• Determine server-side robustness and degradation.
Scalability testing Vs Load testing

Scalability Testing Load Testing

• It focusses on the performance of •Load testing focusses on

websites, software, hardware, and testing an application under
application when changes are heavy loads, to determine at
done in the size or volume of the what point the system
system to meet a growing need.
response time fails.
 Stability Testing
• Stability testing is a software testing procedure where we
analyze the application's performance by applying the load
for a particular duration of time.
• For the stability factor, we can say that when N-number of
users using the application simultaneously for a particular
time.
• Stability testing will provide the advanced substance
in software dependability, error handling, robustness, and
scalability of an application under massive load instead of
analyzing the system behavior under usual conditions.
 Why do we need to perform Stability
Testing?

• It helps us to detect the bugs when the system is pushed to strict

circumstances and fix those bugs or defects that can increase the
software's constancy or the application.
• The life of the software is enhanced if we execute the stability testing.
• If we performed stability tests endlessly, we could identify the constancy of
the product.
• If we prepare the system in advance, we can endure any stress/
 Alpha, Beta and Gamma testing

Alpha Testing
Alpha testing is an initial phase of software
testing where a group of internal testers
assesses the software for defects before it is
released to external users.
Alpha testing simulates end-users actions to
verify software behavior under real-life
conditions.
Beta Testing
Beta testing involves releasing the software to
a limited group of external users to gather
real-world feedback and identify potential
issues before a wider release.
It is often pre-release, involves a limited
number of end users (beta testers) verifying
software compatibility, providing feedback on
usability, and detecting bugs.
Gamma Testing
Gamma testing, also known as “Release
candidate testing,” is conducted after Beta
Testing. It is concentrated on security and
functionality and is conducted without in-house
QA activities. Only a limited number of users
participate.
Gamma testing focuses on ensuring the product
is ready for a broader audience.
 Test cases
Test Case: A set of conditions or variables under which a tester determines whether a system, software
application, or one of its features is working as expected. Each test case is a specific scenario that the
software must handle, often including:

• Test Case ID: A unique identifier.

• Test Description: A brief description of the test scenario.

• Preconditions: Any setup or conditions that must be met before the test can be executed.

• Test Steps: The specific actions that need to be performed to carry out the test.

• Expected Result: The anticipated outcome if the system behaves as expected.

• Actual Result: The outcome observed when the test is executed.

• Pass/Fail Criteria: Determines whether the test case has passed or failed.
 Example Test Case
• Test Case ID: TC001

• Test Description: Verify login functionality with valid credentials.

• Preconditions: User is on the login page.

• Test Steps:
• Enter a valid username.

• Enter a valid password.

• Click the "Login" button.

• Expected Result: User is successfully logged in and redirected to the dashboard.

• Actual Result: (To be filled after testing)

• Pass/Fail Criteria: (To be determined after testing)

 Test Suites

• Test Suite: A collection of test cases intended to be executed together to test a particular component or system

behavior. Test suites are organized to focus on specific areas of functionality and are used to ensure comprehensive

testing.

• Types of Test Suites:

• Smoke Test Suite: A minimal set of tests to check the basic functionality of the system.

• Regression Test Suite: A set of tests designed to ensure that new code changes do not adversely affect existing

functionality.

• Functional Test Suite: Contains test cases that verify the functional aspects of a particular feature or module.

• Performance Test Suite: Focuses on the performance aspects such as speed, responsiveness, and stability under

load.
Example Test Suite
• Suite Name: Login Module Test Suite
• Description: Test cases to validate the login functionality of the
application.
• Included Test Cases:
• TC001: Verify login with valid credentials.
• TC002: Verify login with invalid credentials.
• TC003: Verify the behavior when the "Forgot Password" link is clicked.
• TC004: Verify session timeout after inactivity.
 TEST PLAN
• A test plan is a document that consists of all future testing-related activities.

• It is prepared at the project level and in general, it defines work products to be

tested, how they will be tested, and test type distribution among the testers.

• Before starting testing there will be a test manager who will be preparing a
test plan.

• In any company whenever a new project is taken up before the tester is

involved in the testing the test manager of the team would prepare a test Plan.
 Test case specification

• Test case specification is the documentation detailing

how a certain part of the software is to be tested.

• It describes the goals and scope of a test case, what is to

be provided as input, the conditions under which the test
case is to be conducted, and the expected results.
 Importance of Test Specification

• Clarity and Consistency: Test case specifications also make it easier for
all the team members to know what has to be tested and how it has to
be done since the framework for testing is clearly laid down. This is
useful in ensuring that the quality of the software being developed is
consistent between one development cycle and the other.
• Traceability: Test case specifications help to connect the requirements
and test cases. This means that every requirement is associated with a
test case and therefore the functionalities are tested and checked.
• Reusability: Test case specifications can be written down and
documented for future use and this can help in cutting down the
time and costs of testing. They can also be used in similar projects
to improve efficiency.

• Risk Mitigation: This way, possible risks and defects are detected
and reported from the very beginning of the development
process, so that they cannot cause problems in the production
environment.
 Software Testing Life Cycle.

• The Software Testing Life Cycle (STLC) is a systematic

approach to testing a software application to ensure that it
meets the requirements and is free of defects.
• It is a process that follows a series of steps or phases, and
each phase has specific objectives and deliverables.
• The STLC is used to ensure that the software is of high
quality, reliable, and meets the needs of the end-users.
 Phases of STLC

1. Requirement Analysis: Requirement Analysis is the first

step of the Software Testing Life Cycle (STLC).
• In this phase quality assurance team understands the
requirements like what is to be tested.
• If anything is missing or not understandable then the quality
assurance team meets with the stakeholders to better
understand the detailed knowledge of requirements.
2. Test Planning: Test Planning is the most efficient phase of
the software testing life cycle where all testing plans are
defined.
• In this phase manager of the testing, team calculates the
estimated effort and cost for the testing work.
• This phase gets started once the requirement-gathering
phase is completed.
3. Test Case Development: The test case development phase
gets started once the test planning phase is completed.
• In this phase testing team notes down the detailed test
cases.
• The testing team also prepares the required test data for the
testing.
• When the test cases are prepared then they are reviewed by
the quality assurance team.
4. Test Environment Setup: Test environment setup is a vital part of the STLC.

• Basically, the test environment decides the conditions on which software is

tested.

• This is independent activity and can be started along with test case

development.

• In this process, the testing team is not involved. either the developer or the

customer creates the testing environment.

5. Test Execution: After the test case development
and test environment setup test execution phase
gets started.
• In this phase testing team starts executing test
cases based on prepared test cases in the earlier
step.
6. Test Closure: Test closure is the final stage of the
Software Testing Life Cycle (STLC) where all testing-
related activities are completed and documented.

• The main objective of the test closure stage is to ensure

that all testing-related activities have been completed
and that the software is ready for release.
END OF MODULE II