Software Testing

Phases of Software Project

A software project is made up of a series of phases. Software projects comprise the following phases.
 Requirements gathering and analysis
 Planning
 Design
 Development or coding
 Testing
 Deployment and maintenance
1.1. Requirements Gathering and Analysis
During requirements gathering, the specific requirements of the software to be built are gathered and
documented. If the software is bespoke software, then there is a single customer who can give these
requirements. If the product is general-purpose software, then a product marketing team within the software
product organization specifies the requirements. It is important to ensure that the right requirements are
captured at every stage. The requirements get documented in the form of a System Requirements
Specification (SRS) document. This document act as a bridge between the customer and the designers
chartered to build the product.
1.2. Planning
The purpose of the planning phase is to come up with a schedule, the scope and resource requirements for a
release. A plan explains how the requirements will be met and by which time. It needs to take into account
the requirements – what will be met and what will not be met – for the current release to decide on the scope
for the project, look at resource availability, and to come out with set of milestones and release date for the
project. The planning phase is applicable for both development and testing activities. At the end of this
phase, both project plan and test plan documents are delivered.
1.3. Design
The design phase produces a representation that will be used by the following phase, the
development phase. This representation should serve two purposes. First, from this representation, it should
be possible to very that all the requirements are satisfied. Second, this representation should give sufficient
information for the development phase to proceed with the coding and implementation of the system. Design
is usually split into two levels – high-level design and low-level or a detailed design. The design step
produces the system design description (SDD) document that will be used by development teams to produce
the programs that realize the design.
1.4. Development or Coding
Design acts as a blueprint for the actual coding to proceed. This development or coding phase
comprises coding the programs in the chosen programming language. It produces the software that meets the
requirements the design was meant to satisfy. In addition to programming, this phase also involves the
creation of produce documentation.
1.5. Testing
Testing is the process of exercising the software product in pre-defined ways to check if the behavior
is the same as expected behavior. By testing the product, an organization identifies and removes as many
defects as possible before shipping it out.
1.6. Deployment and Maintenance
The product now enters the maintenance phase, wherein the product is maintained or changed to
satisfy the changes that arise from customer expectations, environmental changes, etc., Maintenance is made
up of corrective maintenance, adaptive maintenance and preventive maintenance.

Quality, Quality Assurance and Quality Control

Requirements get translated into software features, each feature being designed to meet one or more of
the requirements. For each such feature, the expected behavior is characterized by a set of test cases. Each
test case is further characterized by
1. The environment under which the test case is to be executed.
2. Inputs that should be provided for that test case;
3. How these inputs should get processed;
4. What changes should be produced in the internal state or environment; and
5. What outputs should be produced.
The actual behavior of a given software for a given test case, under a given set of inputs, in a given
environment, and in a given internal state is characterized by
1. How these inputs actually get processed;
2. What changes are actually produced in the internal state or environment; and
3. What outputs are actually produced?
If the actual behavior and the expected behavior are identical in all their characteristics, then that test
case is said to be passed. If not, the given software is said to have a defect on that test case.

Quality control attempts to build a product, test it for expected behavior after it is built, and if the
expected behavior is not the same as the actual behavior of the product, fixes the product as is necessary and
rebuilds the product. This iteration is repeated till the expected behavior of the product matches the actual
behavior for the scenarios tested. Thus quality control is defect-detection and defect-correction oriented, and
works on the product rather than on the process.

Quality assurance, on the other hand, attempts defect prevention by concentrating on the process of
producing the product rather than working on defect detection / correction after the product is built. For
example, instead of producing and then testing a program code for proper behavior by exercising the built
product, a quality assurance approach would be to first review the design before the product is built and
correct the design errors in the first place.
 Similarly, to ensure the production of a better code, a quality assurance process may mandate coding
standards to be followed by all programmers. Also, since quality assurance continues throughout the life of
the product it is everybody’s responsibility; hence it is a staff function. In contrast, the responsibility for
quality control is usually localized to a quality control team.

Table : Difference between quality assurance and quality control

Quality Assurance Quality Control
Concentrates on the process of producing the Concentrates on specific products
products
Defect-prevention oriented Defect-detection and correction oriented
Usually done throughout the life cycle Usually done after the product is built
This is usually a staff function This is usually a line function
Examples : reviews and audits Examples software testing at various levels

Testing, Verification and Validation

