Notes Unit 4 SE - ETCS 303

Unit – 4
Software Testing
Software Testing Introduction
Software testing is a process of identifying the correctness of a 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.
Software testing provides an independent view and objective of the software

and gives surety of fitness of the software. It involves testing of all components
under the required services to confirm that whether it is satisfying the specified
requirements or not. The process is also providing the client with information
about the quality of the software.
Testing is mandatory because it will be a dangerous situation if the software

fails any of time due to lack of testing. So, without testing software cannot be
deployed to the end user.
Who does Testing?

It depends on the process and the associated stakeholders of the project(s). In
the IT industry, large companies have a team with responsibilities to evaluate
the developed software in context of the given requirements. Moreover,
developers also conduct testing which is called Unit Testing. In most cases,
Software Engineering (ETCS 303) By Dr Shafiqul Abidin, HMRITM, (GGSIPU), Delhi

the following professionals are involved in testing a system within their
respective capacities −
 Software Tester
 Software Developer
 Project Lead/Manager
 End User
Different companies have different designations for people who test the
software on the basis of their experience and knowledge such as Software
Tester, Software Quality Assurance Engineer, QA Analyst, etc.
It is not possible to test the software at any time during its cycle. The next two
sections state when testing should be started and when to end it during the
SDLC.
Software testing can be divided into two steps:
Verification & Validation

These two terms are very confusing for most people, who use them
interchangeably.
1. Verification: it refers to the set of tasks that ensure that software correctly
implements a specific function.
2. Validation: it refers to a different set of tasks that ensure that the software
that has been built is traceable to customer requirements.
The following table highlights the differences between verification and
validation.

Verification:"Are we building the product right?"
Validation: "Are we building the right product?"
Verification Validation
Verification addresses the Validation addresses the concern:

concern: "Are you building it "Are you building the right
right?" thing?"
Ensures that the software Ensures that the functionalities

system meets all the meet the intended behavior.
functionality.
Verification takes place first Validation occurs after

and includes the checking for verification and mainly involves
documentation, code, etc. the checking of the overall
product.
Done by developers. Done by testers.
It has static activities, as it It has dynamic activities, as it

includes collecting reviews, includes executing the software
walkthroughs, and inspections against the requirements.
to verify a software.
It is an objective process and It is a subjective process and

no subjective decision should involves subjective decisions on
be needed to verify a software. how well a software works.

Function Testing and Structural Testing
Functional Testing
Functional Testing is a testing technique that is used to test the features/functionality of the system or
Software, should cover all the scenarios including failure paths and boundary cases.
Functional Testing is a type of software testing whereby the system is tested against the functional
requirements/specifications. Functions (or features) are tested by feeding them input and examining the
output. Functional testing ensures that the requirements are properly satisfied by the application. This
type of testing is not concerned with how processing occurs, but rather, with the results of processing. It
simulates actual system usage but does not make any system structure assumptions.
During functional testing, Black Box Testing technique is used in which the internal logic of the system
being tested is not known to the tester.
Functional testing is normally performed during the levels of System Testing and Acceptance Testing.
Functional testing is more effective when the test conditions are created directly from user/business
requirements. When test conditions are created from the system documentation (system requirements/
design documents), the defects in that documentation will not be detected through testing and this may be
the cause of end-users‟ wrath when they finally use the software.
Functional Testing Techniques:
There are two major Functional Testing techniques as shown below:

Functional Testing
Advantages
Simulates actual system usage.
Makes no system structure assumptions.
Disadvantages
Potential of missing logical errors in software.
Possibility of redundant testing.
The other major Functional Testing techniques include:
 Unit Testing
 Integration Testing
 Smoke Testing
 User Acceptance Testing
 Localization Testing
 Interface Testing
 Usability Testing
 System Testing
 Regression Testing
 Globalization Testing
Black Box Testing
Black box testing is a technique of software testing which examines the

functionality of software without peering into its internal structure or coding.
The primary source of black box testing is a specification of requirements that
is stated by the customer.
In this method, tester selects a function and gives input value to examine its
functionality, and checks whether the function is giving expected output or not.
If the function produces correct output, then it is passed in testing, otherwise
failed. The test team reports the result to the development team and then tests
the next function. After completing testing of all functions if there are severe
problems, then it is given back to the development team for correction.

Generic steps of black box testing
 The black box test is based on the specification of requirements, so it is

examined in the beginning.
 In the second step, the tester creates a positive test scenario and an
adverse test scenario by selecting valid and invalid input values to check
that the software is processing them correctly or incorrectly.
 In the third step, the tester develops various test cases such as decision
table, all pairs test, equivalent division, error estimation, cause-effect
graph, etc.
 The fourth phase includes the execution of all test cases.
 In the fifth step, the tester compares the expected output against the
actual output.
 In the sixth and final step, if there is any flaw in the software, then it is
cured and tested again.
Test procedure
The test procedure of black box testing is a kind of process in which the tester
has specific knowledge about the software's work, and it develops test cases to
check the accuracy of the software's functionality.
It does not require programming knowledge of the software. All test cases are
designed by considering the input and output of a particular function.A tester
knows about the definite output of a particular input, but not about how the
result is arising. There are various techniques used in black box testing for
testing like decision table technique, boundary value analysis technique, state

transition, All-pair testing, cause-effect graph technique, equivalence
partitioning technique, error guessing technique, use case technique and user
story technique.
Test cases
Test cases are created considering the specification of the requirements. These
test cases are generally created from working descriptions of the software
including requirements, design parameters, and other specifications. For the
testing, the test designer selects both positive test scenario by taking valid input
values and adverse test scenario by taking invalid input values to determine the
correct output. Test cases are mainly designed for functional testing but can
also be used for non-functional testing. Test cases are designed by the testing
team, there is not any involvement of the development team of software.
Techniques Used in Black Box Testing

