Software Testing

• Software testing is a process of identifying the correctness of software by considering its all
attributes (Reliability, Scalability, Portability, Re-usability, Usability) and evaluating the execution of
software components to find the software bugs or errors or defects.
• Testing includes an examination of code and also the execution of code in various environments,
conditions as well as all the examining aspects of the code.
Type of Software testing:-

Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit

23-11-2023 95
5
 Manual Testing and Automation Testing
• The process of checking the functionality of an application as per the customer needs without
taking any help of automation tools is known as Manual testing.
• Manual testing can be further divided into three types of testing, which are as follows:
➢White box testing
➢Black box testing
➢Gray box testing

• Automation testing is a process of converting any manual test cases into the test scripts with the
help of automation tools, or any programming language is known as automation testing. With the
help of automation testing, we can enhance the speed of our test execution because here, we do
not require any human efforts. We need to write a test script and execute those scripts.

Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit

23-11-2023 96
5
 Test, Test Case and Test Suite (CO5)

• Test and Test case terms are used interchangeably. In practice, both are same and
are treated as synonyms. Test case describes an input description and an expected
output description
• The set of test cases is called a test suite. Hence any combination of test cases
may generate a test suite.

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 97

 Difference between White Box, Black Box and Grey Box Testing
Index Black Box Testing White Box Testing Grey Box Testing
1 Knowledge o f internal working structure (Code) is not Knowledge of internal working structure (Coding of software) is Partially Knowledge of the internal wo rking structure is
required for this type of testing. Only GUI (Graphical User necessarily required for this type of testing. required.
Interface) is required for test cases.

2 Black Bo x Testing is also known as functional testing, data- White Bo x Testing is also known as structural testing, clear box Grey Bo x Testing is also known as translucent testing as the
driven testing, and closed box testing. testing, code-based testing, and transparent testing. tester has limited knowledge of coding.

3 The approach towards testing includes trial techniques and White Bo x Testing is proceeded by verifying the system If the tester has knowledge of coding, then it is proceeded
error guessing method because tester does not need knowledge boundaries and data domains inherent in the software as there is no by validating data domains and internal system boundaries
of internal coding of the software. lack of internal coding knowledge. of the software.

4 The testing space of tables for inputs (inputs to be used for The testing space of tables for inputs (inputs to be used for creating The testing space of tables for inputs (inputs to be used for
creating test cases) is pretty huge and largest among all testing test cases) is less as compared to Black Box testing. creating test cases) is smaller than Black Bo x and White
spaces. Box testing.

5 It is very difficult to discover hidden errors of the software It is simp le to discover hidden errors because it can be due to Difficult to discover the hidden error. Might be found in
because errors can be due to internal working wh ich is internal working which is deeply explored in White Box testing. user level testing.
unknown for Black Box testing.

6 It is not considered for algorithm testing. It is well suitable and recommended for algorithm testing. It is not considered for algorithm testing.

7 Time consumption in Black Bo x testing depends upon the White Bo x testing takes a long time to design test cases due to Test cases designing can be done in a short time period.
availability of the functional specifications. lengthy code.

8 Tester, developer and the end user can be the part of testing.
Only tester and developer can be a part of testing; the end user can Tester, developer and the end user can be the part of testing.
not involve.
9 It is the least time-consuming process among all the testing The entire testing process is the most time consuming among all less time consuming than White Box testing.
processes. the testing processes.
10 Resilience and security against viral attacks are covered under Resilience and security against viral attacks are not covered under Resilience and security against viral attacks are not covered
Black Box testing. White Box testing. under Grey Box testing.
11 The base of this testing is external expectations internal The base of this testing is coding which is responsible for internal Testing based on high-level database diagrams and dataflow
behavior is unknown. working. diagrams.
12 It is less exhaustive than White Box and Grey Bo x testing It is most exhaustive between Black Bo x and Grey Bo x testing Partly exhaustive; depends upon the type of test cases are
methods. methods. coding based or GUI based.

Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit

23-11-2023 98
5
 Difference between Automation Testing and Manual Testing