Testing is traditionally used to mean testing of the program code. If each phase is “tested” separately
as and when the phase is completed (or, better still, as the phase is being executed), then defects can be
detected early, thereby reducing the overall costs.
Testing is done by a set of people within a software product organization whose goal and charter is to
uncover the defects in the product before it reaches the customer. The purpose of software testing is to find
defects in a software product.
The idea of catching defects within each phase, without letting them reach the testing phase, leads us
to define two more terms – verification and validation.
The SRS document is the product of the requirements phase. To ensure that requirements are faithfully
captured, the customer verifies this document. The design phase takes the SRS document as input and maps
the requirements to a design that can drive the coding.

Differences between Verification and Validation

Verification Validation

Validation refers to the set of activities

Verification refers to the set of activities
that ensure that the software that has
that ensure software correctly
been built is traceable to customer
implements the specific function
Definition requirements.
 Verification Validation

It includes checking documents, designs, It includes testing and validating the

Focus codes, and programs. actual product.

Type of Testing Verification is the static testing. Validation is dynamic testing.

It does not include the execution of the

It includes the execution of the code.
Execution code.

Methods used in verification are Methods used in validation are Black

reviews, walkthroughs, inspections and Box Testing, White Box
Methods Used desk-checking. Testing and non-functional testing.

It checks whether the software meets the

It checks whether the software conforms
requirements and expectations of a
to specifications or not.
Purpose customer or not.

It can find the bugs in the early stage of It can only find the bugs that could not
Bug the development. be found by the verification process.

The goal of verification is application

The goal of validation is an actual
and software architecture and
product.
Goal specification.

Validation is executed on software code

Quality assurance team does verification.
Responsibility with the help of testing team.

Timing It comes before validation. It comes after verification.

It consists of checking of
It consists of execution of program and
Human or documents/files and is performed by
is performed by computer.
Computer human.

After a valid and complete specification Validation begins as soon as project

Lifecycle the verification starts. starts.

Error Focus Verification is for prevention of errors. Validation is for detection of errors.

Verification is also termed as white box Validation can be termed as black box
Another testing or static testing as work product testing or dynamic testing as work
Terminology goes through reviews. product is executed.
 Verification Validation

Verification finds about 50 to 60% of the Validation finds about 20 to 30% of the
Performance defects. defects.

Verification is based on the opinion of

Validation is based on the fact and is
reviewer and may change from person to
often stable.
Stability person.

White Box Testing

1. What is White Box Testing?

White box testing is a way of testing the external functionality of the code by examining and testing the
program code that realizes the external functionality. This is also known as clear box or glass box or open
box testing.
White box testing takes into account the program code, code structure and internal design flow. A number of
defects come about because of incorrect translation of requirements and design into program code. Some
other defects are created by programming errors and programming language idiosyncrasies. Since the
program code represents what the product actually does, testing by looking at the program code makes us
get closer to what the product is actually doing.

Types of White Box Testing

White box testing can be done for different purposes. The three main types are:
1. Unit Testing
2. Integration Testing
3. Regression Testing

Types of White Box Testing

Unit Testing
 Checks if each part or function of the application works correctly.
 Ensures the application meets design requirements during development.

Integration Testing
 Examines how different parts of the application work together.
 Done after unit testing to make sure components work well both alone and together.

Regression Testing
 Verifies that changes or updates don’t break existing functionality.
 Ensures the application still passes all existing tests after updates.

White Box Testing Techniques

White box testing is classified into “static” and “structural”.

Static Testing
Static testing is a type of testing which requires only the source code of the product, not the binaries or
executables. Static testing does not involve executing the programs on computers but involves select people
going through the code to find out whether
 the code works according to the functional requirement;
 the code has been written in accordance with the design developed earlier in the project life cycle;
 the code for any functionality has been missed out;
 the code handles errors properly

Static Testing by Humans

(i) Sometimes human can find errors that computers cannot.
(ii) By making multiple humans read and evaluate the program, we can get multiple perspectives and
therefore have more problems identified upfront than a computer could
(iii) A human evaluation of the code can compare it against the specifications or design and thus ensure that
it does what is intended to do. This may not always be possible when a computer runs a test
(iv) A human evaluation can detect many problems at one go and can even try to identify the root causes of
the problems.
(v) By making humans test the code before execution, computer resources can be saved.
(vi) A proactive method of testing like static testing minimizes the delay in identification of the problems.
(vii) Psychological point of view, finding defects later in the cycle creates immense pressure on
programmers.