Decision Table Technique is a systematic approach where various input
Decision Table combinations and their respective system behavior are captured in a tabular form. It
Technique is appropriate for the functions that have a logical relationship between two and more
than two inputs.
Boundary Value Technique is used to test boundary values, boundary values are
Boundary Value
those that contain the upper and lower limit of a variable. It tests, while entering
Technique
boundary value whether the software is producing correct output or not.
State Transition Technique is used to capture the behavior of the software application
State Transition when different input values are given to the same function. This applies to those
Technique types of applications that provide the specific number of attempts to access the
application.
All-pair testing Technique is used to test all the possible discrete combinations of
All-pair Testing
values. This combinational method is used for testing the application that uses
Technique
checkbox input, radio button input, list box, text box, etc.
Cause-Effect Cause-Effect Technique underlines the relationship between a given result and all the
Technique factors affecting the result.It is based on a collection of requirements.
Equivalence Equivalence partitioning is a technique of software testing in which input data
Partitioning divided into partitions of valid and invalid values, and it is mandatory that all
Technique partitions must exhibit the same behavior.
Error guessing is a technique in which there is no specific method for identifying the
Error Guessing
error. It is based on the experience of the test analyst, where the tester uses the
Technique
experience to guess the problematic areas of the software.

Use case Technique used to identify the test cases from the beginning to the end of
Use Case the system as per the usage of the system. By using this technique, the test team
Technique creates a test scenario that can exercise the entire software based on the functionality
of each function from start to end.
Decision table technique in Black box testing
Decision table technique is one of the widely used case design techniques for black box testing. This is a
systematic approach where various input combinations and their respective system behavior are captured
in a tabular form.
That's why it is also known as a cause-effect table. This technique is used to pick the test cases in a
systematic manner; it saves the testing time and gives good coverage to the testing area of the software
application.
Decision table technique is appropriate for the functions that have a logical relationship between two and
more than two inputs.
This technique is related to the correct combination of inputs and determines the result of various
combinations of input. To design the test cases by decision table technique, we need to consider
conditions as input and actions as output.
Let's understand it by an example:
Most of us use an email account, and when you want to use an email account, for this you need to enter
the email and its associated password.
If both email and password are correctly matched, the user will be directed to the email account's
homepage; otherwise, it will come back to the login page with an error message specified with "Incorrect
Email" or "Incorrect Password."
Now, let's see how a decision table is created for the login function in which we can log in by using email
and password. Both the email and the password are the conditions, and the expected result is action.
In the table, there are four conditions or test cases to test the login function. In the first condition if both
email and password are correct, then the user should be directed to account's Homepage.

In the second condition if the email is correct, but the password is incorrect then the function should
display Incorrect Password. In the third condition if the email is incorrect, but the password is correct,
then it should display Incorrect Email.
Now, in fourth and last condition both email and password are incorrect then the function should display
Incorrect Email.
In this example, all possible conditions or test cases have been included, and in the same way, the testing
team also includes all possible test cases so that upcoming bugs can be cured at testing level.
In order to find the number of all possible conditions, tester uses 2n formula where n denotes the number
of inputs; in the example there is the number of inputs is 2 (one is true and second is false).
Number of possible conditions = 2^ Number of Values of the second condition

Number of possible conditions =2^2 = 4
While using the decision table technique, a tester determines the expected output, if the function produces
expected output, then it is passed in testing, and if not then it is failed. Failed software is sent back to the
development team to fix the defect.
Decision Table Testing
Decision table testing is a testing technique used to test system behavior for different input
combinations. This is a systematic approach where the different input combinations and their
corresponding system behavior (Output) are captured in a tabular form. That is why it is also called
as a Cause-Effect table where Cause and effects are captured for better test coverage.
A Decision Table is a tabular representation of inputs versus rules/cases/test conditions. Let's learn
with an example.
Example 1: Decision Base Table for Login Screen
Let's create a decision table for a login screen.

The condition is simple if the user provides correct username and password the user will be
redirected to the homepage. If any of the input is wrong, an error message will be displayed.
Conditions Rule 1 Rule 2 Rule 3 Rule 4
Username (T/F) F T F T
Password (T/F) F F T T
Output (E/H) E E E H
Advantage of decision table technique:
1. Any complex business flow can be easily converted into the test scenarios & test cases using this
technique.
2. Such type of table are work iteratively, means the table created at the first iteration is used as
input table for next tables. Such iteration can be carried out only if the initial table is
unsatisfactory.
3. Simple to understand and everyone can use this method design the test scenarios & test cases.
4. It provide complete coverage of test cases which help to reduce the rework on writing test
scenarios & test cases.
5. These tables guarantee that we consider every possible combination of condition values. This is
known as its “completeness property”.
Boundary Value Analysis
Boundary value analysis is one of the widely used case design technique for black box testing. It is used
to test boundary values because the input values near the boundary have higher chances of error.
Whenever we do the testing by boundary value analysis, the tester focuses on, while entering boundary
value whether the software is producing correct output or not.
Boundary values are those that contain the upper and lower limit of a variable. Assume that, age is a
variable of any function, and its minimum value is 18 and the maximum value is 30, both 18 and 30 will
be considered as boundary values.

The basic assumption of boundary value analysis is, the test cases that are created using boundary values
are most likely to cause an error.
There is 18 and 30 are the boundary values that's why tester pays more attention to these values, but this
doesn't mean that the middle values like 19, 20, 21, 27, 29 are ignored. Test cases are developed for each
and every value of the range.
Testing of boundary values is done by making valid and invalid partitions. Invalid partitions are tested
because testing of output in adverse condition is also essential.
Let's understand via practical:
Imagine, there is a function that accepts a number between 18 to 30, where 18 is the minimum and 30 is
the maximum value of valid partition, the other values of this partition are 19, 20, 21, 22, 23, 24, 25, 26,
27, 28 and 29. The invalid partition consists of the numbers which are less than 18 such as 12, 14, 15, 16
and 17, and more than 30 such as 31, 32, 34, 36 and 40. Tester develops test cases for both valid and
invalid partitions to capture the behavior of the system on different input conditions.