Aspects Automation testing Manual testing
Definition When an application or software is tested with the help of some tools is It is a type of software testing, which is done by the test Engineer to
known as automation testing. check the functionality of an application based on the customer
Whenever multiple releases or multiple regression cycle is going on the requirement.
application or software, we will go for automation testing.
Reliability It is reliable because it tests the application with the help of tools and It is not reliable because there is a possibility of human error, which may
test scripts. not be delivered the bug-free application.
Reused The script can be reused across multiple releases. It could be possible when the test case only needs to run once or twice.
Batch Batch execution is possible using automation testing because all the Batch execution is not possible in manual testing.
Execution written scripts can be executed parallelly or simultaneously.
Time-saving The execution is always faster than the manual; that's why the It is time consuming due to the usage of the human resources.
automation testing process is time-saving.
Investment While using the Automation tool, investment is required. Human resources needed investment.
Performance To test the performance of the application with the help of load and In manual testing, performance testing is not possible.
testing stress testing, automation test engineer needs to perform Performance
Testing.
Programmin Without having an understanding of programming language, we cannot There is no need to know programming language but should have the
g knowledge write the test script. product knowledge to write the test case.
Framework The automation test engineer can use the different types of frameworks There is no need for a framework while using manual testing.
like Data driven, Hybrid, modular driven, and keyword-driven to
faster the automation process.
Ope rating Automation testing can also be performed on different systems with Operating system compatibility is not possible in manual testing because
system different operating system platforms and various programming the different tester is required to perform such tasks.
compatibility languages.
Regression Whenever the code changes happen due to the enhancement of the When the test engineer executes the test case for the first time, it may be
testing release, then automation test engineer performs the regression testing. useful, but there is a possibility that it will not catch the regression bugs
because of changing requirements frequently.

Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit

23-11-2023 99
5
 Difference between Defect, Error, Fault, Failures
Comparison basis Bug Defect Error Fault Failure

Definition It is an informal name specified The Defect is the difference between the actual An Error is a mistake made in the The Fault is a state that causes If the software has lots of defects,
to the defect. outcomes and expected outputs. code; that's why we cannot execute or the software to fail to accomplish it leads to failure or causes failure.
compile code. its essential function.

Raised by The Test Engineers submit The Testers identify the defect. And it was also The Developers and automation test Human mistakes cause fault. The failure finds by the manual
the bug. solved by the developer in the development phase engineers raise the error. test engineer through
or stage. the development cycle.
Different •Different type of bugs are as •Different type of Defects are as follows: •Different type of Error is as •Different type of Fault are as
types follows: Based on priority:High below:Syntactic Error follows:Business Logic Faults -----
•Medium •User interface error •Functional and Logical Faults
•Logic bugs •Low •Flow control error •Faulty GUI
•Algorithmic bugs •And based on the severity:Critical •Error handling error •Performance Faults
•Resource bugs •Major •Calculation error •Security Faults
•Minor •Hardware error •Software/ hardware fault
•Trivial •Testing Error
Reasons Following are reasons which The below reason leads to the defects: The reasons for having an error are as The reasons behind the fault are as Following are some of the
follows: follows:
behind may cause the bugs: Giving incorrect and wrong inputs. Errors in the code.
most important reasons behind
A Fault may occur by an improper
Missing coding Dilemmas and errors in the outside behavior The M istake of some values. the failure:
step in the initial stage, process, or
Wrong coding and inside structure and design. If a developer is unable to compile or run a Environmental condition
data definition.
program successfully.
Extra coding An error in coding or logic affects the software Confusions and issues in programming. Inconsistency or issue in the System usage
and causes it to breakdown or the failure. Invalid login, loop, and syntax. program. Users
Inconsistency between actual and expected An irregularity or loophole in the Human error
outcomes. software that leads the software to
Blunders in design or requirement actions. perform improperly .
M isperception in understanding the
requirements of the application.
Way to Following are the way to stop With the help of the following, we can prevent Below are ways to prevent the Errors: of software design and The way to prevent failure are as
prevent the the bugs: the Defects: Implementing several innovative Enhance the software quality with system programminThe fault can be follows:
Test-driven development. programming methods. review and programming. prevented with the help of the Confirm re-testing.
reasons Offer programming language Use of primary and correct software development Detect the issues and prepare a suitable following: Review the requirements and revisit
support. techniques. mitigation plan. Peer review. the specifications.
Adjusting, advanced, and operative Peer review Validate the fixes and verify their quality Assess the functional necessities of Implement current protective
development procedures. It is executing consistent code reviews to evaluate its and precision. the software. techniques.
Evaluating the code systematically. quality and correctness. Execute the detailed code analysis. Categorize and evaluate errors and
Verify the correctness g. issues.

Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit

23-11-2023 100
5
 Verification and Validation(CO5)

