Unit-4: Software Testing & Debugging 12 hours

Testing Fundamentals- Error, Fault & Failure, Black Box Testing- Equivalence
Partitioning, Boundary value Analysis, White Box Testing- Control flow-based
Testing, Data flow-based Testing, Testing Strategies- Verification & Validation, Unit
Testing, Integration Testing, System Testing, Acceptance Testing, Deriving Test Cases,
Alpha and Beta Testing, Regression Testing, Performance Testing, Stress Testing,
Debugging.

Software Testing – Bug vs Defect vs Error vs Fault vs Failure

Software Testing defines a set of procedures and methods that check whether the
actual software product matches with expected requirements, thereby ensuring
that the product is Defect free. There are a set of procedures that needs to be in
mind while testing the software manually or by using automated procedures. The
main purpose of software testing is to identify errors, deficiencies, or missing
requirements with respect to actual requirements. Software Testing is Important
because if there are any bugs or errors in the software, they can be identified
early and can be solved before the delivery of the software product. The article
focuses on discussing the difference between bug, defect, error, fault, and failure.

What is a Bug?
A bug refers to defects which means that the software product or the application
is not working as per the adhered requirements set. When we have any type of
logical error, it causes our code to break, which results in a bug. It is now that
the Automation/ Manual Test Engineers describe this situation as a bug.
 A bug once detected can be reproduced with the help of standard bug-
reporting templates.
 Major bugs are treated as prioritized and urgent especially when there is a
risk of user dissatisfaction.
 The most common type of bug is a crash.
 Typos are also bugs that seem tiny but are capable of creating disastrous
results.
What is a Defect?
A defect refers to a situation when the application is not working as per the
requirement and the actual and expected result of the application or software are
not in sync with each other.
 The defect is an issue in application coding that can affect the whole
program.
 It represents the efficiency and inability of the application to meet the criteria
and prevent the software from performing the desired work.
 The defect can arise when a developer makes major or minor mistakes during
the development phase.
What is an Error?
Error is a situation that happens when the Development team or the developer
fails to understand a requirement definition and hence that misunderstanding gets
translated into buggy code. This situation is referred to as an Error and is mainly
a term coined by the developers.
 Errors are generated due to wrong logic, syntax, or loop that can impact the
end-user experience.
 It is calculated by differentiating between the expected results and the actual
results.
 It raises due to several reasons like design issues, coding issues, or system
specification issues and leads to issues in the application.
What is a Fault?
Sometimes due to certain factors such as Lack of resources or not following
proper steps Fault occurs in software which means that the logic was not
incorporated to handle the errors in the application. This is an undesirable
situation, but it mainly happens due to invalid documented steps or a lack of data
definitions.
 It is an unintended behavior by an application program.
 It causes a warning in the program.
 If a fault is left untreated it may lead to failure in the working of the deployed
code.
 A minor fault in some cases may lead to high-end error.
 There are several ways to prevent faults like adopting programming
techniques, development methodologies, peer review, and code analysis.
What is a Failure?
Failure is the accumulation of several defects that ultimately lead to Software
failure and results in the loss of information in critical modules thereby making
the system unresponsive. Generally, such situations happen very rarely because
before releasing a product all possible scenarios and test cases for the code are
simulated. Failure is detected by end-users once they face a particular issue in
the software.
 Failure can happen due to human errors or can also be caused intentionally in
the system by an individual.
 It is a term that comes after the production stage of the software.
 It can be identified in the application when the defective part is executed.
A simple diagram depicting Bug vs Defect vs Fault vs Failure:

Software Testing

Functional testing is a type of software testing in which the system is tested

against the functional requirements of the system. It is conducted to ensure that
the requirements are properly satisfied by the application. Functional testing
verifies that each function of the software application works in conformance with
the requirement and specification. Boundary Value Analysis(BVA) is one of the
functional testings.
1. Black Box Testing is a software testing method in which the internal
structure/design/implementation of the item being tested is not known to the
tester. Only the external design and structure are tested.
2. White Box Testing is a software testing method in which the internal
structure/design/implementation of the item being tested is known to the
tester. Implementation and impact of the code are tested.

Black Box Testing

1. Boundary Value Analysis

Boundary Value Analysis is based on testing the boundary values of valid and
invalid partitions. The behavior at the edge of the equivalence partition is more
likely to be incorrect than the behavior within the partition, so boundaries are an
area where testing is likely to yield defects.
It checks for the input values near the boundary that have a higher chance of
error. Every partition has its maximum and minimum values and these maximum
and minimum values are the boundary values of a partition.
Note:
 A boundary value for a valid partition is a valid boundary value.
 A boundary value for an invalid partition is an invalid boundary value.
 For each variable we check-
 Minimum value.
 Just above the minimum.
 Nominal Value.
 Just below Max value.
 Max value.