The software system will be passed in the test if it accepts a valid number and gives the desired output, if
it is not, then it is unsuccessful. In another scenario, the software system should not accept invalid
numbers, and if the entered number is invalid, then it should display error massage.
If the software which is under test, follows all the testing guidelines and specifications then it is sent to
the releasing team otherwise to the development team to fix the defects.
Example: For a function that computes the square root of integer values in the range of 0 and 5000, the
test cases must include the following values: {0, -1,5000,5001}.
Cause and Effect Graph in Black box Testing
Cause-effect graph comes under the black box testing technique which underlines the relationship
between a given result and all the factors affecting the result. It is used to write dynamic test cases.
The dynamic test cases are used when code works dynamically based on user input. For example, while
using email account, on entering valid email, the system accepts it but, when you enter invalid email, it
throws an error message. In this technique, the input conditions are assigned with causes and the result of
these input conditions with effects.
Cause-Effect graph technique is based on a collection of requirements and used to determine minimum
possible test cases which can cover a maximum test area of the software.
The main advantage of cause-effect graph testing is, it reduces the time of test execution and cost.
This technique aims to reduce the number of test cases but still covers all necessary test cases with
maximum coverage to achieve the desired application quality.
Cause-Effect graph technique converts the requirements specification into a logical relationship between
the input and output conditions by using logical operators like AND, OR and NOT.
Notations used in the Cause-Effect Graph

AND - E1 is an effect and C1 and C2 are the causes. If both C1 and C2 are true, then effect E1 will be
true.
OR - If any cause from C1 and C2 is true, then effect E1 will be true.
NOT - If cause C1 is false, then effect E1 will be true.
Mutually Exclusive - When only one cause is true.
Let's try to understand this technique with some examples:

Situation:
The character in column 1 should be either A or B and in the column 2 should be a digit. If both columns
contain appropriate values then update is made. If the input of column 1 is incorrect, i.e. neither A nor B,
then message X will be displayed. If the input in column 2 is incorrect, i.e. input is not a digit, then
message Y will be displayed.
 A file must be updated, if the character in the first column is either "A" or "B" and in the second column it
should be a digit.
 If the value in the first column is incorrect (the character is neither A nor B) then massage X will be
displayed.
 If the value in the second column is incorrect (the character is not a digit) then massage Y will be
displayed.
Now, we are going to make a Cause-Effect graph for the above situation:
Causes are:
 C1 - Character in column 1 is A
 C2 - Character in column 1 is B
 C3 - Character in column 2 is digit!
Effects:
 E1 - Update made (C1 OR C2) AND C3

 E2 - Displays Massage X (NOT C1 AND NOT C2)
 E3 - Displays Massage Y (NOT C3)
Where AND, OR, NOT are the logical gates.

Effect E1- Update made- The logic for the existence of effect E1 is "(C1 OR C2) AND C3". For C1
OR C2, any one from C1 and C2 should be true. For logic AND C3 (Character in column 2 should be a
digit), C3 must be true. In other words, for the existence of effect E1 (Update made) any one from C1 and
C2 but the C3 must be true. We can see in graph cause C1 and C2 are connected through OR logic and
effect E1 is connected with AND logic.
Effect E2 - Displays Massage X - The logic for the existence of effect E2 is "NOT C1 AND NOT C2"
that means both C1 (Character in column 1 should be A) and C2 (Character in column 1 should be B)
should be false. In other words, for the existence of effect E2 the character in column 1 should not be
either A or B. We can see in the graph, C1 OR C2 is connected through NOT logic with effect E2.
Effect E3 - Displays Massage Y- The logic for the existence of effect E3 is "NOT C3" that means cause
C3 (Character in column 2 is a digit) should be false. In other words, for the existence of effect E3, the
character in column 2 should not be a digit. We can see in the graph, C3 is connected through NOT logic
with effect E3.
So, it is the cause-effect graph for the given situation. A tester needs to convert causes and effects into
logical statements and then design cause-effect graph. If function gives output (effect) according to the
input (cause) so, it is considered as defect free, and if not doing so, then it is sent to the development team
for the correction.
Conclusion
Summary of the steps:
 Draw the circles for effects and Causes.

 Start from effect and then pick up what is the cause of this effect.
 Draw mutually exclusive causes (exclusive causes which are directly connected via one effect and one
cause) at last.
 Use logic gates to draw dynamic test cases.

Benefits of making cause-Effect Diagram
 It finds out the areas where data is collected for additional study.
 It motivates team contribution and uses the team data of the process.
 Uses synchronize and easy to read format to diagram cause-and-effect relationships.
 Point out probable reasons of difference in a process.
 It enhances facts of the procedure by helping everyone to learn more about the factors at work and how
they relate.
 It assists us to decide the root reasons of a problem or quality using a structured approach.
Steps to proceed on Cause-Effect Diagram:

Firstly: Recognize and describe the input conditions (causes) and actions (effect)
Secondly: Build up a cause-effect graph
Third: Convert cause-effect graph into a decision table
Fourth: Convert decision table rules to test cases. Each column of the decision table represents a test
case
Let’s draw a cause and effect graph based on a situation

Situation:
The “Print message” is software that read two characters and, depending on their values, messages must
be printed.
 The first character must be an “A” or a “B”.

 The second character must be a digit.
 If the first character is an “A” or “B” and the second character is a digit, the file must be updated.
 If the first character is incorrect (not an “A” or “B”), the message X must be printed.
 If the second character is incorrect (not a digit), the message Y must be printed.
Solution:
The causes for this situation are:
C1 – First character is A
C2 – First character is B
C3 – the Second character is a digit
The effects (results) for this situation are