There are multiple methods to achieve static testing by humans. They are as follows:
1. Desk checking of the code
2. Code walkthrough
3. Code review
4. Code inspection
Static testing by humans is done before the code is compiled and executed, some of these methods can be
viewed as process-oriented or defect prevention-oriented or quality assurance-oriented activities rather than
pure testing activities.

Desk Checking
Desk checking is a method to verify the portions of the code for correctness. Such verification is done by
comparing the code with the design or specifications to make sure that the code does what it is supposed to
do and effectively. This is the desk checking that most programmers do before compiling and executing the
code.
This method of catching and correcting errors is characterized by:
(i) No structured method or formalism to ensure completeness
(ii) No maintaining of a log or checklist
Advantages:
 This method is that the programmer who knows the code and the programming language very well is
well equipped to read and understand his or her own code
 The defects are detected and corrected with minimum time delay
Some of the disadvantages of this method of testing are as follows:
 A developer is not the best person to detect problems in his or her own code. He or she may be
tunnel vision and have blind spots to certain types of problems.
 Developers generally prefer to write new code rather than do any form of testing
 This method is essentially person-dependent and informal and thus may not work consistently across
all developers

Code Walkthrough
This method and formal inspection are group-oriented methods. Walkthroughs are less formal than
inspections. The advantage that walkthrough has over desk checking is that it brings multiple perspectives.

Formal inspection
Code inspection – also called Fagan Inspection is a method, normally with a high degree of formalism. The
focus of this method is to detect all faults, violations and other side-effects. This method increases the
number of defects detected by
1. Demanding thorough preparation before an inspection / review
2. Enlisting multiple diverse views
3. Assigning specific roles to the multiple participants
4. Going sequentially through the code in a structured manner

Combining various methods

The methods discussed above are not mutually exclusive. They need to be used in a judicious combination
to be effective in achieving the goal of finding defects early.
Formal inspections have been found very effective in catching defects early. Some of the challenges to
watch out for in conducting formal inspections are as follows.
1. These are time consuming. Since the process calls for preparation as well as formal meetings, these
can take time.
2. The logistics and scheduling can become an issue since multiple people are involved.
3. It is not always possible to go through every line of code, with several parameters and their
combinations in mind to ensure the correctness of the logic, side-effects and appropriate error
handling. It may also not be necessary to subject the entire code to formal inspection.
Portions of code can be classified on the basis of their criticality or complexity as “high”, “medium”, and
“low”. Desk checking, walkthrough, review and inspection are not only used for code but can be used for all
other deliverable in the project life cycle such as documents, binaries and media.

Static Analysis Tools

There are several static analysis tools available in the market that can reduce the manual work and perform
analysis of the code to find out errors such as those listed below.
1. Whether there are unreachable codes
2. Variables declared but not used
3. Mismatch in definition and assignment of values of variables
4. Illegal or error prone typecasting of variables
5. Use of non-portable or architecture-dependent programming constructs
6. Memory allocated but not having corresponding statements for freeing them up memory
7. Calculation of cyclomatic complexity

Structural Testing
 Structural testing takes into account the code, code structure, internal design and how they are coded.
The fundamental difference between structural testing and static testing is that in structural testing tests are
actually run by the computer on the built product, whereas in static testing, the product is tested by humans
using just the source code and not the executables or binaries.
Structural testing entails running the actual product against some pre-designed test cases to exercise as much
of the code as possible or necessary. A given portion of the code is exercised if a test case causes the
program to execute that portion of the code when running the test.
6.1. Unit / Code Functional Testing
This initial part of structural testing corresponds to some quick checks that a developer performs before
subjecting the code to more extensive code coverage testing or code complexity testing.
 The developer can perform certain obvious tests, knowing the input variables and the corresponding
expected output variables. This can be a quick test that checks out any obvious mistakes. The review
mechanism does not waste time catching obvious errors.
 For modules with complex logic or conditions, the developer can build a “debug version” of the
product by putting intermediate print statements and making sure the program is passing through the
right loops and iterations the right number of times.
 Initial test is to run the product under a debugger or an Integrated Development Environment (IDE).
These tools allow single stepping of instruction, setting break points at any function or instruction
and viewing the various system parameters or program variable values.

All the above fall more under the “debugging” category of activities than under the “testing” category of
activities.

