SOFTWARE TESTING
AND QUALITY
ASSURANCE
MODULE 2
MODULE 2-Testing Techniques
► Dynamic Testing
►White box Testing Techniques
►Black Box testing
► Validation Activities
► Regression Testing
Topics covered in dynamic Testing
► Dynamic Testing: Black Box testing: boundary value
analysis, equivalence class testing, state table based
testing, cause-effect graphing based testing, error
guessing.
STATIC TESTING
Static testing is software testing technique where testing is carried out without executing
the code. This type of testing comes under VerificationThe two main types of static testing
techniques are
► Manual examinations: Manual examinations include analysis of code done
manually, also known as REVIEWS.
► Automated analysis using tools: Automated analysis are basically static
analysis which is done using tools.
DYNAMIC TESTING
► Dynamic testing is software testing technique where testing is carried out with executing
the code. This type of testing comes under Validation.
► Dynamic Testing Techniques
The Dynamic Testing Techniques are broadly classified into two categories. They are:
⮚ Functional Testing
⮚ Non-Functional Testing
► Levels of Dynamic Testing
There are various levels of Dynamic Testing Techniques. They are:
► Unit Testing
► Integration Testing
► System Testing
Black box testing
► BLACK BOX TESTING, also known as Behavioral Testing, is a
software testing method in which the internal
structure/design/implementation of the item being tested is not known to the
tester. These tests can be functional or non-functional, though usually
functional.
► This method is named so because the software program, in the eyes of the tester, is like a black box; inside
which one cannot see. This method attempts to find errors in the following categories:
► Incorrect or missing functions
► Interface errors
► Errors in data structures or external database access
► Behavior or performance errors
► Initialization and termination errors
White box testing
► WHITE BOX TESTING (also known as Clear Box Testing, Open Box Testing, Glass Box
Testing, Transparent Box Testing, Code-Based Testing or Structural Testing) is a
software testing method in which the internal structure/design/implementation of the item being
tested is known to the tester.
► White Box Testing method is applicable to the following levels of software testing:
► Unit Testing: For testing paths within a unit.
► Integration Testing: For testing paths between units.
► System Testing: For testing paths between subsystems.
► Grey box testing (white+ black)—called maintenance testing
► Yellow box testing(warning will be given..if u do this, this might happen)
► Red box testing(protocol testing,network testing)-error is tested
► Green box testing(check whether it is environmental friendly)
Dynamic Testing-Definition
► Dynamic testing is a software testing process that is performed in an
environment where the code is actually executed. This type of testing is used,
by the team, to check the functional behavior of the software and to verify its
conformance with the user expectations and requirements
Features of Dynamic Testing:
The importance of the software testing techniques can be attained by understanding its
features and various other components. Therefore, listed below are some of the features
of dynamic testing.
► It helps detect defects in the software.
► Determines the quality attributes of the code.
► Assists the team in identifying bugs.
► Testing is done by executing the program.
► Helps the team in validating the consistency of the software product.
Unlike other testing techniques, dynamic testing is performed directly on the software
product.
► It is a more formal approach for test case identification, coverage consideration, test
execution, and reporting.
► Dynamic testing involves both functional and non-functional testing.
► It is executed during the validation stage of the software testing.
► Unlike static testing, in dynamic testing, the team executes the software’s code to get
expected results.
Reasons for performing dynamic testing
► It is an effective method for measuring the impact of various environmental stresses on the software
product, such as hardware, network, and more.
► Another major reason for implementing dynamic testing is that it helps the team to find errors and
defects in the software.
► During this process, the team executes the code to test the performance of the software product in a
run-time environment.
Reasons for performing dynamic testing
► It is executed to check the functional behavior of the software.
► Assists the team in evaluating and validating the output with the expected output.
► Most importantly, it helps the team to validate the overall performance of the software
Techniques of Dynamic Testing:
► To execute the process of dynamic testing, software testers use two different
techniques- functional and non-functional testing. These help them to
efficiently test system while determining its compliance with the stated
requirements. Both of these testing techniques play a significant role in
validating the performance and quality of the software, and are hence defined
below:
► Functional Testing: Dynamic tests involving functional testing technique
allows the team to verify the compliance of software product’s features and
components with the functional specifications, stated before the
commencement of the testing process. Moreover, this technique involves
execution of functional test cases, which helps them to get accurate and
expected results.
► Functional testing is further performed with the assistance of various testing types,
which play an extremely crucial role in determining the performance and functionality
of the software. These are:
► Unit Testing.
► Integration Testing.
► System Testing.
► Acceptance Testing.
► Non-Functional Testing: Another beneficial dynamic testing technique,
non-functional testing is implemented by the team to validate the non-functional requirements
of the software product. The focus of this testing technique is to test the non-functional
attribute and components of the software, such as robustness of the software system, memory
leaks, performance, and more. Additionally,
► this type of testing is performed at the test level, with the assistance of following
testing types:
► Performance Testing.
► Recovery Testing.
► Security Testing.
► Usability Testing.
► Compatibility Testing.
Types of Dynamic Testing:
As per their utility, different techniques of dynamic testing are employed by the team for various scenarios. Few of
these techniques are:
► Unit Testing: Generally run by software developers, unit testing involves testing of small fragments of
the source code such as operational procedures or individual functions, independent of each other. One
particular benefit of this approach is that it allows the easy incorporation of changes at a later date.
► Integration testing: Generally run by software developers, unit testing involves testing of small
fragments of the source code such as operational procedures or individual functions, independent of
each other. One particular benefit of this approach is that it allows the easy incorporation of changes at a
later date.
► System test: A form of Black box strategy, system testing is done to evaluate the
compliance of the system performance with the specifications mentioned in the owner
manual. It includes GUI testing.
► Acceptance test: Acceptance testing is conducted to determine if the requirements of the
product specifications are being met as per the contractual obligations at the site. It has
variants by the name of Alpha beta tests, Contract and regulation acceptance testing,
physical tests, etc.
Process of Dynamic Testing:
Once the strategy as well as the techniques of test execution are decided, the team moves on to performing the
activity of testing, which usually follows a set process. This process helps monitor each step of testing and helps
the team to identify any deviances from the strategy or plans. The process of dynamic testing is as follows:
► Test Case Design: During this initial stage of the process, team works together to design test cases, which
are based on the scope of testing as well as the requirements established before the beginning of the project.
► Environment Setup: The purpose of the team during this stage of the process is to prepare and setup the
test environment. In dynamic testing, the test environment should be similar to the production environment,
as the testing is executed directly on the product.
► Test Execution: Finally, the test cases prepared during the initial stage of the process are executed by the
team here.
► Analysis & Evaluation: The results derived from the testing is analysed and evaluated, and then
compared with the expected results.
► Reporting: At the end of the process any bugs, defects, deviations, or irregularities, between the actual
result and expected result, are recorded and reported to the person concerned. It is the responsibility of
this individual to rectify the issue and ensure the quality of the product.
Boundary Value Analysis
► Boundary testing is the process of testing between extreme ends or boundaries between
partitions of the input values. So these extreme ends like Start- End, Lower- Upper, Maximum-
Minimum, Just Inside-Just Outside values are called boundary values and the testing is called
"boundary testing“
Let’s take same above example to understand the Boundary value analysis concept:
► One test case for exact boundary values of input domains each means 1 and 100.
► One test case for just below boundary value of input domains each means 0 and 99.
► One test case for just above boundary values of input domains each means 2 and 101.
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.
Suppose, if the input is a set of values between A and B, then design test cases for A, A+1, A-1 and B, B+1, B-1.
Example:
Why go with Boundary Value Analysis?
Consider an example where a developer writes code for an amount text field which will accept and transfer values only from 100 to
5000. The test engineer checks it by entering 99 into the amount text field and then clicks on the transfer button. It will show an error
message as 99 is an invalid test case, because the boundary values are already set as 100 and 5000. Since 99 is less than 100, the text
field will not transfer the amount.
The valid and invalid test cases are listed below.
Valid Test Cases
1.Enter the value 100 which is min value.
2.Enter the value 101 which is min+1 value.
3.Enter the value 4999 which is max-1 value.
4.Enter the value 5000 which is max value.
Invalid Test Cases
5.Enter the value 99 which is min-1 value.
6.Enter the value 5001 which is max+1 value
Equivalence Partioning
► Equivalence
partitioning or equivalence class partitioning (E
CP) is a software testing technique that divides the
input data of a software unit
into partitions of equivalent data from which test
cases can be derived.
► Eq:A program reads three numbers A,B,C with
range[1,50] and print the largest
number.Design test cases for this program
using equivalence class testing techniques.
First we partition the domain of input as valid input values and invalid
values. so we get following classes -
I1I1 = { <A,B,C> : 1 ≤ A ≤ 50 }
I2I2 = { <A,B,C> : 1 ≤ B ≤ 50}
I3I3 = { <A,B,C> : 1 ≤ C ≤ 50}
I4I4 = { <A,B,C> : A < 1}
I5I5 = { <A,B,C> : A > 50}
I6I6 = { <A,B,C> : B < 1}
I7I7 = { <A,B,C> : B > 50}
I8I8 = { <A,B,C> : C < 1 }
I9I9 = { <A,B,C> : C > 50}
► Now test cases can be designed from the above derived classes taking
one case from each class such that the test case covers maximum valid
input classes and seperate test cases for each invalid class.
Test case id A B C Expected Result Classes covered
test cases
1 13 25 36 C is greater I1,I2,I3I1,I2,I3
2 0 13 45 invalid input I4I4
3 51 34 17 invalid input I5I5
4 29 0 18 invalid input I6I6
5 36 53 32 invalid input I7I7
6 27 42 0 invalid input I8I8
7 33 21 51 invalid input I9
Another set of equivalence classes based on some possibilities of 3 integers A, B, C.
I1I1 = { < A,B,C > : A>B, A>C }
I2I2 = { < A,B,C > : B>A , B>C }
I3I3 = { < A,B,C > : C>A , C>B }
I4I4 = { < A,B,C > : A = B, A + C}
I5I5 = { < A,B,C > : B = C, A + B }
I6I6 = { < A,B,C > : A = C, C = B}
I7I7 = { < A,B,C > : A = B = C }
Test case ID A B C Expected Classes
Result covered test
cases
1 25 13 13 A is greater I1,I5I1,I5
2 25 40 25 B is greater I2,I6I2,I6
3 24 24 37 C is greater I3,I4I3,I4
4 25 25 25 All are equal I7I7
CAUSE EFFECT FLOW TESTING
Steps for drawing cause-Effect Diagram:
► Step 1 : Identify and Define the Effect
► Step 2 : Fill in the Effect Box and Draw the Spine
► Step 3: Identify the main causes contributing to the effect being
studied.
► Step 4 : For each major branch, identify other specific factors
which may be the causes of the EFFECT.
► Step 5 : Categorize relative causes and provide detailed levels of
causes.
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.
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
Error Guessing
► Error Guessing is a Software Testing technique on guessing the error which can prevail in the code. It is an
experience-based testing technique where the Test Analyst uses his/her experience to guess the problematic
areas of the application. This technique necessarily requires skilled and experienced testers
Drawbacks of Error Guessing?
► The main drawback of error guessing is it depends on the experience of the tester, who is deploying it. On the
other hand, if several testers contribute to the process then the outcome can be more effective.
► The defect and failure list can be used as the basis of a set of tests and this systematic approach is known as
fault attack.
White box Testing Techniques
► WHITE BOX TESTING is testing a software solution's internal structure,
design, and coding. It is also known as Clear Box testing, Open Box testing,
Structural testing, Transparent Box testing, Code-Based testing, and Glass Box
testing. It is usually performed by developers.
What do you verify in White Box
Testing?
► White box testing involves the testing of the software code for the
following:
► Internal security holes
► Broken or poorly structured paths in the coding processes
► The flow of specific inputs through the code
► Expected output
► The functionality of conditional loops
► Testing of each statement, object, and function on an individual basis
How do you perform White Box
Testing?
► To give you a simplified explanation of white box testing, we have
divided it into two basic steps. This is what testers do when testing an
application using the white box testing technique:
► STEP 1) UNDERSTAND THE SOURCE CODE
► Step 2) CREATE TEST CASES AND EXECUTE
WhiteBox Testing Example
Printme
► Consider (int a, int b)
the following { of code
piece
int result = a+ b;
If (result> 0)
Print ("Positive", result)
Else
Print ("Negative", result)
} ----------- End of the source code
► The goal of WhiteBox testing in software engineering is to verify
all the decision branches, loops, statements in the code.
To exercise the statements in the above code, WhiteBox test cases
would be
► A = 1, B = 1
► A = -1, B = -3
White Box Testing Techniques
► A major White box testing technique is Code Coverage analysis.
► Code Coverage analysis eliminates gaps in a Test Case suite. It
identifies areas of a program that are not exercised by a set of test
cases. Once gaps are identified, you create test cases to verify untested
parts of the code, thereby increasing the quality of the software product
► coverage analysis techniques a box tester can use:
► Statement Coverage:- This technique requires every possible
statement in the code to be tested at least once during the testing
process of software engineering.
► Branch Coverage - This technique checks every possible path (if-else
and other conditional loops) of a software application.
Following are important WhiteBox Testing
Techniques:Statement Coverage
► Decision Coverage
► Branch Coverage
► Condition Coverage
► Multiple Condition Coverage
► Finite State Machine Coverage
► Path Coverage
► Control flow testing
► Data flow testing
Advantages of White Box Testing
► Code optimization by finding hidden errors.
► White box tests cases can be easily automated.
► Testing is more thorough as all code paths are usually covered.
► Testing can start early in SDLC even if GUI is not available.
Disadvantages of WhiteBox
Testing
► White box testing can be quite complex and expensive.
► Developers who usually execute white box test cases detest it. The white box testing by developers is not
detailed can lead to production errors.
► White box testing requires professional resources, with a detailed understanding of programming and
implementation.
► White-box testing is time-consuming, bigger programming applications take the time to test fully.
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
► Mutation testing (or mutation analysis or program mutation) is used
to design new software tests and evaluate the quality of existing
software tests. ... Each mutated version is called a mutant and tests
detect and reject mutants by causing the behavior of the original
version to differ from the mutant.
► REGRESSION TESTING is defined as a type of software testing to confirm
that a recent program or code change has not adversely affected existing
features. Regression Testing is nothing but a full or partial selection of already
executed test cases which are re-executed to ensure existing functionalities work
fine.
► Progressive testing also known as incremental testing is used to test modules
one after the other.
Need of Regression Testing
► The Need of Regression Testing mainly arises whenever there is requirement to
change the code and we need to test whether the modified code affects the other
part of software application or not. Moreover, regression testing is needed, when
a new feature is added to the software application and for defect fixing as well as
performance issue fixing.
Regression Testing Steps:
► Regression tests are the ideal cases of automation which results in better Return On Investment
(ROI).
► Select the Tests for Regression.
► Choose the apt tool and automate the Regression Tests
► Verify applications with Checkpoints
► Manage Regression Tests/update when required
► Schedule the tests
► Integrate with the builds
► Analyze the results
Types of Regression Tests:
► Unit Regression Testing
► Regional Regression Testing
► Full Regression Testing
Regression Testing Techniques
► Retest all
Running all test cases in the test suite after any change, which is thorough but can be time-
consuming.
► Test Case Selection :Choosing a subset of test cases that are most likely to be affected by
the changes, improving efficiency compared to retesting all.
► Test Prioritization : Ordering test cases based on their priority or potential impact,
allowing for focused testing on critical areas.
Parameters Regression Testing Retesting
Known As Regression testing is known as a generic testing. Retesting is known as planned testing.
Retesting is used to ensure the test cases which failed in last
Regression testing is to ensure that changes have not
Objective execution are fixed. It is performed on a specific part of the
affected the unchanged part of product.
system to verify that a specific defect has been fixed.
Regression testing is used for past test cases. It is performed
on the entire system or a subset of the system to ensure that
Scope Retesting is used only for failed test cases.
all previously tested functionality is still working as
expected
Defect Verification Defect verification is not coming under regression testing. Defect verification is coming under retesting.
Regression testing can be done either in automation or
Manual/ Automation Testing Retesting can not be automated.
manual testing.
Regression testing has lower priority than retesting testing
Priority Retesting has higher priority than regression testing.
but in some cases it can be done in parallel with retesting.
Test Cases Executed Passed test cases can be executed during regression testing. Only failed test cases are re-executed during retesting.
Parameters Regression Testing Retesting
Test Case Automation During regression testing test cases can be automated. During retesting test cases can't be automated.
It takes more time as it explores the whole application to It takes less time as it focuses only on the exploration of a
Time
uncover the bugs. certain defect of the product.
Testing for regression is done to look for unanticipated side To ensure the functioning of original problem as expected
Need
effects. retesting is carried out.
Regression testing is only performed after a code
Retesting is performed in the same environment and with the
When to Perform? modification, in case of implementation of a new feature, or
same data, but a new build is used.
an enhancement.
Test cases are obtained from the document specification and Test cases are not obtained beforehand but only after the start
Source of Test Cases
bug reports. of testing.