• Verification: Software should confirm to its.(are we building the product

right?)
• It is the process of determining whether the output of one phase of
software development conforms to that of its previous phase. Thus
verification is concerned with phase containment of errors

• Validation: Software should do what the user really require.(are we

building the right product?)
• It is the process of determining whether a fully developed system
conforms to its requirements specification. the aim of validation is
that the final product be error free.

Testing= Verification + Validation

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 101
 Verification and Validation(CO5)

• The purpose of V & V is to confirm system specification and to meet the

requirement of system customers.
• Verification: represent the set of activities that are carried out to confirm
that the s/w correctly implemented the specific functionality.(are we
building the product right?)
• It is the process of determining whether the output of one phase of
software development conforms to that of its previous phase. Thus
verification is concerned with phase containment of errors
• Validation: represent set of activities that ensure that the s/w that has
been build is satisfying the customer requirements.(are we building the
right product?)
• It is the process of determining whether a fully developed system
conforms to its requirements specification. the aim of validation is that
the final product be error free.

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 102
 Verification and Validation(CO5)

• Program Verification:
• It is the process of checking that a software achieves its goal
without any bugs.
• It is the process to ensure whether the product that is developed is
right or not.
• Are we building the product, right?
• Program Validation:
• It 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 product i.e. it
checks what we are developing is the right product.
• Are we building the right product?

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 103
 Verification and Validation(CO5)

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 104
 Difference between Verification and Validation(CO5)

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 105
 Black Box and White Box Testing

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 106
 1- Black Box/Functional Testing (CO5)

• black box testing is a process of checking the functionality of an application as per the
customer requirement. The source code is not visible in this testing; that's why it is
known as black-box testing.
• Test cases are designed from an examination of the input/output values only and no
knowledge of design, or code is required.
• It is also known as Functional Testing

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 107
 1- Black Box/Functional Testing (CO5)

The following are the main approaches to designing black box test cases.

1. Boundary Values analysis

2. Robustness Testing
3. Worst case Testing
4. Equivalence Class Testing
5. Decision Table Based Testing

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 108
 1.1- Boundary Value Analysis

Consider a program with two input variables x and y. These input variables
have specified boundaries as:

a ≤x ≤b
c ≤y ≤d

Fig. : Input domain for program having two input variables

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 109
 1.1- Boundary Value Analysis

The boundary value analysis test cases for our program with two
inputs variables (x and y) that may have any value from 100 to 300
are: (200,100), (200,101), (200,200), (200,299), (200,300), (100,200),
(101,200), (299,200) and (300,200). This input domain is shown in Fig.
8.5. Each dot represent a test case and inner rectangle is the domain
of legitimate inputs. Thus, for a program of n variables, boundary
value analysis yield 4n + 1 test cases

Fig. : Input domain of two variables x and y with boundaries [100,300] each

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 110
 Example

Consider a program for the determination of the nature of roots of a

quadratic equation. Its input is a triple of positive integers (say a,b,c)
and values may be from interval [0,100]. The program output may
have one of the following words.
[Not a quadratic equation; Real roots; Imaginary roots; Equal roots]
Design the boundary value test cases.

Quadratic equation will be of type:

ax2+bx+c=0
Roots are real if (b2-4ac)>0
Roots are imaginary if (b2-4ac)<0
Roots are equal if (b2-4ac)=0
Equation is not quadratic if a=0

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 111
 Example

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 112
 1.2- Robustness Testing

It is nothing but the extension of boundary value analysis. Here, we

would like to see, what happens when the extreme values are
exceeded with a value slightly greater than the maximum, and a
value slightly less than minimum. It means, we want to go outside
the legitimate boundary of input domain

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 113
 1.3- Worst-case testing

If we reject “single fault” assumption theory of reliability and may

like to see what happens when more than one variable has an
extreme value. In electronic circuits analysis, this is called “worst
case analysis”. It is more thorough in the sense that boundary value
test cases are a proper subset of worst case test cases. It requires
more effort.

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 114
 1.4- Equivalence Class Testing

In this method, input domain of a program is partitioned into a finite

number of equivalence classes such that one can reasonably assume,
but not be absolutely sure, that the test of a representative value of
each class is equivalent to a test of any other value
Two steps are required
❖ The equivalence classes are identified by taking each input
condition and partitioning it into valid and invalid classes
❖ Generate the test cases using the equivalence classes identified in
the previous step. This is performed by writing test cases covering
all the valid equivalence classes. Then a test case is written for each
invalid equivalence class so that no test contains more than one
invalid class. This is to ensure that no two invalid classes mask each
other

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 115
 1.4- Equivalence Class Testing