6.2. Code Coverage Testing

Code coverage testing involves designing and executing test cases and finding out the percentage of code
that is covered by testing. The percentage of code covered by a testis found by adopting a technique called
instrumentation of code. There are specialized tools available to achieve instrumentation. Instrumentation
rebuilds the product, linking the product with a set of libraries provided by the tool vendors. The
instrumented code can monitor and keep an audit of what portions of code are covered. The tools also allow
reporting on the portions of the code that are covered frequently, so that the critical or most-often portions of
code can be identified.
Code coverage testing is made up of the following types of coverage
1. Statement Coverage
2. Path Coverage
3. Condition Coverage
4. Function Coverage
6.2.1 Statement Coverage
Program constructs in most conventional programming language can be classified as
1. Sequential control flow
2. Two-way decision statements like (if then else)
3. Multi-way decision statements like (Switch)
4. Loops like (while do, repeat until and for)

Statement coverage refers to writing test cases that execute each of the program statements. For a section of
code that consists of statements that are sequentially executed, test cases can be designed to run through
from top to bottom. First, if there are asynchronous exceptions that the code encounters, then, even if we
start a test case at the beginning of a section, the test case may not cover all the statements in that section.
Second a section of code may be entered from multiple points.
When we consider a two-way decision construct like the if statement, then to cover all the statements, we
should also cover the then and else parts of the if statement. This means we should have, for each if then
else, one test case to test the Then part and one test case to test the else part.
The multi-way decision construct such as a Switch statement can be reduced to multiple two-way if
statements. Thus, to cover all possible switch cases, there would be multiple tst cases.
Loop constructs present more variations to take care of. A loop-in various forms such as for, while, repeat
and so on – is characterized by executing a set of statements repeatedly until or while certain conditions are
met. One of the common looping errors is that the termination condition of the loops is not properly stated.
There is better statement coverage for statements within a loop, there should be test cases that,
1. Skip the loop completely, so that the situation of the termination condition being true before starting
the loop is tested.
2. Exercise the loop between once and the maximum number of times, to check all possible “normal”
operations of the loop.
3. Try covering the loop, around the “boundary” of n-that is, just below n, n, and just above n.
[ Statement Coverage = (Total statements exercised / Total number of executable statements in
program) * 100 ]
6.2.2 Path Coverage
In path coverage, we split a program into a number of distinct paths. A program can start from the beginning
and take any of the paths to its completion.
[ Path Coverage = (Total paths exercised / Total number of paths in program) * 100 ]
Path coverage provides a stronger condition of coverage than statement coverage as it relates to the various
logical paths in the program rather than just program statements.
6.2.3 Condition Coverage
The condition coverage, as defined by the formula alongside in the margin gives an indication of the
percentage of conditions covered by a set of test cases. Condition coverage is a much stronger criteria than
path coverage, which in turn is a much stronger criteria than statement coverage.
[ Condition Coverage = (Total decisions exercised / Total number of decisions in program) * 100 ]
6.2.4 Function Coverage
This is a new addition to structural testing to identify how many program functions are covered by test
cases.
The requirements of a product are mapped into functions during the design phase and each of the functions
form a logical unit. The advantages that function coverage provides over the other types of coverage are as
follows:
(i) Functions are easier to identify in a program and hence it is easier to write test cases to provide
function coverage
(ii) Since functions are at a much higher level of abstraction than code, it is easier to achieve 100
percent function coverage than 100 percent coverage in any of the earlier methods.
(iii) Functions have a more logical mapping to requirements and hence can provide a more direct
correlation to the test coverage of the product.
(iv) Functions are a means of realizing requirements, the importance of functions can be prioritized
based on the importance of the requirements they realize.
(v) Function coverage provides a natural transition to black box testing.
We can also measure how many time a given function is called. This will indicate which functions are used
most often and hence these functions become the target of any performance testing and optimization.

[Function Coverage = (Total functions exercised / Total number of functions in program) * 100]

Challenges in White Box Testing

 White box testing requires a sound knowledge of the program code and the programming language.
 Human tendency of a developer being unable to find the defects in his or her code.
 Fully tested code may not correspond to realistic scenarios.

Advantages of White Box Testing