Example: Consider a system that accepts ages from 18 to 56.

Boundary Value Analysis(Age accepts 18 to 56)

Invalid Valid
Invalid
(min- (min, min + 1, nominal, max – 1,
(max + 1)
1) max)

17 18, 19, 37, 55, 56 57

Valid Test cases: Valid test cases for the above can be any value entered greater
than 17 and less than 57.
 Enter the value- 18.
 Enter the value- 19.
 Enter the value- 37.
 Enter the value- 55.
 Enter the value- 56.
Invalid Testcases: When any value less than 18 and greater than 56 is entered.
 Enter the value- 17.
 Enter the value- 57.
Single Fault Assumption: When more than one variable for the same
application is checked then one can use a single fault assumption. Holding all but
one variable to the extreme value and allowing the remaining variable to take the
extreme value. For n variable to be checked:
Maximum of 4n+1 test cases
Problem: Consider a Program for determining the Previous Data.
Input: Day, Month, Year with valid ranges as-
1 ≤ Month≤12
1 ≤ Day ≤31
1900 ≤ Year ≤ 2000
Design Boundary Value Test Cases.
Solution: Taking the year as a Single Fault Assumption i.e. year will be having
values varying from 1900 to 2000 and others will have nominal values.

Test Month Day Year Output

Cases

1 6 15 1990 14 June 1990

2 6 15 1901 14 June 1901

3 6 15 1960 14 June 1960

4 6 15 1999 14 June 1999

5 6 15 2000 14 June 2000

Taking Day as Single Fault Assumption i.e. Day will be having values varying
from 1 to 31 and others will have nominal values.

Test Month Day Year Output

Case

6 6 1 1960 31 May 1960

7 6 2 1960 1 June 1960

8 6 30 1960 29 June 1960

9 6 31 1960 Invalid day

Taking Month as Single Fault Assumption i.e. Month will be having values
varying from 1 to 12 and others will have nominal values.

Test Case Mont Day Year Output

h

10 1 15 1960 14 Jan 1960

11 2 15 1960 14 Feb 1960

12 11 15 1960 14 Nov 1960

13 12 15 1960 14 Dec 1960

For the n variable to be checked Maximum of 4n + 1 test case will be required.

Therefore, for n = 3, the maximum test cases are-
4 × 3 + 1 =13

2. Equivalence Partitioning

It is a type of black-box testing that can be applied to all levels of software

testing. In this technique, input data are divided into the equivalent partitions that
can be used to derive test cases-
 In this input data are divided into different equivalence data classes.
 It is applied when there is a range of input values.
Example: Below is the example to combine Equivalence Partitioning and
Boundary Value.
Consider a field that accepts a minimum of 6 characters and a maximum of 10
characters. Then the partition of the test cases ranges 0 – 5, 6 – 10, 11 – 14.

Test Scenario Test Description Expected Outcome

Enter value 0 to 5
1 Not accepted
character

2 Enter 6 to 10 character Accepted

3 Enter 11 to 14 character Not Accepted

Why Combine Equivalence Partitioning and Boundary Analysis

Testing: Following are some of the reasons why to combine the two approaches:
 In this test cases are reduced into manageable chunks.
 The effectiveness of the testing is not compromised on test cases.
 Works well with a large number of variables.

White Box Testing

1. Control 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.

Notations used for Control Flow Graph

1. Node
2. Edge
3. Decision Node
4. Junction node
 Node
Nodes in the control flow graph are used to create a path of procedures. Basically, it
represents the sequence of procedures which procedure is next to come so, the tester
can determine the sequence of occurrence of procedures.

We can see below in example the first node represent the start procedure and the next
procedure is to assign the value of n after assigning the value there is decision node to
decide next node of procedure as per the value of n if it is 18 or more than 18 so
Eligible procedure will execute otherwise if it is less than 18 Not Eligible procedure
executes. The next node is the junction node, and the last node is stop node to stop the
procedure.

Edge
Edge in control flow graph is used to link the direction of nodes.

We can see below in example all arrows are used to link the nodes in an appropriate
direction.

Decision node
Decision node in the control flow graph is used to decide next node of procedure as
per the value.

We can see below in example decision node decide next node of procedure as per the
value of n if it is 18 or more than 18 so Eligible procedure will execute otherwise if it
is less than 18, Not Eligible procedure executes.

Junction node
Junction node in control flow graph is the point where at least three links meet.

