Chapter - 2

Software Testing Strategies and Techniques

Testability - Characteristics lead to testable software.

Test characteristics Test Case Design for Desktop, Mobile,

Web application using Excel

White Box Testing - Basis path testing, Control Structure

Testing.

Black Box Testing- Boundary Value Analysis, Equivalence

partitioning.

Differences between BBT & WBT

• Testability - Characteristics lead to testable software
• Five Characteristics to Build Testability in Software
• Adding Simplicity
• Simplicity means creating the most straightforward possible solutions to the
problems at hand. Reducing the complexity of a feature to deliver only the required
value helps testing minimize the scope of functionality that needs to be covered.
• Never be afraid to ask about removing complexity from business requirements; less
is more in this situation. As part of the definition of “done”, we need to have
expected results in every story. If that is not feasible, we need to at least have a clear
idea of customer expectations.
• Improve Observability
• Observing the software and understanding different patterns gives us a tremendous
advantage to catch gaps or errors. Exploratory Testing can improve observability.
Sometimes, we need to learn from our applications; observing is core to exploring
multiple behaviors and paths while testing.
• Improving log files and tracking allows us to monitor system events and recreate
problems, an additional benefit of enhancing the ongoing supportability.
• Control
• Control is critical for testability, particularly so if required to perform any test automation.
Cleanly controlling the functionality to manage the state changes within the system in a
deterministic way is valuable to any testing efforts and is a basic element of a test
automation strategy.
• I suggest focusing on what we can expect (expected results). A simple approach:
grabbing customer-centric scenarios and identifying specific outcomes. This way, we can do
test automation. Otherwise, automating something unexpected or unpredictable is chaotic.

• Be Knowledgeable
• As testers, we must be subject matter experts on the application, take advantage of that
learning or new user experience, and collaborate. It is crucial to share the knowledge with the
rest of the team and continuously learn from others. This is a never-ending journey.
• Involving testers brings a wealth of testing knowledge and context to any software discussion.
Team members must work together to understand the essential quality attributes, critical
paths, core components, and associated risks on a design that allows the team to mitigate
those risks in the most effective way.
• Testing Stability​
• It is tough to test a system with functional variability in high levels of
operational faults. Nothing hinders testing like an unstable system. We cannot
create automation test scripts or Performance test scripts with applications
continuously changing or failing.​
• Stability can be tricky. Unstable systems can destroy the application’s
reputation and result in financial loss. Therefore, it is essential to get a stable
version of the application to create our tests, before starting any
test automation.​
• Characteristics of Software Test
Each test has its own characteristics. The following points, however, should be
noted.
• High probability of detecting errors:
To detect maximum errors, the tester should understand the software
thoroughly and try to find the possible ways in which the software can fail.
For example, in a program to divide two numbers, the possible way in which
the program can fail is when 2 and 0 are given as inputs and 2 is to be divided
by 0. In this case, a set of tests should be developed that can demonstrate an
error in the division operator.
• No redundancy:
Resources and testing time are limited in software development process.
Thus, it is not beneficial to develop several tests, which have the same
intended purpose. Every test should have a distinct purpose.
• Choose the most appropriate test:
There can be different tests that have the same intent but due to certain
limitations such as time and resource constraint, only few of them are used.
In such a case, the tests, which are likely to find more number of errors,
should be considered.
• Moderate:
• test is considered good if it is neither too simple, nor too complex. Many
tests can be combined to form one test case. However this can increase the
complexity and leave many errors undetected. Hence, all tests should be
performed separately.
• What are the different techniques of Software Testing?

• Black Box Testing is a software testing method in which the internal structure/
design/ implementation of the item being tested is not known to the tester

• White Box Testing is a software testing method in which the internal structure/
design/ implementation of the item being tested is known to the tester.
Black Box Testing White Box Testing

It is a way of software testing in which the It is a way of testing the software in which
internal structure or the program or the the tester has knowledge about the internal
code is hidden and nothing is known about structure or the code or the program of the
it. software.

It is mostly done by software testers. It is mostly done by software developers.

No knowledge of implementation is needed. Knowledge of implementation is required.

It can be referred as outer or external It is the inner or the internal software

software testing. testing.

It is functional test of the software. It is structural test of the software.

This testing can be initiated on the basis This type of testing of software is started after
of requirement specifications document.​ detail design document.​