1. Thorough Testing : White box testing is thorough as the entire code and structures are tested.
2. Code Optimization: It results in the optimization of code removing errors and helps in removing extra
lines of code.
3. Early Detection of Defects: It can start at an earlier stage as it doesn’t require any interface as in the
case of black box testing.
4. Integration with SDLC: White box testing can be easily started in Software Development Life Cycle.
5. Detection of Complex Defects: Testers can identify defects that cannot be detected through other
testing techniques.
6. Comprehensive Test Cases: Testers can create more comprehensive and effective test cases that cover
all code paths.
7. Testers can ensure that the code meets coding standards and is optimized for performance.

Disadvantages of White Box Testing

1. Programming Knowledge and Source Code Access: Testers need to have programming knowledge
and access to the source code to perform tests.
2. Overemphasis on Internal Workings: Testers may focus too much on the internal workings of the
software and may miss external issues.
3. Bias in Testing: Testers may have a biased view of the software since they are familiar with its internal
workings.
4. Test Case Overhead: Redesigning code and rewriting code needs test cases to be written again.
5. Dependency on Tester Expertise: Testers are required to have in-depth knowledge of the code and
programming language as opposed to black-box testing.
6. Inability to Detect Missing Functionalities: Missing functionalities cannot be detected as the code that
exists is tested.
7. Increased Production Errors: High chances of errors in production.

Code Complexity Testing

The different types of coverage that can be provided to test a program. Two questions that come to mind
while using this coverage are:
1. Which of the paths are independent? If two paths are not independent, then we may be able to
minimize the number of tests.
2. Is there an upper bound on the number of tests that must be run to ensure that all the statements
have been executed at least once?
Cyclomatic complexity is a metric that quantifies the complexity of a program and thus provides answers to
the above questions.
.

BLACK BOX TESTING

Black box testing is done from the customer’s viewpoint. The test engineer engaged in black box testing
only knows the set of inputs and expected outputs and is unaware of how those inputs are transformed into
outputs by the software.
Types Of Black Box Testing
The following are the several categories of black box testing:
1. Functional Testing
2. Regression Testing
3. Nonfunctional Testing (NFT)

Functional Testing
 Functional testing is defined as a type of testing that verifies that each function of the software
application works in conformance with the requirement and specification.
 This testing is not concerned with the source code of the application. Each functionality of the software
application is tested by providing appropriate test input, expecting the output, and comparing the actual
output with the expected output.
 This testing focuses on checking the user interface, APIs, database, security, client or server application,
and functionality of the Application Under Test. Functional testing can be manual or automated. It
determines the system’s software functional requirements.

Regression Testing
 Regression Testing is the process of testing the modified parts of the code and the parts that might get
affected due to the modifications to ensure that no new errors have been introduced in the software after
the modifications have been made.
 Regression means the return of something and in the software field, it refers to the return of a bug. It
ensures that the newly added code is compatible with the existing code.
 In other words, a new software update has no impact on the functionality of the software. This is carried
out after a system maintenance operation and upgrades.

Nonfunctional Testing
 Non-functional testing is a software testing technique that checks the non-functional attributes of the
system.
 Non-functional testing is defined as a type of software testing to check non-functional aspects of a
software application.
 It is designed to test the readiness of a system as per nonfunctional parameters which are never
addressed by functional testing.
 Non-functional testing is as important as functional testing.
 Non-functional testing is also known as NFT. This testing is not functional testing of software. It focuses
on the software’s performance, usability, and scalability.
Why black box testing
Black box testing helps in the overall functionality verification of the system under test. It is done based
on requirements. Black box testing addresses the stated requirements as well as implied requirements. It
encompasses the end user perspectives. It handles valid and invalid inputs.
When to do black box testing?
Black box testing activities require involvement of the testing team from the beginning of the software
project life cycle, regardless of the software development life cycle model chosen for the project.
How to do black box testing?
Black box testing exploits specifications to generate test cases in a methodical way to avoid
redundancy and to provide better coverage.
The various techniques we will discuss are as follows.
1. Requirements based testing
2. Positive and negative testing
3. Boundary value analysis
4. Decision tables
5. Equivalence partitioning
6. State based testing
7. Compatibility testing
8. User documentation testing
9. Domain testing

Requirements based testing