E1 – Update the file
E2 – Print message “X”
E3 – Print message “Y”
LET’S START!!

First, draw the causes and effects as shown below:
Key – Always go from effect to cause (left to right). That means, to get effect “E”, what causes should be
true.
In this example, let‟s start with Effect E1.
Effect E1 is to update the file. The file is updated when

– The first character is “A” and the second character is a digit
– The first character is “B” and the second character is a digit
– The first character can either be “A” or “B” and cannot be both.
Now let‟s put these 3 points in symbolic form:
For E1 to be true – following are the causes:

– C1 and C3 should be true
– C2 and C3 should be true
– C1 and C2 cannot be true together. This means C1 and C2 are mutually exclusive.

\Now let‟s draw this:
So as per the above diagram, for E1 to be true the condition is

(C1 C2) C3
The circle in the middle is just an interpretation of the middle point to make the graph less messy.
There is a third condition where C1 and C2 are mutually exclusive. So the final graph for effect E1 to be
true is shown below:

Let’s move to Effect E2:
E2 states to print message “X”. Message X will be printed when the First character is neither A nor B.
Which means Effect E2 will hold true when either C1 OR C2 is invalid. So the graph for Effect E2 is
shown as (In blue line)
For Effect E3.

E3 states to print message “Y”. Message Y will be printed when Second character is incorrect.
Which means Effect E3 will hold true when C3 is invalid. So the graph for Effect E3 is shown as (In
Green line)
This completes the Cause and Effect graph for the above situation.
Now let‟s move to draw the Decision table based on the above graph.

Writing Decision table based on Cause and Effect graph
First, write down the Causes and Effects in a single column shown below
Key is the same. Go from bottom to top which means traverse from effect to cause.
Start with Effect E1. For E1 to be true, the condition is (C1 C2) C3.
Here we are representing True as 1 and False as 0
First, put Effect E1 as True in the next column as
Now for E1 to be “1” (true), we have the below two conditions –

C1 AND C3 will be true
C2 AND C3 will be true
For E2 to be True, either C1 or C2 has to be false shown as

For E3 to be true, C3 should be false.
So it‟s done. Let‟s complete the graph by adding 0 in the blank column and including the test case
identifier.
Writing Test cases from the decision table

I am writing a sample test case for test case 1 (TC1) and Test Case 2 (TC2).
In a similar fashion, you can create other test cases.

(A test case contains many other attributes like preconditions, test data, severity, priority, build, version,
release, environment etc. I assume all these attributes to be included when you write the test cases in
actual situation)
Conclusion
Summarizing the steps once again:
1. Draw the circles for Causes and Graphs

2. Start from effects and move towards the cause.
3. Look for mutually exclusive causes.
This finishes the Cause and Effect graph dynamic test case writing technique. We have seen how to draw
the graph and how to draw the decision table based on it. The final step of writing test cases based on
decision table is comparatively easy.
Equivalence Partitioning Technique

Equivalence partitioning is a technique of software testing in which input data is divided into partitions of
valid and invalid values, and it is mandatory that all partitions must exhibit the same behavior. If a
condition of one partition is true, then the condition of another equal partition must also be true, and if a
condition of one partition is false, then the condition of another equal partition must also be false. The
principle of equivalence partitioning is, test cases should be designed to cover each partition at least once.
Each value of every equal partition must exhibit the same behavior as other.
The equivalence partitions are derived from requirements and specifications of the software. The
advantage of this approach is, it helps to reduce the time of testing due to a smaller number of test cases
from infinite to finite. It is applicable at all levels of the testing process.
For example, assume that there is a function of a software application that accepts a particular number of
digits, not greater and less than that particular number. For example, an OTP number which contains only
six digits, less or more than six digits will not be accepted, and the application will redirect the user to the
error page.
1. 1. OTP Number = 6 digits

Let's see one more example.
A function of the software application accepts a 10 digit mobile number.
1. 2. Mobile number = 10 digits
In both examples, we can see that there is a partition of two equally valid and invalid partitions, on
applying valid value such as OTP of six digits in the first example and mobile number of 10 digits in the
second example, both valid partitions behave same, i.e. redirected to the next page.
Another two partitions contain invalid values such as 5 or less than 5 and 7 or more than 7 digits in the
first example and 9 or less than 9 and 11 or more than 11 digits in the second example, and on applying
these invalid values, both invalid partitions behave same, i.e. redirected to the error page.

We can see in the example, there are only three test cases for each example and that is also the principal
of equivalence partitioning which states that this method intended to reduce the number of test cases.
Example 1: For a software that computes the square root of an input integer which can assume values in
the range of 0 to 5000, there are three equivalence classes: The set of negative integers, the set of integers
in the range of 0 and 5000, and the integers larger than 5000. Therefore, the test cases must include
representatives for each of the three equivalence classes and a possible test set can be: {-5,500,6000}.
Example 2: Design the black-box test suite for the following program. The program computes the
intersection point of two straight lines and displays the result. It reads two integer pairs (m1, c1) and (m2,
c2) defining the two straight lines of the form y=mx + c.
The equivalence classes are the following:
Parallel lines (m1=m2,c1≠c2)
• Intersecting lines(m1≠m2)
• Coincident lines (m1=m2,c1=c2)
Now, selecting one representative value from each equivalence class, the test suit (2, 2) (2, 5), (5,
5) (7, 7), (10, 10) (10, 10) are obtained.
Design of Test Cases