Most of the time, equivalence class testing defines classes of the input
domain. However, equivalence classes should also be defined for
output domain. Hence, we should design equivalence classes based on
input and output

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 116
 2- White Box Testing(Structural Testing)

• It is a complementary approach to functional testing. It permits us to examine the

internal structure of the program.
• Also called Structural Testing, Clear Box testing, Transparent Box testing, Glass Box
testing, Open Box testing.
• The purpose of implementing the white box testing is to emphasize the flow of inputs
and outputs over the software and enhance the security of an application.

1. Path Testing
2. Cyclomatic Complexity
3. Graph Matrices
4. Data Flow Testing
5. Mutation Testing

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 117
 2.1- Path Testing

This type of testing involves:

1. Generating a set of paths that will cover every branch in the
program.
2. Finding a set of test cases that will execute every path in the set of
program paths.
Step 1:
Generate Control flow graph of a program.
Step 2:
Draw a Decision to Decision path (DD-path) graph from the
control flow graph.
it is a directed graph. node are sequences of statements and edges represent
control flow between them.
DD path is used to find Independent path.
Independent path: it is used to ensure
1. Every statement in the program has been executed at least once.
2. Every branch has been exercised for true and false condition.

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 118
 2.2- Cyclomatic Complexity

• The purpose of implementing the white box testing is to emphasize the flow of inputs and
outputs over the software and enhance the security of an application.
• McCabe’s cyclomatic metric M = e – n + 2P.
For example, a flow graph shown in in Fig with entry node ‘a ’ and exit node ‘f ’
M = E – N + 2P
where,
E = the number of edges in the control flow graph
N = the number of nodes in the control flow graph
P = the number of connected components

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 119
 2.2- Cyclomatic Complexity

The value of cyclomatic complexity can be calculated as :

M=9–6+2=5
Here e = 9, n = 6 and P =1
There will be five independent paths for the flow graph illustrated in Fig.
Path 1 : a c f
Path 2 : a b e f
Path 3 : a d c f
Path 4 : a b e a c f or a b e a b e f
Path 5 : a b e b e f

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 120
 2.2- Cyclomatic Complexity

Several properties of cyclomatic complexity are stated below:

1. V(G) ≥1

2. V (G) is the maximum number of independent paths in graph G.

3. Inserting & deleting functional statements to G does not affect V(G).

4. G has only one path if and only if V(G)=1.

5. Inserting a new row in G increases V(G) by unity.

6. V(G) depends only on the decision structure of G.

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 121
 2.3- Graph Matrices

A graph matrix is a square matrix with one row and one column
for every node in the graph. The size of the matrix (i.e., the
number of rows and columns) is equal to the number of nodes
in the flow graph. Some examples of graphs and associated
matrices are shown in figure

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 122
 2.4- Data Flow Testing

Data flow testing is another form of structural testing. It has nothing to

do with data flow diagrams.
i. Statements where variables receive values.
ii. Statements where these values are used or referenced.

As we know, variables are defined and referenced throughout the

program. We may have few define/ reference anomalies:

i. A variable is defined but not used/ referenced.

ii. A variable is used but never defined.
iii. A variable is defined twice before it is used.

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 123
 2.4- Data Flow Testing

The definitions refer to a program P that has a program graph G(P) and
a set of program variables V. The G(P) has a single entry node and a
single exit node. The set of all paths in P is PATHS(P)

Defining Node: Node n ϵ G(P) is a defining node of the variable v ϵ V,

written as DEF (v, n), if the value of the variable v is defined at the
statement fragment corresponding to node n

Usage Node: Node n ϵ G(P) is a usage node of the variable v ϵ V,

written as USE (v, n), if the value of the variable v is used at statement
fragment corresponding to node n. A usage node USE (v, n) is a
predicate use (denote as p) if statement n is a predicate statement
otherwise USE (v, n) is a computation use (denoted as c)

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 124
 2.4- Data Flow Testing

Definition use: A definition use path with respect to a variable v

(denoted du-path) is a path in PATHS(P) such that, for some v ϵ V, there
are define and usage nodes DEF(v, m) and USE(v, n) such that m and n
are initial and final nodes of the path.
Definition clear : A definition clear path with respect to a variable v
(denoted dc-path) is a definition use path in PATHS(P) with initial and
final nodes DEF(v, m) and USE (v, n), such that no other node in the
path is a defining node of v.

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 125
 2.5- Mutation testing