Validating the requirements given in the Software Requirements Specification(SRS) of the software
system.
Requirements review ensures that they are consistent, correct, complete and testable. This process
ensures that some implied requirements are converted and documented as explicit requirements, thereby
bringing better clarity to requirements and making requirements based testing more effective.
All explicit requirements (from the Systems Requirements Specification) and implied requirements
(inferred by the test team) are collected and documented as “Test Requirements Specification”(TRS).
Requirements based testing can also be conducted based on such a TRS, as it captures the testers’
perspective as well.
A requirement is subjected to multiple phases of testing-unit, component, integration and system testing.
This reference to the phase of testing can be provided in a column in the Requirements Traceability Matrix.
This column indicates when a requirement will be tested and at what phase of testing it needs to be
considered for testing.
An RTM plays a valuable ROLE IN REQUIREMENTS Based testing.
1. Regardless of the number of requirements, ideally each of the requirements has to e tested.
 2. By prioritizing the requirements, the RTM enables testers to prioritize the test cases execution to
catch defects in the high-priority area as early as possible.
3. Test conditions can be grouped to create test cases or can be represented as unique test cases.
4. Test conditions/cases can be used as inputs to arrive at a size/effort/schedule estimation of tests.

Positive Testing and Negative Testing:

Positive Testing:
 Positive Testing is testing process where the system validated against the valid input data. In this
testing tester always check for only valid set of values and check if a application behaves as
expected with its expected inputs.
 Positive Testing always tries to prove that a given product and project always meets the
requirements and specifications. Under Positive testing is test the normal day to day life scenarios
and check the expected behavior of application.
Negative Testing:
 Negative Testing is testing process where the system validated against the invalid input data.
A negative test checks if a application behaves as expected with its negative inputs.
 The main intention of this testing is to check whether software application not showing error when
supposed to & showing error when not supposed to. Such testing is to be carried out keeping
negative point of view & only execute the test cases for only invalid set of input data.
 Negative testing is a testing process to identify the inputs where system is not designed or un-
handled inputs by providing different invalid.
 The main reason behind Negative testing is to check the stability of the software application against
the influences of different variety of incorrect validation data set.

What is Boundary Testing?

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".
 The basic idea in boundary value testing is to select input variable values at their:
1. Minimum
2. Just above the minimum
3. A nominal value
4. Just below the maximum
5. Maximum
  In Boundary Testing, Equivalence Class Partitioning plays a good role
 Boundary Testing comes after the Equivalence Class Partitioning.

Equivalent Class Partitioning

Equivalent Class Partitioning is a black box technique (code is not visible to tester) which can be applied to
all levels of testing like unit, integration, system, etc. In this technique, you divide the set of test condition
into a partition that can be considered the same.
 It divides the input data of software into different equivalence data classes.
 You can apply this technique, where there is a range in input field.

Decision Table
A Decision Table Testing is a good way to deal with different combination of inputs which produce
different results. It is also called Cause-Effect Table. It provides a systematic way of stating complex
business rules, which is useful for developers as well as for testers. Decision tables can be used in test design
as they help testers to explore the effects of combinations of different inputs.
A decision table is basically an outstanding technique used in both testing and requirements management. It
is a structured exercise to prepare requirements when dealing with complex business rules..

Decision Table Testing

Advantages of Decision Table Testing

 Any complex business flow can be easily converted into the test scenarios & test cases using this
technique.
 Such type of table work iteratively, means the table created at the first iteration is used as input table for
next tables.
 It provide complete coverage of test cases which help to reduce the rework on writing test scenarios &
test cases.
 These tables guarantee that we consider every possible combination of condition values. This is known as
its “completeness property”.

Compatibility Testing
Compatibility testing is a non-functional testing conducted on the application to evaluate the application's
compatibility within different environments. It can be of two types - forward compatibility testing and
backward compatibility testing.
 Operating system Compatibility Testing - Linux , Mac OS, Windows
 Database Compatibility Testing - Oracle SQL Server
 Browser Compatibility Testing - IE , Chrome, Firefox
 Other System Software - Web server, networking/ messaging tool, etc.
Domain Testing
Domain testing is a software testing technique in which selecting a small number of test cases from a nearly
infinite group of test cases. For testing few applications, Domain specific knowledge plays a very crucial
role.
Domain testing is a type of functional testing and tests the application by feeding interesting inputs and
evaluating its outputs.
Domain - Equivalence Class Testing
Equivalence class carries its own significance when performing domain testing. Different ways of
equivalence class are:
 Intuitive equivalence
 Specified equivalence
 Subjective equivalence
 Risk-based equivalence

Advantages of Black Box Testing

 The tester does not need to have more functional knowledge or programming skills to implement the