Exhaustive testing of almost any non-trivial system is impractical due to the fact that the domain of input
data values to most practical software systems is either extremely large or infinite. Therefore, we must
design an optional test suite that is of reasonable size and can uncover as many errors existing in the
system as possible. Actually, if test cases are selected randomly,
manyoftheserandomlyselectedtestcasesdonotcontributetothesignificanceofthetestsuite,
they do not detect any additional defects not already being detected by other test cases in the suite. Thus,
the number of random test cases in a test suite is, in general, not an indication of the effectiveness of the
testing. In other words, testing a system using a large collection of test cases that are selected at random
does not guarantee that all (or even most) of the errors in the system will be uncovered. Consider the
following example code segment which finds the greater of two integer values x and y. This code
segment has a simple programming error.
if (x>y)
max = x;
else
max = x;

For the above code segment, the test suite, {(x=3,y=2);(x=2,y=3)} can detect the error, whereas a larger
test suite {(x=3,y=2);(x=4,y=3);(x=5,y=1)} does not detect the error. So, it would be incorrect to say that
a larger test suite would always detect more errors than a smaller one, unless of course the larger test
suite has also been carefully designed. This implies that the test suite should be carefully designed than
picked randomly. Therefore, systematic approaches should be followed to design an optimal test suite. In
an optimal test suite, each test case is designed to detect different errors.
Functional Testing Vs. Structural Testing
In the black-box testing approach, test cases are designed using only the functional specification of the
software, i.e. without any knowledge of the internal structure of the software. For this reason, black-box
testing is known as functional testing. On the other hand, in the white-box testing approach, designing
test cases requires thorough knowledge about the internal structure of software, and therefore the white-
box testing is called structural testing.

White Box Testing
One white-box testing strategy is said to be stronger than another strategy, if all types of errors
detected by the first testing strategy is also detected by the second testing strategy, and the
second testing strategy additionally detects some more types of errors. When two testing
strategies detect errors that are different at least with respect to some types of errors, then they
are called complementary. The concepts of stronger and complementary testing are schematically
illustrated in figure.
Stronger and complementary testing strategies

Comparison: Black Box and White Box Testing
BLACK BOX TESTING WHITE BOX TESTING
Internal workings of an application are not
required. Knowledge of the internal workings is must.
Also known as closed box/data driven testing. Also knwon as clear box/structural testing.
End users, testers and developers. Normally done by testers and developers.
Data domains and internal boundaries can be better
This can only be done by trial and error method. tested.
Structural Testing
Structural testing, also known as glass box testing or white box testing is an approach where the tests are
derived from the knowledge of the software's structure or internal implementation.
The other names of structural testing includes clear box testing, open box testing, logic driven testing or
path driven testing.
Advantages of Structural Testing:

 Forces test developer to reason carefully about implementation
 Reveals errors in "hidden" code
 Spots the Dead Code or other issues with respect to best programming practices.
Structural Testing Techniques:
 Statement Coverage - This technique is aimed at exercising all programming statements with
minimal tests.
 Branch Coverage - This technique is running a series of tests to ensure that all branches are
tested at least once.
 Path Coverage - This technique corresponds to testing all possible paths which means that each
statement and branch are covered.
 Data Flow
 Mutation Testing

Path Testing
Path Testing is a structural testing method based on the source code or algorithm and NOT based on the
specifications. It can be applied at different levels of granularity.
Path Testing Assumptions:

 The Specifications are Accurate
 The Data is defined and accessed properly
 There are no defects that exist in the system other than those that affect control flow
Path Testing Techniques:

 Control Flow Graph (CFG) - The Program is converted into Flow graphs by representing the code into nodes,
regions and edges.
 Decision to Decision path (D-D) - The CFG can be broken into various Decision to Decision paths and then
collapsed into individual nodes.
 Independent (basis) paths - Independent path is a path through a DD-path graph which cannot be reproduced
from other paths by other methods.
Data Flow Testing

Data flow testing is a family of test strategies based on selecting paths through the program's control
flow in order to explore sequences of events related to the status of variables or data objects. Dataflow
Testing focuses on the points at which variables receive values and the points at which these values are
used.
Advantages of Data Flow Testing:

Data Flow testing helps us to pinpoint any of the following issues:
 A variable that is declared but never used within the program.
 A variable that is used but never declared.
 A variable that is defined multiple times before it is used.
 Deallocating a variable before it is used.

Mutation Testing
Mutation testing is a structural testing technique, which uses the structure of the code to guide the testing
process. On a very high level, it is the process of rewriting the source code in small ways in order to
remove the redundancies in the source code
These ambiguities might cause failures in the software if not fixed and can easily pass through testing
phase undetected.
Mutation Testing Benefits:

Following benefits are experienced, if mutation testing is adopted:
 It brings a whole new kind of errors to the developer's attention.
 It is the most powerful method to detect hidden defects, which might be impossible to identify using the
conventional testing techniques.
 Tools such as Insure++ help us to find defects in the code using the state-of-the-art.
 Increased customer satisfaction index as the product would be less buggy.
 Debugging and Maintaining the product would be more easier than ever.
Different levels of software testing

Software level testing can be majorly classified into 4 levels:
1. Unit Testing: A level of the software testing process where individual units/components of a
software/system are tested. The purpose is to validate that each unit of the software performs as designed.
2. Integration Testing: A level of the software testing process where individual units are combined and
tested as a group. The purpose of this level of testing is to expose faults in the interaction between
integrated units.
3. System Testing: A level of the software testing process where a complete, integrated system/software
is tested. The purpose of this test is to evaluate the system‟s compliance with the specified requirements.
4. Acceptance Testing: A level of the software testing process where a system is tested for acceptability.
The purpose of this test is to evaluate the system‟s compliance with the business requirements and assess
whether it is acceptable for delivery.

Debugging
Definition: Debugging is the process of detecting and removing of existing and potential errors (also
called as „bugs‟) in a software code that can cause it to behave unexpectedly or crash. Debugging tools
are use for this purpose.
To prevent incorrect operation of a software or system, debugging is used to find and resolve bugs or
defects. When various subsystems or modules are tightly coupled, debugging becomes harder as any
change in one module may cause more bugs to appear in another. Sometimes it takes more time to debug
a program than to code it.
Debugging checks, detects and corrects errors or bugs to allow proper program operation according to set
specifications.
Debugging Approaches:
The following are a number of approaches popularly adopted by programmers for debugging.
 Brute Force Method:

This is the foremost common technique of debugging however is that the least economical
method
 Backtracking:
This is additionally a reasonably common approach. during this approach, starting from the
statement at which an error symptom has been discovered, the source code is derived backward
till the error is discovered.
 Cause Elimination Method:
In this approach, a listing of causes that may presumably have contributed to the error symptom is
developed and tests are conducted to eliminate every. A connected technique of identification of
the error from the error symptom is that the package fault tree analysis.
 Program Slicing:
This technique is analogous to backtracking. Here the search house is reduced by process slices. A
slice of a program for a specific variable at a particular statement is that the set of supply lines
preceding this statement which will influence the worth of that variable

Differences between Testing and Debugging
Below is the difference between testing and debugging:
Testing Debugging
Debugging is the process to correct the

Testing is the process to find bugs and errors.
bugs found during testing.
It is the process to identify the failure of implemented It is the process to give the absolution to
code. code failure.
Testing is the display of errors. Debugging is a deductive process.
Debugging is done by either programmer

Testing is done by the tester.
or developer.
There is no need of design knowledge in the testing Debugging can‟t be done without proper
process. design knowledge.
Debugging is done only by insider.

Testing can be done by insider as well as outsider.
Outsider can‟t do debugging.
Debugging is always manual. Debugging

Testing can be manual or automated.
can‟t be automated.
It is based on different testing levels i.e. unit testing, Debugging is based on different types of
integration testing, system testing etc. bugs.

Software Testing Tools
Top 10 Most Popular Software Testing Tools

This list of tools features tools that perform regression test, cross-browser tests, and other tests that you'll
need in your DevOps process.
Selenium
Selenium is one of the oldest and most popular tools in test automation.
UFT/QTP
Unified Functional Test (UFT), formerly known as Quick Test Professional (QTP), is a leading cross-
platform test automation tool.
Katalon Studio
Katalon Studio is another popular open-source test automation tool for the web and mobile environment.
Silk Test
Silk Test is a test automation tool from Microfocus used for automated functional and regression testing.
It is known for its speedy, efficient and high-quality test automation
Squish
Squish has become the latest sensation in test automation. It is the number one choice for organizations
when it comes to GUI test automation worldwide.
TestComplete
TestComplete is a functional test automation platform developed by SmartBear. TestComplete gives

software testers the ability to create automated tests for web,
Ranorex
Ranorex is an all-in-one GUI test automation tool from Ranorex Studio. Ranorex is used for end-to-end
testing on mobile, desktop and web application
Appium

Appium is another popular open-source mobile test automation tool for all native, hybrid, and mobile
web apps for iOS and Android.
SoapUI
As the name indicates, SoapUI is a widely used open-source test automation tool for SOAP and REST
APIs. SoapUI is a functional testing tool explicitly designed for API testing by SmartBear.
EggPlant
EggPlant is a black-box GUI test automation tool. For software testers, Eggplant offers an assortment of
test automation tools utilizing which you can perform various types of testing.
Difference between system testing and acceptance testing

S.no. System Testing Acceptance Testing
Acceptance testing is performed to test whether
System testing is performed to test end to end
1 the software is conforming specified
functionality of the software.
requirements and user requirements or not.
Only developers and testers can perform System It can be performed by testers, stakeholders and
2
testing. costumers.
It can be both non-functional and functional
3 It can be only functional testing.
testing.
In System testing, we test the performance of the In Acceptance testing, we test whether the system
4
whole system. is conforming requirements or not.
System testing uses demo input values that are Acceptance testing uses the actual real-time input
5
selected by the testing team. values provided by the user.
In this testing, we include the testing of complete
Here we test whether the software is fulfilling all
6 specification including software and hardware,
the needs of the user or not.
memory and number of users.
System Testing is a combination of System Acceptance Testing is a combination of alpha
7
Testing and Integration testing. testing and beta testing.
8 It is performed before the Acceptance testing. It is performed after the System testing.
Acceptance testing involves boundary value
System testing involves load and stress testing
9 analysis, equivalence portioning and decision
under non-functional testing.
table under functional testing.
The defects found in system testing are The defects found in acceptance testing are
10
considered to be fixed. considered as product failure.

Alpha Testing Introduction
Alpha testing is conducted in the organization and tested by a representative group of end-users at the
developer's side and sometimes by an independent team of testers.
Alpha testing is simulated or real operational testing at an in-house site. It comes after the unit testing,
integration testing, etc. Alpha testing used after all the testing are executed.
It can be a white box, or Black-box testing depends on the requirements - particular lab environment and
simulation of the actual environment required for this testing.

Beta Testing
Beta Testing is a part of acceptance testing which is intended to validate the product for usability,
functionality, reliability, and compatibility by the end-user. It adds value to the software as user validates
it by providing real input values.
It helps in enhancement of the quality of software and leads it towards success. Also, helpful in deciding
whether the software is worthy to invest more in future versions or not.
It is not controlled activity since it happens at the user's side. It is considered as final testing before
delivering the software to the customers. Software released for beta testing is known as beta software.

Software Maintenance
Definition of 'Software Maintenance’
Definition: Software maintenance is a part of Software Development Life Cycle. Its main purpose is to
modify and update software application after delivery to correct faults and to improve performance.
Software is a model of the real world. When the real world changes, the software requires alteration
wherever possible.
Description: Software maintenance is a vast activity which includes optimization, error correction,
deletion of discarded features and enhancement of existing features. Since these changes are necessary, a
mechanism must be created for estimation, controlling and making modifications. The essential part of
software maintenance requires preparation of an accurate plan during the development cycle. Typically,
maintenance takes up about 40-80% of the project cost, usually closer to the higher pole. Hence, a focus
on maintenance definitely helps keep costs down.
Types of software maintenance