Example

1. public class VoteEligiblityAge{

2.
3. public static void main(String []args){
4. int n=45;
5. if(n>=18)
6. {
7. System.out.println("You are eligible for voting");
8. } else
9. {
10. System.out.println("You are not eligible for voting");
11. }
12. }
13. }

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.

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

In other words, branch coverage follows decision point and branch coverage
edges. Many different metrics can be used to find branch coverage and decision
coverage, but some of the most basic metrics are: finding the percentage of
program and paths of execution during the execution of the program.

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.

Let's understand it with an example:

1. Read X
2. Read Y
3. IF X+Y > 100 THEN
4. Print "Large"
5. ENDIF
6. If X + Y<100 THEN
7. Print "Small"
8. ENDIF

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.

Path 1 - A1-B2-C4-D6-E8Path 2 - A1-B3-5-D7

Branch Coverage (BC) = Number of paths
=2

Case Covered Branches Path Branch coverage

Yes 1, 2, 4, 5, 6, 8 A1-B2-C4-D6-E8 2

No 3,7 A1-B3-5-D7

Calculating Cyclomatic Complexity-

Cyclomatic complexity is calculated using the control flow representation of the program
code.

In control flow representation of the program code,

Nodes represent parts of the code having no branches.
Edges represent possible control flow transfers during program execution
There are 3 commonly used methods for calculating the cyclomatic complexity-
Method-01:

Cyclomatic Complexity = Total number of closed regions in the control flow graph + 1
Method-02:

Cyclomatic Complexity = E – N + 2

Here-
E = Total number of edges in the control flow graph
N = Total number of nodes in the control flow graph

Method-03:

Cyclomatic Complexity = P + 1

Here,
P = Total number of predicate nodes contained in the control flow graph

Problem-01:

Calculate cyclomatic complexity for the given code-

IF A = 354
THEN IF B > C
THEN A = B
ELSE A = C
END IF
END IF
PRINT A

Solution-

We draw the following control flow graph for the given code-
Using the above control flow graph, the cyclomatic complexity may be calculated as-

Method-01:
Cyclomatic Complexity
= Total number of closed regions in the control flow graph + 1
=2+1
=3

Method-02:
Cyclomatic Complexity
=E–N+2
=8–7+2
=3

Method-03:
Cyclomatic Complexity
=P+1
=2+1
=3
Decision Coverage Testing

Decision Coverage is a white box testing technique which reports the true or false outcomes
of each boolean expression of the source code. The goal of decision coverage testing is to
cover and validate all the accessible source code by checking and ensuring that each branch of
every possible decision point is executed at least once.
In this coverage, expressions can sometimes get complicated. Therefore, it is very hard to
achieve 100% coverage. That’s why there are many different methods of reporting this
metric. All these methods focus on covering the most important combinations. It is very much
similar to decision coverage, but it offers better sensitivity to control flow.

Statement Coverage Testing

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.

In white box testing, concentration of the tester is on the working of internal source
code and flow chart or flow graph of the code.

2. Data Flow Testing

Data flow testing is used to analyze the flow of data in the program. It is the process
of collecting information about how the variables flow the data in the program. It tries
to obtain particular information of each particular point in the process.

Data flow testing is a group of testing strategies to examine the control flow of
programs in order to explore the sequence of variables according to the sequence of
events. It mainly focuses on the points at which values assigned to the variables and
the point at which these values are used by concentrating on both points, data flow
can be tested.
Data flow testing uses the control flow graph to detect illogical things that can
interrupt the flow of data. Anomalies in the flow of data are detected at the time of
associations between values and variables due to:

o If the variables are used without initialization.

o If the initialized variables are not used at least once.

Let's understand this with an example:

In this code, we have a total 8 statements, and we will choose a path which covers all
the 8 statements. As it is evident in the code, we cannot cover all the statements in a
single path because if statement 2 is true then statements 4, 5, 6, 7 not covered, and if
statement 4 is true then statement 2 and 3 are not covered.

So, we are taking two paths to cover all the statements.

1. x= 1Path - 1, 2, 3, 8

Output = 2

When we set value of x as 1 first it come on step 1 to read and assign the value of x
(we took 1 in path) then come on statement 2 (x>0 (we took 2 in path)) which is true
and it comes on statement 3 (a= x+1 (we took 3 in path)) at last it comes on statement
8 to print the value of x (output is 2).

For the second path, we take the value of x is 1

2. Set x= -1Path = 1, 2, 4, 5, 6, 5, 6, 5, 7, 8

Output = 2