Black Box Testing.
 It is efficient for implementing the tests in the larger system.
 Tests are executed from the user’s or client’s point of view.
 Test cases are easily reproducible.
 It is used to find the ambiguity and contradictions in the functional specifications.

Disadvantages of Black Box Testing

 There is a possibility of repeating the same tests while implementing the testing process.
 Without clear functional specifications, test cases are difficult to implement.
 It is difficult to execute the test cases because of complex inputs at different stages of testing.
 Sometimes, the reason for the test failure cannot be detected.
 Some programs in the application are not tested.
 It does not reveal the errors in the control structure.
 Working with a large sample space of inputs can be exhaustive and consumes a lot of time.

Difference between Black Box Testing and White Box Testing

Black Box Testing White Box Testing
Parameters

White Box Testing is a way of testing

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

Black box testing is mainly focused on

White box testing is mainly focused
testing the functionality of the software,
on ensuring that the internal code of
Testing ensuring that it meets the requirements
the software is correct and efficient.
objectives and specifications.

Black box testing uses methods White box testing uses methods
like equivalence partitioning , boundary like control flow testing , data flow
value analysis , and error guessing to testing and statement coverage
Testing methods create test cases. testing .

Black box testing does not require any

knowledge of the internal workings of the White box testing requires knowledge
software, and can be performed by testers of programming languages, software
who are not familiar with programming architecture and design patterns.
languages.
Knowledge level

Black box testing is generally used for White box testing is used for testing
testing the software at the functional the software at the unit level,
Scope level. integration level and system level.

Implementation of code is not needed for Code implementation is necessary for

black box testing. white box testing.
Implementation

Black Box Testing is mostly done by White Box Testing is mostly done by
software testers. software developers.
Done By

Black Box Testing can be referred to as White Box Testing is the inner or the
outer or external software testing. internal software testing.
Terminology
 Black Box Testing White Box Testing
Parameters

Black Box Testing is a functional test of White Box Testing is a structural test
the software. of the software.
Testing Level

Black Box testing can be initiated based

White Box testing of software is
on the requirement specifications
started after a detail design document.
document.
Testing Initiation

No knowledge of programming is It is mandatory to have knowledge of

required. programming.
Programming

Black Box Testing is the behavior testing White Box Testing is the logic testing
of the software. of the software.
Testing Focus

White Box Testing is generally

Black Box Testing is applicable to the
applicable to the lower levels of
higher levels of testing of software.
software testing.
Applicability

Black Box Testing is also called closed White Box Testing is also called as
Alternative testing. clear box testing.
Names

Black Box Testing is least time White Box Testing is most time
Time consuming. consuming.
Consumption

Suitable for Black Box Testing is not suitable or White Box Testing is suitable for
Algorithm preferred for algorithm testing. algorithm testing.
Testing

Data domains along with inner or

Can be done by trial and error ways and
internal boundaries can be better
methods.
tested.
Approach

Search something on google by using

By input to check and verify loops
keywords
Example

It is less exhaustive as compared to white It is comparatively more exhaustive

Exhaustiveness box testing. than black box testing.

Types Types of Black Box Testing: Types of White Box Testing:

 Black Box Testing White Box Testing
Parameters

 Functional Testing  Unit Testing

 Non-functional testing  Integration Testing
 Regression Testing  Regression Testing

Static Testing vs Dynamic Testing

Parameters Static Testing Dynamic Testing

Static testing is performed to check the

Dynamic testing is performed to analyze
defects in the software without actually
the dynamic behavior of the code.
Definition executing the code.

Objective The objective is to prevent defects. The objective is to find and fix defects.

Stage of It is performed at the early stage of It is performed at the later stage of the
execution software development. software development.

In static testing, the whole code is not In dynamic testing, the whole code is
Code Execution executed. executed.

Before/ After Static testing is performed before code Dynamic testing is performed after code
Code Deployment deployment. deployment.

Cost Static testing is less costly. Dynamic testing is highly costly.

Documents Static Testing involves a checklist for Dynamic Testing involves test cases for
Required the testing process. the testing process.

It usually takes a longer time as it

It generally takes a shorter time.
Time Required involves running several test cases.

It exposes the bugs that are explorable

It can discover a variety of bugs. through execution hence discovering
Bugs only a limited type of bugs.

Static testing may complete 100%