In a software lifetime, type of maintenance may vary based on its nature. It may be just a routine
maintenance tasks as some bug discovered by some user or it may be a large event in itself based on
maintenance size or nature. Following are some types of maintenance based on their characteristics:
 Corrective Maintenance - This includes modifications and updations done in order to correct or
fix problems, which are either discovered by user or concluded by user error reports.
 Adaptive Maintenance - This includes modifications and updations applied to keep the software
product up-to date and tuned to the ever changing world of technology and business environment.
 Perfective Maintenance - This includes modifications and updates done in order to keep the
software usable over long period of time. It includes new features, new user requirements for
refining the software and improve its reliability and performance.
 Preventive Maintenance - This includes modifications and updations to prevent future problems
of the software. It aims to attend problems, which are not significant at this moment but may
cause serious issues in future.

Cost of Maintenance
Reports suggest that the cost of maintenance is high. A study on estimating software maintenance found
that the cost of maintenance is as high as 67% of the cost of entire software process cycle.
On an average, the cost of software maintenance is more than 50% of all SDLC phases. There are various
factors, which trigger maintenance cost go high, such as:
Process of Software Maintenance:

Software Maintenance is an important phase of Software Development Life Cycle (SDLC), and it is
implemented in the system through a proper software maintenance process, known as Software
Maintenance Life Cycle (SMLC). This life cycle consists of seven different phases, each of which can
be used in iterative manner and can be extended so that customized items and processes can be included.
These seven phases of Software Maintenance process are:
1. Identification Phase:
In this phase, the requests for modifications in the software are identified and analysed. Each of
the requested modification is then assessed to determine and classify the type of maintenance
activity it requires. This is either generated by the system itself, via logs or error messages, or by
the user.
2. Analysis Phase:

The feasibility and scope of each validated modification request are determined and a plan is
prepared to incorporate the changes in the software. The input attribute comprises validated
modification request, initial estimate of resources, project documentation, and repository
information. The cost of modification and maintenance is also estimated.
3. Design Phase:
The new modules that need to be replaced or modified are designed as per the requirements
specified in the earlier stages. Test cases are developed for the new design including the safety
and security issues. These test cases are created for the validation and verification of the system.
4. Implementation Phase:
In the implementation phase, the actual modification in the software code are made, new features
that support the specifications of the present software are added, and the modified software is
installed. The new modules are coded with the assistance of structured design created in the
design phase.
5. System Testing Phase:
Regression testing is performed on the modified system to ensure that no defect, error or bug is
left undetected. Furthermore, it validates that no new faults are introduced in the software as a
result of maintenance activity. Integration testing is also carried out between new modules and
the system.
6. Acceptance Testing Phase:
Acceptance testing is performed on the fully integrated system by the user or by the third party
specified by the end user. The main objective of this testing is to verify that all the features of the
software are according to the requirements stated in the modification request.
7. Delivery Phase:
Once the acceptance testing is successfully accomplished, the modified system is delivered to the
users. In addition to this, the user is provided proper consisting of manuals and help files that
describe the operation of the software along with its hardware specifications. The final testing of
the system is done by the client after the system is delivered.

Software Maintenance Models:
To overcome internal as well as external problems of the software, Software maintenance models are
proposed. These models use different approaches and techniques to simplify the process of maintenance
as well as to make is cost effective. Software maintenance models that are of most importance are:
Quick-Fix Model:
This is an ad hoc approach used for maintaining the software system. The objective of this model is to
identify the problem and then fix it as quickly as possible. The advantage is that it performs its work
quickly and at a low cost. This model is an approach to modify the software code with little consideration
for its impact on the overall structure of the software system.

Iterative Enhancement Model:
Iterative enhancement model considers the changes made to the system are iterative in nature. This model
incorporates changes in the software based on the analysis of the existing system. It assumes complete
documentation of the software is available in the beginning. Moreover, it attempts to control complexity
and tries to maintain good design.
Iterative Enhancement Model is divided into three stages:
1. Analysis of software system.

2. Classification of requested modifications.
3. Implementation of requested modifications.
The Re-use Oriented Model:

The reuse-oriented model assumes that the existing program components can be reused to perform
maintenance. The parts of the old/existing system that are appropriate for reuse are identified and
understood, in Reuse Oriented Model. These parts are then go through modification and enhancement,
which are done on the basis of the specified new requirements. The final step of this model is the
integration of modified parts into the new system.

It consists of the following steps.
1. Identifying the components of the old system which can be reused

2. Understanding these components
3. Modifying the old system components so that they can be used in the new system
4. Integrating the modified components into the new system.

Techniques for Maintenance
Reverse Engineering
It is a process to achieve system specification by thoroughly analyzing, understanding the existing

system.
Reverse Engineering is processes of extracting knowledge or design information from anything man-
made and reproducing it based on extracted information. It is also called back Engineering.
Software Reverse Engineering is the process of recovering the design and the requirements specification
of a product from an analysis of it‟s code. Reverse Engineering is becoming important, since several
existing software products, lack proper documentation, are highly unstructured, or their structure has
degraded through a series of maintenance efforts.
Why Reverse Engineering?
 Providing proper system documentatiuon.

 Recovery of lost information.
 Assisting with maintenance.
 Facility of software reuse.
 Discovering unexpected flaws or faults.
Used of Software Reverse Engineering –
 Software Reverse Engineering is used in software design, reverse engineering enables the
developer or programmer to add new features to the existing software with or without knowing
the source code.
 Reverse engineering is also useful in software testing, it helps the testers to study the virus and
other malware code .