➢ It perform After the initial testing is complete. The idea behind

mutation testing is to make few arbitrary changes to a program at
a time. Each time the program is changed, it is called as a mutated
program and the change effected is called as a mutant.

➢ A mutated program is tested against the full test suite of the

program. If there exists at least one test case in the test suite for
which a mutant gives an incorrect result, then the mutant is said
to be dead.

➢ If a mutant remains alive even after all the test cases have been
exhausted, the test data is enhanced to kill the mutant.

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 126
 2.5- Mutation testing

Disadvantage:
• it is computationally very expensive, due to a large number of possible
mutants can be generated.
• it is not suitable for manual testing. Mutation testing should be used in
conjunction of some testing tool which would run all the test cases
automatically. Version

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 127
 Level Of Testing

There are 3 levels of testing:

1. Unit Testing
2. Integration Testing
3. System Testing

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 128
 1- Unit Testing (CO5)

• It is also called module testing.

• Follows a white box testing(logic of program).
• Done by developer.
• It is the testing of different units (or modules) of a system in
isolation.
• steps are needed in order to be able to test the module:
• The procedures belonging to other modules that the module
under test calls.
• Nonlocal data structures that the module accesses.
• A procedure to call the functions of the module under test
with appropriate parameters.

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 129
 Stub and Driver

Stubs and drivers are designed to provide the complete environment

for a module.
Stub: it is a dummy procedure that has the same I/O parameters
as the given procedure but has a highly simplified behavior.
Driver : it contain the nonlocal data structures accessed by the
module under test, and would also have the code to call the
different functions of the module with appropriate parameter
values.

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 130
 2-Integration Testing (CO5)

The purpose of unit testing is to determine that each

independent module is correctly implemented. This gives little
chance to determine that the interface between modules is also
correct, and for this reason integration testing must be
performed. One specific target of integration testing is the
interface: whether parameters match on both sides as to type,
permissible ranges, meaning and utilization.

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 131
 2-Integration Testing (CO5)

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 132
 2.1- Bottom-Up Integration

• Only terminal modules (i.e., the modules that do not call other modules) are
tested in isolation
• Modules at higher level are tested using the previously tested lower level
modules
• Non-terminal modules are not tested in isolation
• Requires a module driver for each module to feed the test case input to the
interface of the module being tested
• However, stubs are not needed since we are starting with the terminal
modules and use already tested modules when testing modules in the
lower levels

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 133
 2.1- Bottom-Up Integration

A B

C H

E F G I

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 134
 2.2- Top-down Integration

• Only modules tested in isolation are the modules which are at the
highest level
• After a module is tested, the modules directly called by that module
are merged with the already tested module and the combination is
tested
• Requires stub modules to simulate the functions of the missing
modules that may be called
• However, drivers are not needed since we are starting with the
modules which is not used by any other module and use already
tested modules when testing modules in the higher levels

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 135
 2.2- Top-down Integration

A B

C
H

E F G I

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 136
 2.3- Other Integration Approaches

• Sandwich Integration
• Compromise between bottom-up and top-down
testing
• Simultaneously begin bottom-up and top-down testing
and meet at a predetermined point in the middle
• Big Bang Integration
• Every module is unit tested in isolation
• After all of the modules are tested they are all
integrated together at once and tested
• No driver or stub is needed
• However, in this approach, it may be hard to isolate the
bugs!

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 137
 Difference between Top-down and Bottom-Up Integration
S.N Comparison Basis Top-Down Integration Testing Bottom-up Integration Testing
O.
1. Definition We will add the modules incrementally or one by one and test the data The lower- level modules are tested with higher- level modules until
flow in similar order. all the modules have been tested successfully.

2. Executed on The top-down integration testing approach will be executed on the The bottom-up integration testing approach will be executed on
Structure or procedure-oriented programming languages. Object-oriented programming languages.

3. Observation In the top-down approach, the observation of test output is more In the bottom- up approach, the observation of test output is more
complicated. accessible.
4. Risk analysis We are collaborating on the impact of internal operational failures. To analyze the individual process, we can use the Models.

5. Work on The top-down integration testing approach will work on major to minor The bottom-down integration testing approach will work on the
components. miner to significant components.