Dynamic testing only achieves less than
Statement statement coverage incomparably in
50% coverage.
Coverage less time.
 Parameters Static Testing Dynamic Testing

It includes Informal reviews,

It involves functional and non-
walkthroughs, technical reviews, code
functional testing.
Techniques reviews, and inspections.

Example It is a verification process. It is a validation process.

Cyclomatic Complexity

 Cyclomatic complexity, developed by Thomas McCabe, is a metric that measures the complexity of a
program by counting its decision points. It measures the number of unique paths through the code,
indicating how complex the logic is. Lower complexity suggests simpler, more manageable code,
reducing the chances of errors and making it easier to maintain and modify. Essentially, it helps assess
the code’s readability and risk associated with changes.

What is Cyclomatic Complexity?

 The cyclomatic complexity of a code section is the quantitative measure of the number of linearly
independent paths in it. It is a software metric used to indicate the complexity of a program. It is
computed using the control flow graph of the program. The nodes in the graph indicate the smallest
group of commands of a program, and a directed edge in it connects the two nodes i.e. if the second
command might immediately follow the first command.
 For example, if the source code contains no control flow statement then its cyclomatic complexity will
be 1, and the source code contains a single path in it. Similarly, if the source code contains one if
condition then cyclomatic complexity will be 2 because there will be two paths one for true and the other
for false.

Formula for Calculating Cyclomatic Complexity

 Mathematically, for a structured program, the directed graph inside the control flow is the edge joining
two basic blocks of the program as control may pass from first to second.
So, cyclomatic complexity M would be defined as,

M=E–N+2
where
 E = the number of edges in the control flow graph
N = the number of nodes in the control flow graph

How to Calculate Cyclomatic Complexity?

Steps that should be followed in calculating cyclomatic complexity and test cases design are:

Construction of graph with nodes and edges from code.

 Identification of independent paths.
 Cyclomatic Complexity Calculation
 Design of Test Cases

Example

A = 10
IF B > C THEN
A=B
ELSE
A=C
ENDIF
Print A
Print B
Print C
Control Flow Graph of the above code:
 The cyclomatic complexity calculated for the above code will be from the control flow graph.
The graph shows seven shapes(nodes), and seven lines(edges), hence cyclomatic complexity is
7-7+2 = 2.

Use of Cyclomatic Complexity

 Determining the independent path executions thus proven to be very helpful for Developers and Testers.
 It can make sure that every path has been tested at least once.
 Thus help to focus more on uncovered paths.
 Code coverage can be improved.
 Risks associated with the program can be evaluated.
 These metrics being used earlier in the program help in reducing the risks.

Advantages of Cyclomatic Complexity

 It can be used as a quality metric, given the relative complexity of various designs.
 It is able to compute faster than Halstead’s metrics.
 It is used to measure the minimum effort and best areas of concentration for testing.
 It is able to guide the testing process.
 It is easy to apply.

Disadvantages of Cyclomatic Complexity

 It is the measure of the program’s control complexity and not the data complexity.
 In this, nested conditional structures are harder to understand than non-nested structures.
 In the case of simple comparisons and decision structures, it may give a misleading figure.

Control Flow Graph (CFG)

A Control Flow Graph (CFG) is the graphical representation of control flow or computation during the
execution of programs or applications. Control flow graphs are mostly used in static analysis as well as
compiler applications, as they can accurately represent the flow inside a program unit. The control flow
graph was originally developed by Frances E. Allen..

Characteristics of Control Flow Graph

1. The control flow graph is process-oriented.
2. The control flow graph shows all the paths that can be traversed during a program execution.
3. A control flow graph is a directed graph.
4. Edges in CFG portray control flow paths and the nodes in CFG portray basic blocks.

There exist 2 designated blocks in the Control Flow Graph:

1. Entry Block: The entry block allows the control to enter into the control flow graph.
2. Exit Block: Control flow leaves through the exit block.

General Control Flow Graphs

Control Flow Graph is represented differently for all statements and loops. Following images describe it:
1. If-else
2. While

3. do-while

4. for

Example
if A = 10 then
if B > C
A=B
else A = C
endif
endif
print A, B, C

Flowchart of above example will be:

Control Flow Graph of above

Advantage of CFG
There are many advantages of a control flow graph.
1. It can easily encapsulate the information per each basic block.
2. It can easily locate inaccessible codes of a program and syntactic structures such as loops are easy to find
in a control flow graph.