No knowledge of programming is required.​ It is mandatory to have knowledge

of programming.​
It is the behavior testing of the software.​ It is the logic testing of the software.​
It is applicable to the higher levels of testing of It is generally applicable to the lower levels of
software.​ software testing.​
It is also called closed testing.​ It is also called as clear box testing.​
It is least time consuming.​ It is most time consuming.​
It is not suitable or preferred for algorithm testing.​ It is suitable for algorithm testing.​

Can be done by trial and error ways and methods.​ Data domains along with inner or
internal boundaries can be better tested.​
Example: search something on google by using Example: by input to check and verify loops​
keywords​
• Working process of white box testing:
• Input: Requirements, Functional specifications, design documents, source code.
• Processing: Performing risk analysis for guiding through the entire process.
• Proper test planning: Designing test cases so as to cover entire code. Execute
rinse-repeat until error-free software is reached. Also, the results are
communicated.
• Output: Preparing final report of the entire testing process.

• White Box Testing techniques:

 Statement coverage
 Branch Coverage
 Condition Coverage
 Multiple Condition Coverage
 Basis Path Testing
 Loop Testing
• White Box Testing techniques:
1. Basis Path Testing:
Basis Path Testing is a white-box testing technique based on the control structure
of a program or a module. Using this structure, a control flow graph is prepared
and the various possible paths present in the graph are executed as a part of
testing. Therefore, by definition,
Basis path testing is a technique of selecting the paths in the control flow graph
, that provide a basis set of execution paths through the program or module.
Since this testing is based on the control structure of the program, it requires
complete knowledge of the program’s structure.
To design test cases using this technique, four steps are followed :
• Construct the Control Flow Graph
• Compute the Cyclomatic Complexity of the Graph
• Identify the Independent Paths
• Design Test cases from Independent Paths
Let’s understand each step one by one.
1. Control Flow Graph –
A control flow graph (or simply, flow graph) is a directed graph which represents the
control structure of a program or module. A control flow graph (V, E) has V number of
nodes/vertices and E number of edges in it. A control graph can also have :
• Junction Node – a node with more than one arrow entering it.
• Decision Node – a node with more then one arrow leaving it.
• Region – area bounded by edges and nodes (area outside the graph is also counted as a
region.).
• Below are the notations used while constructing a flow graph :
• Sequential Statements

• If – Then – Else –
• While – Do
• Cyclomatic Complexity –
The cyclomatic complexity V(G) is said to be a measure of the logical
complexity of a program. It can be calculated using three different formulae :
• 1. Formula based on edges and nodes
• V(G) = e - n + 2*P
• Where,
e is number of edges,
n is number of vertices,
P is number of connected components.
• For example, consider first graph given above
• where, e = 4, n = 4 and p = 1

So,
Cyclomatic complexity V(G)
= 4 - 4 + 2 * 1
= 2
2.Formula based on Decision Nodes :
V(G) = d + P
where,
d is number of decision nodes,
P is number of connected nodes.
For example, consider first graph given above,
where, d = 1 and p = 1
So,
Cyclomatic Complexity V(G)
= 1 + 1
= 2
3. Formula based on Regions :V(G) = number of regions in the graph
For example, consider first graph given above,
Cyclomatic complexity V(G)
= 1 (for Region 1) + 1 (for Region 2)
= 2
• Example 2
V(G) = 4 (Using any of the above formulae)
No of independent paths = 4
• #P1: 1 – 2 – 4 – 7 – 8
• #P2: 1 – 2 – 3 – 5 – 7 – 8
• #P3: 1 – 2 – 3 – 6 – 7 – 8
• #P4: 1 – 2 – 4 – 7 – 1 – . . . – 7 – 8
• Control Loop Testing:
• Loops are widely used and these are fundamental to many algorithms hence, their
testing is very important. Errors often occur at the beginnings and ends of loops.