6. Complexity The complexity of the top-down approach is simple. The complexity of the bottom- up approach is complex and highly
data intensive.
7. Stub/Drive r Stub modules must be created in the top-down testing approach. The driver modules must be created in the bottom-up testing
creation approach.
8. Managed from It is performed from main-module to sub-module. It is performed from the sub-module to the main module.
9. Advantage •Following are some of the significant benefits of using top-down •Below are some of the essential advantages of using bottom- up
integration testing:In this, the early prototype is possible. integration testing:We do not need to wait for the development of
•Fault Localization is easier. all the modules as it saves time.
•Identification of defects is easy.
10. Disadvantage •Some of the most common drawbacks of the top-down approach are as •The disadvantage of the bottom- up approach is as
follows:Lower- level modules are tested ineffectively. follows:Compulsory modules are tested last, due to which the
•Due to the high number of stubs, it gets pretty complicated. defects can occur.
•Critical Modules are tested first so that fewer chances of defects. •There is no possibility of an early prototype.

Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit

23-11-2023 138
5
 3- System Testing (CO5)

•Alpha Testing: Alpha testing refers to the system testing carried

out by the test team within the developing organization.

• Beta testing: Beta testing is the system testing performed by a

select group of friendly customers.

• Acceptance Testing: Acceptance testing is the system testing

performed by the customer to determine whether he should accept
the delivery of the system.

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 139
 Alpha, Beta and Acceptance Testing (CO5)

• The term Acceptance Testing is used when the software is developed for
a specific customer. A series of tests are conducted to enable the customer
to validate all requirements. These tests are conducted by the end user /
customer and may range from adhoc tests to well planned systematic
series of tests.
• The terms alpha and beta testing are used when the software is developed
as a product for anonymous customers.
• Alpha Tests are conducted at the developer’s site by some potential
customers. These tests are conducted in a controlled environment. Alpha
testing may be started when formal testing process is near completion.
• Beta Tests are conducted by the customers / end users at their sites.
Unlike alpha testing, developer is not present here. Beta testing is
conducted in a real environment that cannot be controlled by the developer.

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 140
 3- System Testing (CO5)

Performance testing : Performance testing is carried out to check whether the system needs
the nonfunctional requirements identified in the SRS document. All performance tests can be
considered as black-box tests.
• Stress testing
• Volume testing
• Configuration testing
• Compatibility testing
• Regression testing
• Recovery testing
• Maintenance testing
• Documentation testing
• Usability testing

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 141
 3- System Testing (CO5)

Stress testing : Stress tests are black box tests which are designed to impose a range of
abnormal and even illegal input conditions so as to stress the capabilities of the software. For
example, suppose an operating system is supposed to support 15 multi programmed jobs, the
system is stressed by attempting to run 15 or more jobs simultaneously. A real-time system
might be tested to determine the effect of simultaneous arrival of several high-priority
interrupts.

• Volume testing: It is especially important to check whether the data structures (arrays,
queues, stacks, etc.) have been designed to successfully extraordinary situations. For
example, a compiler might be tested to check whether the symbol table overflows when a
very large program is compiled

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 142
 3- System Testing (CO5)

• Configuration testing: This is used to analyze system behavior in various

hardware and software configurations specified in the requirements.

• Compatibility testing : This type of testing is required when the system

interfaces with other types of systems. Compatibility aims to check whether
the interface functions perform as required.

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 143
 3- System Testing (CO5)

• Regression testing: This type of testing is required when the system being tested is an
upgradation of an already existing system to fix some bugs or enhance functionality,
performance, etc.

• Recovery testing : Recovery testing tests the response of the system to the presence of
faults, or loss of power, devices, services, data, etc.

• Maintenance testing : This testing addresses the diagnostic programs, and other procedures
that are required to be developed to help maintenance of the system. It is verified that the
artifacts exist and they perform properly.

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 144
 3- System Testing (CO5)

• Documentation testing: It is checked that the required user manual, maintenance

manuals, and technical manuals exist and are consistent.

• Usability testing: Usability testing concerns checking the user interface to see if it meets
all user requirements concerning the user interface.

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 145
 Bug Life Cycle

Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit

23-11-2023 146
5
 Bug Life Cycle