When we set the value of x as ?1 then first, it comes on step 1 to read and assign the
value of x (we took 1 in the path) then come on step number 2 which is false because
x is not greater than 0 (x>0 and their x=-1). Due to false condition, it will not come on
statement 3 and directly jump on statement 4 (we took 4 in path) and 4 is true (x<=0
and their x is less than 0) then come on statement 5 (x<1 (we took 5 in path)) which is
also true so it will come on statement 6 (x=x+1 (we took 6 in path)) and here x is
incremented by 1.

So,

x=-1+1
x=0

There is value of x become 0. Now it goes to statement 5(x<1 (we took 5 in path))
with value 0 and 0 is less than 1 so, it is true. Come on statement 6 (x=x+1 (we took 6
in path))

x=x+1
x= 0+1
x=1

There x has become 1 and again goes to statement 5 (x<1 (we took 5 in path)) and
now 1 is not less than 1 so, condition is false and it will come to else part means
statement 7 (a=x+1 where the value of x is 1) and assign the value to a (a=2). At last,
it come on statement 8 and print the value (Output is 2).

Make associations for the code:

Associations
In associations we list down all the definitions with all of its uses.

(1, (2, f), x), (1, (2, t), x), (1, 3, x), (1, (4, t), x), (1, (4, f), x), (1, (5, t), x), (1, (5, f), x),
(1, 6, x), (1, 7, x), (6,(5, f)x), (6,(5,t)x), (6, 6, x), (3, 8, a), (7, 8, a).

How to make associations in data flow testing <link>

o (1, (2, t), x), (1, (2, f), x)- This association is made with statement 1 (read x;)
and statement 2 (If(x>0)) where x is defined at line number 1, and it is used at
line number 2 so, x is the variable.
Statement 2 is logical, and it can be true or false that's why the association is
defined in two ways; one is (1, (2, t), x) for true and another is (1, (2, f), x) for
false.
o (1, 3, x)- This association is made with statement 1 (read x;) and statement 3
(a= x+1) where x is defined in statement 1 and used in statement 3. It is a
computation use.
o (1, (4, t), x), (1, (4, f), x)- This association is made with statement 1 (read x;)
and statement 4 (If(x<=0)) where x is defined at line number 1 and it is used at
line number 4 so x is the variable. Statement 4 is logical, and it can be true or
false that's why the association is defined in two ways one is (1, (4, t), x) for
true and another is (1, (4, f), x) for false.
o (1, (5, t), x), (1, (5, f), x)- This association is made with statement 1 (read x;)
and statement 5 (if (x<1)) where x is defined at line number 1, and it is used at
line number 5, so x is the variable.
Statement 5 is logical, and it can be true or false that's why the association is
defined in two ways; one is (1, (5, t), x) for true and another is (1, (5, f), x) for
false.
o (1, 6, x)- This association is made with statement 1 (read x;) and statement 6
(x=x+1). x is defined in statement 1 and used in statement 6. It is a
computation use.
o (1, 7, x)- This association is made with statement 1 (read x) and statement 7
(a=x+1). x is defined in statement 1 and used in statement 7 when statement 5
is false. It is a computation use.
 o (6, (5, f) x), (6, (5, t) x)- This association is made with statement 6 (x=x+1;)
and statement 5 if (x<1) because x is defined in statement 6 and used in
statement 5. Statement 5 is logical, and it can be true or false that's why the
association is defined in two ways one is (6, (5, f) x) for true and another is (6,
(5, t) x) for false. It is a predicted use.
o (6, 6, x)- This association is made with statement 6 which is using the value of
variable x and then defining the new value of x.
x=x+1
x= (-1+1)
Statement 6 is using the value of variable x that is ?1 and then defining new
value of x [x= (-1+1) = 0] that is 0.
o (3, 8, a)- This association is made with statement 3(a= x+1) and statement 8
where variable a is defined in statement 3 and used in statement 8.
o (7, 8, a)- This association is made with statement 7(a=x+1) and statement 8
where variable a is defined in statement 7 and used in statement 8.

Definition, c-use, p-use, c-use some p-use coverage, p-use some

c-use coverage in data flow testing <link>
The next task is to group all the associations in Definition, c-use, p-use, c-use some p-
use coverage, p-use some c-use coverage categories.

See the code below:

So, these are the all association which contain definition, Predicate use (p-use),
Computation use (c-use)