Software Re-engineering
When we need to update the software to keep it to the current market, without impacting its functionality,
it is called software re-engineering. It is a thorough process where the design of software is changed and
programs are re-written.
Legacy software cannot keep tuning with the latest technology available in the market. As the hardware
become obsolete, updating of software becomes a headache. Even if software grows old with time, its
functionality does not.
For example, initially Unix was developed in assembly language. When language C came into existence,
Unix was re-engineered in C, because working in assembly language was difficult.
Other than this, sometimes programmers notice that few parts of software need more maintenance than
others and they also need re-engineering.
Re-Engineering Process
 Decide what to re-engineer. Is it whole software or a part of it?

 Perform Reverse Engineering, in order to obtain specifications of existing software.
 Restructure Program if required. For example, changing function-oriented programs into object-oriented
programs.
 Re-structure data as required.
 Apply Forward engineering concepts in order to get re-engineered software. Component reusability

Configuration Management (SCM)
A software is a collection of items like programs, data, documents etc. that can be changed easily.
Throughout the software development cycle the software design documents, software code or software
requirements document etc. are changed often and it is very important that the changes done in software
are done in a controlled manner.
Software Configuration Management is defined as a process to systematically manage, organize, and control
the changes in the documents, codes, and other entities during the Software Development Life Cycle. It is
abbreviated as the SCM process in software engineering. The primary goal is to increase productivity with
minimal mistakes.
As per IEEE Software Configuration Management is:
“SCM is the process of identifying and defining the items in the system, controlling the changes of
these items throughout their life cycle, recording and reporting the status of items and change
requests, and verifying the completeness and correctness of items.
During SCM the changes can be made in software and documents like Test Cases, Test Plan, Design Documents,
SRS etc. during the software development life cycle.

The SCM system has the following advantages:
 Reduced redundant work.

 Effective management of simultaneous updates.
 Avoids configuration-related problems.
 Facilitates team coordination.
 Helps in building management; managing tools used in builds.
 Defect tracking: It ensures that every defect has traceability back to its source.

Notes Unit 4 SE - ETCS 303

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Notes Unit 4 SE - ETCS 303

Uploaded by

Copyright:

Available Formats

Unit – 4

Software Testing Introduction

Software testing is a process of identifying the correctness of a software by

Software testing provides an independent view and objective of the software

Testing is mandatory because it will be a dangerous situation if the software

Who does Testing?

Software Engineering (ETCS 303) By Dr Shafiqul Abidin, HMRITM, (GGSIPU), Delhi

Verification & Validation

Software Engineering (ETCS 303) By Dr Shafiqul Abidin, HMRITM, (GGSIPU), Delhi

Validation: "Are we building the right product?"

Verification addresses the Validation addresses the concern:

Ensures that the software Ensures that the functionalities

Verification takes place first Validation occurs after

Done by developers. Done by testers.

It has static activities, as it It has dynamic activities, as it

It is an objective process and It is a subjective process and

Software Engineering (ETCS 303) By Dr Shafiqul Abidin, HMRITM, (GGSIPU), Delhi

Functional Testing Techniques:

There are two major Functional Testing techniques as shown below:

Software Engineering (ETCS 303) By Dr Shafiqul Abidin, HMRITM, (GGSIPU), Delhi

The other major Functional Testing techniques include:

Black Box Testing

Black box testing is a technique of software testing which examines the

Software Engineering (ETCS 303) By Dr Shafiqul Abidin, HMRITM, (GGSIPU), Delhi

 The black box test is based on the specification of requirements, so it is

Software Engineering (ETCS 303) By Dr Shafiqul Abidin, HMRITM, (GGSIPU), Delhi

Techniques Used in Black Box Testing

Software Engineering (ETCS 303) By Dr Shafiqul Abidin, HMRITM, (GGSIPU), Delhi

Decision table technique in Black box testing

Let's understand it by an example:

Software Engineering (ETCS 303) By Dr Shafiqul Abidin, HMRITM, (GGSIPU), Delhi

Number of possible conditions = 2^ Number of Values of the second condition

Decision Table Testing

Example 1: Decision Base Table for Login Screen

Let's create a decision table for a login screen.

Software Engineering (ETCS 303) By Dr Shafiqul Abidin, HMRITM, (GGSIPU), Delhi

Conditions Rule 1 Rule 2 Rule 3 Rule 4

Advantage of decision table technique:

Boundary Value Analysis

Software Engineering (ETCS 303) By Dr Shafiqul Abidin, HMRITM, (GGSIPU), Delhi

Let's understand via practical:

Software Engineering (ETCS 303) By Dr Shafiqul Abidin, HMRITM, (GGSIPU), Delhi

Cause and Effect Graph in Black box Testing

Notations used in the Cause-Effect Graph

Software Engineering (ETCS 303) By Dr Shafiqul Abidin, HMRITM, (GGSIPU), Delhi

OR - If any cause from C1 and C2 is true, then effect E1 will be true.

NOT - If cause C1 is false, then effect E1 will be true.

Mutually Exclusive - When only one cause is true.

Let's try to understand this technique with some examples:

Software Engineering (ETCS 303) By Dr Shafiqul Abidin, HMRITM, (GGSIPU), Delhi

 E1 - Update made (C1 OR C2) AND C3

Where AND, OR, NOT are the logical gates.

Software Engineering (ETCS 303) By Dr Shafiqul Abidin, HMRITM, (GGSIPU), Delhi

Summary of the steps:

 Draw the circles for effects and Causes.

Software Engineering (ETCS 303) By Dr Shafiqul Abidin, HMRITM, (GGSIPU), Delhi

Steps to proceed on Cause-Effect Diagram:

Secondly: Build up a cause-effect graph

Third: Convert cause-effect graph into a decision table

Let’s draw a cause and effect graph based on a situation

 The first character must be an “A” or a “B”.

The effects (results) for this situation are

Software Engineering (ETCS 303) By Dr Shafiqul Abidin, HMRITM, (GGSIPU), Delhi

In this example, let‟s start with Effect E1.