• This new bug needs to be reported to the concerned Developer by changing the status
as Assigned so that the responsible person should take care of the bug.
• Then the Developer first go through the bug, which means that the Developers read all the
navigation steps to decide whether it is a valid bug or not.
• Based on this, if the bug is valid, the Developer starts reproducing the bug on the application,
once the bug is successfully reproduced, the Developer will analyze the code and does the
necessary changes, and change the status as Fixed.
• Once the code changes are done, and the bug is fixed, the test engineer re-test the bug, which
means that the test engineer performs the same action once again, which is mentioned in the bug
report, and changes the status accordingly:
• Close, if the bug fixes properly, and functionally working according to the requirement.
OR
• Re-open, if the bug still exists or not working properly as per the requirement, then the bug sends
it back to the Developer once again.
• This process is going on continuously until all the bugs are fixed and closed.

Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit

23-11-2023 147
5
 Formal Technical Review(CO5)

Formal Technical Review(Code review)

• Perform on module.
• It is carried out after the module is successfully compiled and all
the syntax errors have been eliminated.
• It is extremely cost-effective strategies for reduction in coding
errors and to produce high quality code.
• Normally, two types of reviews are carried out on the code of a
module.
• 1 Code inspection
• 2 Code walk Through

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 148
 Code Walk Through (CO5)

1. The main objectives of the it is to discover the algorithmic and

logical errors in the code.
2. It is an informel code analyses technique.
3. It is done after a module has been coded, successfully
compiled and all syntax errors eliminated.
4. A few members of the development team are given the code
few days before the walk through meeting to read and
understand code.
5. Each member selects some test cases and simulates execution
and tracing of the code by hand.
6. The members note down their findings to discuss these in a
walk through meeting where the coder of the module is
present.
7. After meeting several guidelines have evolved over the years
for making this useful analysis technique more effective.
23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 149
 Code Walk Through

Some of these guidelines are the following.

• The team performing code walk through should not be either too big
or too small.
• Discussion should focus on discovery of errors and not on how to fix
the discovered errors.
• In order to cooperation and to avoid the feeling among engineers that
they are being evaluated in the code walk through meeting, managers
should not attend the walk through meetings.

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 150
 Code inspection (CO5)

Code is examined for the presence of certain kinds of errors, in

contrast to the hand simulation of code execution done in code walk
through.
List of some classical programming errors which can be checked
during code inspection:
• Use of uninitialized variables.
• Jumps into loops.
• Non terminating loops.
• Incompatible assignments.
• Array indices out of bounds.
• Improper storage allocation and deallocation

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 151
 Daily Quiz
1) Software testing is:
(a) The process of demonstrating that errors are not present
(b) The process of establishing confidence that a program does what it is supposed to do
(c) The process of executing a program to show it is working as per specifications
(d) The process of executing a program with the intent of finding errors
2) Software mistakes during coding are known as:
(a) failures (b) defects (c) bugs (d) errors
3) Functional testing is known as:
(a) Structural testing (b) Behavior testing (c) Regression testing (d) None
4) Regression testing is primarily related to:
(a) Functional testing (b) Data flow testing
(c) Development testing (d) Maintenance testing
5)Validation is
(a) Checking the product with respect to customer’s expectation
(b) Checking the product with respect to specifications
(c) Checking the product with respect to the constraints of the project
(d) All of the above

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 152
 Daily Quiz
6) For a function of n variables, boundary value analysis yields:
(a) 4n+3 test cases (b) 4n+1 test cases
(c) n+4 test cases (d) None of the above
7 ) Beta testing is carried out by
(a) Users (b) Developers
(c) Testers (d) All of the above
8) Equivalence class partitioning is related to
(a) Structural testing (b) Black box testing
(c) Mutation testing (d) All of the above
9) Cause effect graphing techniques is one form of
(a) Maintenance testing (b) Structural testing
(c) Function testing (d) Regression testing
10) During validation
(a) Process is checked (b) Product is checked
(c) Developer’s performance is evaluated (d) The customer checks the product

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 153
 Assignment 5

1. What is software testing? Discuss the role of software testing during

software life cycle and why is it so difficult?
2. Why should we test? Who should do the testing?

3. What should we test? Comment on this statement. Illustrate the

importance of testing
4. Defined the following terms:
(i) fault (ii) failure
(iii) bug (iv) mistake
5. What is the difference between
(i) Alpha testing & beta testing
(ii) Development & regression testing
(iii) Functional & structural testing
6. Discuss the limitation of testing. Why do we say that complete testing is
impossible?
23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 154
 Assignment 5

7. Why does software fail after it has passed from acceptance testing? Explain.

8. What are various kinds of functional testing? Describe any one in detail.

9. Explain the boundary value analysis testing techniques with the help of an example.

10. Discuss cause effect graphing technique with an example .

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 155
 Faculty Video Links, Youtube & NPTEL Video Links and Online