(1, (2, f), x), (1, (2, t), x), (1, 3, x), (1, (4, t), x), (1, (4, f), x), (1, (5, t), x), (1, (5, f), x),
(1, 6, x), (1, 7, x), (6,(5, f)x), (6,(5,t)x), (6, 6, x), (3, 8, a), (7, 8, a), (3, 8, a), (7, 8, a)
Definition
Definition of a variable is the occurrence of a variable when the value is bound to the
variable. In the above code, the value gets bound in the first statement and then start
to flow.

o If(x>0) is statement 2 in which value of x is bound with it.

Association of statement 2 is (1, (2, f), x), (1, (2, t.)
o a= x+1 is statement 3 bounded with the value of x
Association of statement 3 is (1, 3, x)

All definitions coverage

(1, (2, f), x), (6, (5, f) x), (3, 8, a), (7, 8, a).

Predicate use (p-use)

If the value of a variable is used to decide an execution path is considered as predicate
use (p-use). In control flow statements there are two

Statement 4 if (x<=0) is predicate use because it can be predicate as true or false. If it

is true then if (x<1),6x=x+1; execution path will be executed otherwise, else path will
be executed.

Computation use (c-use)

If the value of a variable is used to compute a value for output or for defining another
variable.

Statement 3 a= x+1 (1, 3, x)

Statement 7 a=x+1 (1, 7, x)
Statement 8 print a (3, 8, a), (7, 8, a).

These are Computation use because the value of x is used to compute and value of a
is used for output.

All c-use coverage

(1, 3, x), (1, 6, x), (1, 7, x), (6, 6, x), (6, 7, x), (3, 8, a), (7, 8, a).

All c-use some p-use coverage

(1, 3, x), (1, 6, x), (1, 7, x), (6, 6, x), (6, 7, x), (3, 8, a), (7, 8, a).

All p-use some c-use coverage

(1, (2, f), x), (1, (2, t), x), (1, (4, t), x), (1, (4, f), x), (1, (5, t), x), (1, (5, f), x), (6, (5, f),
x), (6, (5, t), x), (3, 8, a), (7, 8, a).
 After collecting these groups, (By examining each point whether the variable is used
at least once or not) tester can see all statements and variables are used. The
statements and variables which are not used but exist in the code, get eliminated from
the code.

Levels of Testing
In this section, we are going to understand the various levels of
software testing.

As we learned in the earlier section of the software testing tutorial

that testing any application or software, the test engineer needs to
follow multiple testing techniques.

In order to detect an error, we will implement software testing;

therefore, all the errors can be removed to find a product with more
excellent quality.

Verification and Validation in Software

Engineering


Verification and Validation is the process of investigating whether a software

system satisfies specifications and standards and fulfills the required
purpose. Barry Boehm described verification and validation as the following:
Verification: Are we building the product right?
Validation: Are we building the right product?

Verification
Verification is the process of checking that software achieves its goal without any
bugs. It is the process to ensure whether the product that is developed is right or
not. It verifies whether the developed product fulfills the requirements that we
have. Verification is simply known as Static Testing.

Static Testing

Verification Testing is known as Static Testing and it can be simply termed as

checking whether we are developing the right product or not and also whether our
software is fulfilling the customer’s requirement or not. Here are some of the
activities that are involved in verification.
 Inspections
 Reviews
 Walkthroughs
 Desk-checking

Verification and Validation

Validation
Validation is the process of checking whether the software product is up to the
mark or in other words product has high-level requirements. It is the process of
checking the validation of the product i.e. it checks what we are developing is the
right product. it is a validation of actual and expected products. Validation is
simply known as Dynamic Testing.

Dynamic Testing

Validation Testing is known as Dynamic Testing in which we examine whether

we have developed the product right or not and also about the business needs of
the client. Here are some of the activities that are involved in Validation.
1. Black Box Testing
2. White Box Testing
3. Unit Testing
4. Integration Testing
Note: Verification is followed by Validation.
What are the levels of Software Testing?
Testing levels are the procedure for finding the missing areas and avoiding
overlapping and repetition between the development life cycle stages. We have
already seen the various phases such as Requirement collection, designing, coding
testing, deployment, and maintenance of SDLC (Software Development Life
Cycle).

In order to test any application, we need to go through all the above phases of SDLC.
Like SDLC, we have multiple levels of testing, which help us maintain the quality of
the software.

Different Levels of Testing

The levels of software testing involve the different methodologies, which can be used
while we are performing the software testing.

In software testing, we have four different levels of testing, which are as discussed
below:

1. Unit Testing
2. Integration Testing
3. System Testing
4. Acceptance Testing
As we can see in the above image that all of these testing levels have a specific
objective which specifies the value to the software development lifecycle.

For our better understanding, let's see them one by one:

Level1: Unit Testing

Unit testing is the first level of software testing, which is used to test if software
modules are satisfying the given requirement or not.

The first level of testing involves analyzing each unit or an individual

component of the software application.

Unit testing is also the first level of functional testing. The primary purpose of
executing unit testing is to validate unit components with their performance.

A unit component is an individual function or regulation of the application, or we can

say that it is the smallest testable part of the software. The reason of performing the
unit testing is to test the correctness of inaccessible code.

Unit testing will help the test engineer and developers in order to understand the base
of code that makes them able to change defect causing code quickly. The developers
implement the unit.

Level2: Integration Testing

The second level of software testing is the integration testing. The integration testing
process comes after unit testing.

It is mainly used to test the data flow from one module or component to other
modules.

In integration testing, the test engineer tests the units or separate components or
modules of the software in a group.

The primary purpose of executing the integration testing is to identify the defects at
the interaction between integrated components or units.

When each component or module works separately, we need to check the data flow
between the dependent modules, and this process is known as integration testing.

We only go for the integration testing when the functional testing has been completed
successfully on each application module.

In simple words, we can say that integration testing aims to evaluate the accuracy of
communication among all the modules.

Level3: System Testing

The third level of software testing is system testing, which is used to test the
software's functional and non-functional requirements.

It is end-to-end testing where the testing environment is parallel to the production

environment. In the third level of software testing, we will test the application as a
whole system.

To check the end-to-end flow of an application or the software as a user is known

as System testing.

In system testing, we will go through all the necessary modules of an application and
test if the end features or the end business works fine, and test the product as a
complete system.

In simple words, we can say that System testing is a sequence of different types of
tests to implement and examine the entire working of an integrated software computer
system against requirements.

Level4: Acceptance Testing

The last and fourth level of software testing is acceptance testing, which is used to
evaluate whether a specification or the requirements are met as per its delivery.

The software has passed through three testing levels (Unit Testing, Integration
Testing, System Testing). Some minor errors can still be identified when the end-
user uses the system in the actual scenario.

In simple words, we can say that Acceptance testing is the squeezing of all the
testing processes that are previously done.

The acceptance testing is also known as User acceptance testing (UAT) and is done
by the customer before accepting the final product.

Usually, UAT is done by the domain expert (customer) for their satisfaction and
checks whether the application is working according to given business scenarios and
real-time scenarios.

Alpha Testing and Beta Testing

Alpha testing is a type of acceptance testing, which is performed to identify all
possible bugs/issues before releasing the product to the end-user. Alpha test is a
preliminary software field test carried out by a team of users to find out the bugs that
were not found previously by other tests. Alpha testing is to simulate a real user
environment by carrying out tasks and operations that actual user might perform.
Alpha testing implies a meeting with a software vendor and client to ensure that the
developers appropriately meet the client's requirements in terms of the performance,
functionality, and durability of the software.
Alpha testing needs lab environment, and usually, the testers are an internal employee
of the organization. This testing is called alpha because it is done early on, near the
end of the software development, but before beta testing.

Beta Testing is a type of acceptance testing; it is the final test before shipping a
product to the customers. Beta testing of a product is implemented by "real users "of
the software application in a "real environment." In this phase of testing, the software
is released to a limited number of end-users of the product to obtain feedback on the
product quality. It allows the real customers an opportunity to provide inputs into the
design, functionality, and usability of the product. These inputs are essential for the
success of the product. Beta testing reduces product failure risks and increases the
quality of the product through customer validation. Direct feedback from customers is
a significant advantage of beta testing. This testing helps to tests the software in a real
environment. The experiences of the previous users are forwarded back to the
developers who make final changes before releasing the software product.

Differences between the Alpha testing and Beta testing are:

Sr. Alpha Testing Beta Testing

No.

1. Alpha testing performed by a team of Beta testing performed by clients or end-

highly skilled testers who are usually users in a real-time environment, who is not
the internal employee of the an employee of the organization.
organization.

2. Alpha testing performed at the Beta testing doesn't need any lab
developer's site; it always needs a environment or the testing environment; it is
testing environment or lab performed at a client's location or end-user
environment. of the product.

3. Reliability or security testing not Reliability, security, and robustness checked

performed in-depth in alpha testing. during beta testing.

4. Alpha testing involves both white Beta testing uses only black-box testing.
box and black-box techniques.

5. Long execution cycles maybe require Only a few weeks are required for the
for alpha testing. execution of beta testing.

6. Critical issues or fixes can be Most of the issues or feedback is collecting

identified by developers immediately from the beta testing will be implemented
in alpha testing. for the future versions of the product.

7. Alpha testing performed before the At the time of software product marketing.
launch of the product into the
market.
 8. Alpha testing focuses on the Beta testing concentrates on the quality of
product's quality before going to beta the product, but gathers users input on the
testing. product and ensures that the product is ready
for real-time users.

9. Alpha testing performed nearly the Beta testing is a final test before shipping a
end of the software development. product to the customers.

10. Alpha testing is conducting in the Beta testing reversed of alpha testing.
presence of developers and the
absence of end-users.

Regression Testing
Regression Testing is the process of testing the modified parts of the code and the
parts that might get affected due to the modifications to ensure that no new errors
have been introduced in the software after the modifications have been made.
Regression means return of something and in the software field, it refers to the
return of a bug.
When to do regression testing?
 When a new functionality is added to the system and the code has been
modified to absorb and integrate that functionality with the existing code.
 When some defect has been identified in the software and the code is
debugged to fix it.
 When the code is modified to optimize its working.
Process of Regression testing:
Firstly, whenever we make some changes to the source code for any reasons like
adding new functionality, optimization, etc. then our program when executed fails
in the previously designed test suite for obvious reasons. After the failure, the
source code is debugged in order to identify the bugs in the program. After
identification of the bugs in the source code, appropriate modifications are made.
Then appropriate test cases are selected from the already existing test suite which
covers all the modified and affected parts of the source code. We can add new test
cases if required. In the end regression testing is performed using the selected test
cases.

Techniques for the selection of Test cases for Regression Testing:

 Select all test cases: In this technique, all the test cases are selected from the
already existing test suite. It is the most simple and safest technique but not
much efficient.
 Select test cases randomly: In this technique, test cases are selected randomly
from the existing test-suite but it is only useful if all the test cases are equally
good in their fault detection capability which is very rare. Hence, it is not used
in most of the cases.
 Select modification traversing test cases: In this technique, only those test
cases are selected which covers and tests the modified portions of the source
code the parts which are affected by these modifications.
 Select higher priority test cases: In this technique, priority codes are assigned
to each test case of the test suite based upon their bug detection capability,
customer requirements, etc. After assigning the priority codes, test cases with
highest priorities are selected for the process of regression testing.
Test case with highest priority has highest rank. For example, test case with
priority code 2 is less important than test case with priority code 1.
 Tools for regression testing: In regression testing, we generally select the test
cases from the existing test suite itself and hence, we need not to compute their
expected output and it can be easily automated due to this reason. Automating the
process of regression testing will be very much effective and time saving.
Most commonly used tools for regression testing are:
 Selenium
 WATIR (Web Application Testing In Ruby)
 QTP (Quick Test Professional)
 RFT (Rational Functional Tester)
 Winrunner
 Silktest
Advantages of Regression Testing:
 It ensures that no new bugs has been introduced after adding new
functionalities to the system.
 As most of the test cases used in Regression Testing are selected from the
existing test suite and we already know their expected outputs. Hence, it can be
easily automated by the automated tools.
 It helps to maintain the quality of the source code.
Disadvantages of Regression Testing:
 It can be time and resource consuming if automated tools are not used.
 It is required even after very small changes in the code.

Performance and Stress Testing



Performance Testing: Performance Testing is a type of software testing that is

carried out to determine system performance in terms of sensitivity, reactivity, and
stability under a particular workload.
Stress Testing: Stress testing is a type of software testing that verifies the stability
and reliability of the system. This test particularly determines the system’s
robustness and error handling under extremely heavy load conditions.
Difference between Performance and Stress Testing:

S. Performance Testing Stress Testing

No.

Performance testing is carried out Stress testing is carried out to check

1. to check the system’s performance the behavior of the system under the
under varying loads. sudden increased load.

It contains load and stress testing Stress testing is the subset of

2.
as components. performance testing.

It aims to determine the behavior It aims to ensure that putting a high

3. of an application under normal load on servers for an extended
conditions. period does not make them crash.

It checks scalability, speed,

It only checks the stability of the
4. reliability, etc. of the system or
system or software application.
software application.

In performance testing, the limit of

In stress testing, the limit of the load
5. the load is both below and above
is above the threshold of break.
the threshold of break.

It ensures that the system or

It ensures the security of the system
6. software application performs
under failures.
properly.

Performance testing is performed Stress testing is performed by

7.
by uniformly varying the load. increasing the load suddenly.

Load varies from lowest to highest The load is directly changed from the
8.
limit uniformly. lowest to the highest(extreme) point.

9. Performance testing is preferable Stress testing is needed as it aids the

when there is a requirement of testing unit by testing the system in
validating the application’s failure situations, checks for data
functionality, checking the saving by the system before it
adequacy of hardware for load crashed, to see if any unanticipated
 S. Performance Testing Stress Testing
No.

handling, finding, analyzing, and

failures potentially harm the security
fixing performance issues, and
of the system, and more.
more.

Debugging

What is Debugging?
Debugging is defined as the process of identifying errors or bugs in a
program and fixing the identified bugs. The process of debugging involves
the tracing of the program’s execution for the identification of the source of
the problem, analysis of the code to understand the cause of the error, and
modifying the code to fix the bug.

Debugging is an iterative process that involves the repeated testing of the

code until the bug is fixed. It can be done manually as well as by using
automated debugging tools.

Why is Debugging Important?

Debugging is an essential step in the process of software development
because it helps in ensuring that the software is working as per the plan and
meets the requirements of the end users. Debugging helps in the ways listed
below:

 Improving software quality: Debugging helps identify and fix errors,

improving the software’s quality and reducing the likelihood of bugs in
future releases.
 Saving time and resources: It helps in catching errors or bugs at an earlier
stage of the Software Development Life Cycle, thus saving time and
resources for the organization.
 Enhancing user satisfaction: It helps in providing a better user experience
as debugging helps in ensuring that the software is functioning as per
requirements. This enhances user Satisfaction.

Steps involved in Debugging

The following steps are involved in the process of debugging.


Step 1: Identify the Error

This is the first stage of Debugging is identifying the actual Error in the
code of the software.




Step 2: Find the error Location

Once the problem has been identified, you will need to thoroughly review
the code several times to identify the precise location of the error. This
stage, in general, focuses on locating the error rather than perceiving it.




Step 3: Analyze the error

The third step is error analysis, which is a bottom-up technique that starts
with identifying the issue and then analyses the code. This stage helps in the
understanding of the errors. error analysis has two major goals: reevaluating
errors to identify existing bugs and proposing the uncertainty of incoming
collateral damage in a fix.




Step 4: Prove the analysis

After examining the primary bugs, it is necessary to search for any
additional issues that may show on the program. The fourth step is used to
develop automated tests for such domains by integrating the test framework.




Step 5: Cover Lateral Damage

The fifth phase involves collecting all of the unit tests for the code that has
to be modified. When you run these unit tests, they must pass.




Step 6: Fix & Validate

The final stage is fix and validation, which focuses on resolving defects
before running all of the test scripts to determine if they pass.


 Strategies for Debugging
Some of the common strategies which are employed for purpose of
debugging are listed below.

 Backtracking: The bug hunter begins at the statement where an error

symptom is detected and works backward through the source code to the
actual fault.
 Cause Elimination Method: The software engineer generates a list of
possible reasons for an error and performs tests to find the origin of a point
of failure.
 Program Slicing: Quality Assurance (QA) testers execute a group of
program statements in the program (slice) under some specific conditions.
 Shotgun Debugging: Shotgun Debugging is a trial-and-error, fingers-
crossed technique of debugging based on the educated guesses of the
developer.
 Rubber Duck Debugging: Rubber Duck Debugging is when a programmer
explains code to a small rubber duck or another inanimate item line by line.
The idea is to encourage flexible, rational thinking.
 Pair Debugging: Instead of describing code line by line to an inanimate
object, coders pair up explaining code line by line to each other.

Debugging Tools
Many tools have been used to identify and fix bugs; debugging tools are
software applications that are used to test and debug other software systems.
There are several open-source debugging tools on the market, such as DBX,
GDB, and others. Some examples are:

1. GDB (the GNU debugger)

2. LLDB
3. Radare2
4. Microsoft visual studio debugger
5. Valgrind
6. WinDBg
7. Firefox JavaScript debugger
8. Eclipse debugger
9. Arm DTT (Allinea DDT)
10. WDW (OpenWatcom debugger)

Advantages of Debugging
The advantages of Debugging are given below:
 The identification of the bugs at an earlier stage helps in saving the time of
the developers.
 This identification and fixing of bugs also save money in the long run.
 This process of debugging helps in improving the code quality of the
software.
 Debugging can result in better code optimization of the software/product.
 This process ensures that the software is working fine as per the
expectations and plans.

Disadvantages of Debugging
Here are some Disadvantages associated with Debugging.

 The process of debugging is time-consuming.

 It can be stressful for developers if they are working hard to find bugs or
errors.
 In some cases, Debugging may result in the introduction of new bugs in the
software.
 The process of debugging requires specialized tools, which might not be
directly available in the market.
 Developers might get distracted by debugging from other important tasks
such as implementing a new feature.