• Simple loops: For simple loops of size n, test cases are designed that:
• Skip the loop entirely
• Only one pass through the loop
• 2 passes
• m passes, where m < n
• n-1 ans n+1 passes
• Nested loops: For nested loops, all the loops are set to their minimum count and
we start from the innermost loop. Simple loop tests are conducted for the
innermost loop and this is worked outwards till all the loops have been tested.
• Concatenated loops: Independent loops, one after another. Simple loop tests
are applied for each.
If they’re not independent, treat them like nesting.
• Black Box Testing Techniques
Black box testing is a type of software testing in which the
functionality of the software is not known. The testing is done
without the internal knowledge of the products.
Black box testing can be done in following ways:
1. Syntax Driven Testing
2. Equivalence partitioning
3. Boundary value analysis
4. Cause effect Graphing
5. Requirement based testing
6. Compatibility testing
• Equivalence Partitioning –
• It is often seen that many type of inputs work similarly so instead of
giving all of them separately we can group them together and test
only one input of each group.
• The idea is to partition the input domain of the system into a
number of equivalence classes such that each member of class
works in a similar way, i.e., if a test case in one class results in some
error, other members of class would also result into same error.
• The technique involves two steps:
1. Identification of equivalence class – Partition any input domain
into minimum two sets: valid values and invalid values. For example,
if the valid range is 0 to 100 then select one valid input like 49 and
one invalid like 104.
2. Generating test cases –
• (i) To each valid and invalid class of input assign unique identification
number.
(ii) Write test case covering all valid and invalid test case considering that
no two invalid inputs mask each other.
• To calculate the square root of a number, the equivalence classes will be:
(a) Valid inputs:
• Whole number which is a perfect square- output will be an integer.
• Whole number which is not a perfect square- output will be
decimal number.
• Positive decimals
• (b) Invalid inputs:
• Negative numbers(integer or decimal).
• Characters other that numbers like “a”,”!”,”;”,etc.
• 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.
• Example
• 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.
• Test Case Design
• A test case is a set of actions performed on a system to determine if it
satisfies software requirements and functions correctly. The purpose of a
test case is to determine if different features within a system are
performing as expected and to confirm that the system satisfies all
related standards, guidelines and customer requirements.
• A test case template is a document that comes under one of the
test artifacts, which allows testers to develop the test cases for a
particular test scenario in order to verify whether the features of an
application are working as intended or not. Test cases are the set of
positive and negative executable steps of a test scenario which has a set
of pre-conditions, test data, expected results, post-conditions, and actual
results.
• Test Scenario: Test Scenario gives the idea of what we have to test. Test
Scenario is like a high-level test case. Learn more on
how to write test scenario here.
• For example: Verify the login functionality of the Gmail account.
Test Case Template
• Test case ID: Unique ID is required for each test case. Follow some
conventions to indicate the types of the test. For Example, ‘TC_UI_1’
indicating ‘user interface test case #1
• Test priority (Low/Medium/High): This is very useful during test execution.
Test priorities for business rules and functional test cases can be medium or
higher, whereas minor user interface cases can be of a low priority. Testing
priorities should always be set by the reviewer.
• Module Name: Mention the name of the main module or the sub-module.
• Test Designed By Name of the Tester.
• Test Designed Date: Date when it was written.
• Test Executed By Name of the Tester who executed this test. To be filled only
after test execution.
• Test Execution Date: Date when the test was executed.
• Test Title/Name: Test case title. For example, verify the login page with a valid username
and password.
• Test Summary/Description: Describe the test objective in brief.
• Pre-conditions: Any prerequisite that must be fulfilled before the execution of this
test case. List all the pre-conditions in order to execute this test case successfully.
• Dependencies: Mention any dependencies on other test cases or test requirements.
• Test Steps: List all the test execution steps in detail. Write test steps in the order in
which they should be executed. Make sure to provide as many details as you can.
• Test Data: Use of test data as an input for this test case. You can provide different data sets
with exact values to be used as an input.
• Expected Result: What should be the system output after test execution? Describe the
expected result in detail including the message/error that should be displayed on the
screen.
• Post-condition: What should be the state of the system after executing this
test case?
• Actual result: The actual test result should be filled after test execution.
Describe the system behavior after test execution.
• Status (Pass/Fail): If the actual result is not as per the expected result, then
mark this test as failed. Otherwise, update it as passed.
• Notes/Comments/Questions: If there are any special conditions to support
the above fields, which can’t be described above or if there are any
questions related to expected or actual results then mention them here.
• Example
• Let’s assume that you are testing the login functionality of any web
application, say Facebook.
• Please Note Examples of Test Scenario and Test Cases
of
• Desktop Application, Web Application and Web
Application will be given in separate file