Courses Details
• https://nptel.ac.in/courses/106/105/106105182/
• https://www.youtube.com/watch?v=mGrajqMLenI&list=PLyqSpQzTE6M-
sBjDcT21Gpnj8grR2fDgc&index=16
• https://www.youtube.com/watch?v=biKUffL8cm4&list=PLyqSpQzTE6M-
sBjDcT21Gpnj8grR2fDgc&index=2
• https://www.youtube.com/watch?v=0kkUnL1mdUY&list=PLyqSpQzTE6M-
sBjDcT21Gpnj8grR2fDgc&index=4

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 156
 MCQ
1 For a function of two variables, how many cases will be generated by
robustness testing?
(a) 9 (b) 13
(c) 25 (d) 42
2 For a function of n variables robustness testing of boundary value analysis
yields: (a) 4n+1 (b) 4n+3
(c) 6n+1 (d) None of the above
3 Regression testing is primarily related to:
(a) Functional testing (b) Data flow testing
(c) Development testing (d) Maintenance testing
4 A node with indegree=0 and out degree ≠ 0 is called
(a) Source node (b) Destination node
(c) Transfer node (d) None of the above
5 A node with indegree ≠ 0 and out degree=0 is called
(a) Source node (b) Predicate node
(c) Destination node (d) None of the above
23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 157
 MCQ
6 A decision table has
(a) Four portions (b) Three portions
(c) Five portions (d) Two portions
7 Beta testing is carried out by
(a) Users (b) Developers
(c) Testers (d) All of the above
8 Equivalence class partitioning is related to
(a) Structural testing (b) Blackbox testing
(c) Mutation testing (d) All of the above
9 Cause effect graphing techniques is one form of
(a) Maintenance testing (b) Structural testing
(c) Function testing (d) Regression testing
10 During validation
(a) Process is checked (b) Product is checked
(c) Developer’s performance is evaluated (d) The customer checks the product

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 158
 Glossary

1. Choose the correct-

a) Maintenance testing…Breadth test and depth test
b) Black box testing…boundary value analysis?
c) White box testing…. Statement coverage testing
d) Performance Testing….Non-functional testing?

2. Choose the correct-

a) Abstraction…focusing on what an object is and does
b) Encapsulation…separates the external aspects of an object
c) Inheritance…sharing of attributes and operations
d) Polymorphism means that the same operation may behave differently for different classes.

3. Choose the correct-

a) Class Model...describes the static structure of the objects in the system a
b) State model...describes the aspects of an object that change over time. I
c) Interaction Model…describes how the objects in the system co-operate to achieve broader
results.
d) Domain Model…a description of real world objects reflected within the system
23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 159
 Old Question Papers

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 160
 Old Question Papers

23-11-2023 161
Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5
 Old Question Papers

23-11-2023 162
Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5
 Expected Questions for University Exam

1. Why does software fail after it has passed from acceptance testing?
2. What are various kinds of functional testing? Describe any one in detail.
3. Explain the boundary value analysis testing techniques with the help of an example.
4. Describe the equivalence class testing method. Compare this with boundary value
analysis techniques.
5. Discuss cause effect graphing technique with an example

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 163
 Recap of Unit 5

• Testing Objectives, UNIT Testing, Integration Testing, Acceptance Testing,

• Regression Testing, Testing for functionality and Testing for Performance,
• Top-Down and Bottom-Up Testing Strategies:
• Test Drivers and Test Stubs,
• Structural Testing (White Box Testing), Functional Testing (Black Box Testing),
• Alpha and Beta Testing of Products.
• Static Testing Strategies: Formal Technical Reviews (Peer Reviews), Walk Through,
• Code Inspection, Compliance with Design and Coding Standards

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 164
 REFRENCES

1. R. S. Pressman, Software Engineering: A Practitioners Approach, McGraw Hill.

2. Rajib Mall, Fundamentals of Software Engineering, PHI Publication.
3. K. K. Aggarwal and Yogesh Singh, Software Engineering, New Age International
Publishers.
4. Pankaj Jalote, Software Engineering, Wiley
5. Deepak Jain,” Software Engineering: Principles and Practices”, Oxford University Press.
6. Munesh C. Trivedi, Software Engineering, Khanna Publishing House
7. N.S. Gill, Software Engineering, Khanna Publishing House

23-11-2023 Ms. Rifa Nizam Khan ACSBS0304 Software Engineering Unit 5 165