Chapter – 3 Software Testing Methods

Certificate in Software Testing Skill

Page 1 of 25
 Confidentiality Statement

This document should not be carried outside the physical and virtual boundaries of TCS and
its client work locations. Sharing this document with any person other than a TCS associate
would tantamount to violation of confidentiality agreement signed by you while joining
TCS.

Notice
The information given in this course material is merely for reference. Certain third party
terminologies or matter that may be appearing in the course are used only for contextual
identification and explanation, without an intention to infringe.
Certificate in Software Testing Skill TCS Business Domain Academy

Contents
Chapter-3 Software Testing Methods .............................................................................4
3.1 Introduction to Static and Dynamic testing ........................................................... 5
3.2 Static Testing in detail ........................................................................................... 7
3.3 Box Approaches of Testing .................................................................................. 15
Summary ........................................................................................................................ 23

Page 3 of 25
Certificate in Software Testing Skill TCS Business Domain Academy

Chapter-3 Software Testing Methods

Introduction
There are many approaches available in software testing. Testing the software by
performing a manual inspection, review or walkthrough is called Static Testing, whereas
executing programmed code with a given set of test cases is called dynamic testing.

Learning Objective
After reading this chapter, you will be able to understand:
• Static Testing
• Dynamic Testing
• Difference between Static and Dynamic Testing
• Static Testing Methods and technologies
• List of static testing tools language wise
• Black Box Testing & its techniques
• White Box Testing & its techniques
• Grey Box Testing

Page 4 of 25
Certificate in Software Testing Skill TCS Business Domain Academy

3.1 Introduction to Static and Dynamic testing

3.1.1 Static Testing

There are several approaches available in software testing. Testing the software by
performing a manual inspection, review or walkthrough is called Static Testing, whereas
actually executing programmed code with a given set of test cases is called dynamic testing.

The Verification activities into the category of Static Testing. During static testing, you have
a checklist to check whether the work you are doing is going as per set standards of the
organization or not. These standards can be for Coding, Integrating and Deployment.
Reviews, Inspection's and Walkthrough's are static testing methodologies.

Static testing is carried out without executing the application under test whereas dynamic
testing requires one or more executions of application. Static testing is useful in discovery of
faults in the application, ambiguities and errors in requirements and other application
related documents, at relatively very low cost then dynamic expensive testing. While doing
static testing we can find Unreachable Code, Undeclared values, Syntax errors using its
methods and technology for finding defects.

Static testing is accompanied out by an individual who did not write code or by a team of
individuals. A sample process of static testing is shown in below figure. The test team
responsible for static testing has access to requirements document, application and all
other application related documents such as design documents and user manuals and also
have access of static testing tools. A static testing tools takes application code as input and
generates a variety of data useful in test process as output.

Figure 1 : Element of Static Testing

Page 5 of 25
Certificate in Software Testing Skill TCS Business Domain Academy

Static testing is understood, as proofreading, plus when programming tools/text editors

check source code structure or compilers (pre-compilers) check syntax and data flow as
static program analysis.

3.1.2 Dynamic Testing

Dynamic testing/analysis is a tricky process of inspecting and evaluating software

applications as user prospective. It evaluates the software applications that work under
different environments. Dynamic testing ensure that software will function during
installation, and through its life cycle soon after its installation at the user’s end.

Dynamic testing takes place during run time. Dynamic testing may begin before the
program is fully (100 %) completed in order to test particular sections of code and are
applied to distinct functions or modules. Classic techniques for this are either using
stubs/drivers or execution from a debugger environment.

Dynamic Testing contains working with the software, giving input values and checking if the
output is as expected. These are the Validation activities. Unit Tests, Integration Tests,
System Tests and Acceptance Tests are few of the Dynamic Testing methodologies.

3.1.3 Difference between Static & Dynamic Testing

Tester may muddy between static and dynamic testing methods as both of them have
similar purposes. There are number of visible differences between static and dynamic
testing.

The simplest difference is that static testing evaluates the software when it is idle, while
dynamic testing operates the software to see if it functions properly.

Static testing looks for bugs/defects in the software when it is in an inactive state while
dynamic software checks for errors when the software is running or under execution. So
each of these tests have an approach that is unique from each other but will eventually help
the software to have the functionality it should have.

Static and dynamic testing accompaniment each other because they have similar goal of
searching for bugs and errors in the application. Static testing has the ability to help the

Page 6 of 25
Certificate in Software Testing Skill TCS Business Domain Academy

software developers to present changes or modifications right during the software

development phases.

Static testing involves verification, whereas dynamic testing involves validation. And
together they help improve software quality. Among the techniques for static analysis,
mutation testing can be used to ensure the test-cases will detect errors which are
introduced by mutating the source code.

3.2 Static Testing in detail

In this section we will know about Static Testing Methods and technologies, Goal and List of
static testing tools.

3.2.1 Static Testing Methods and technologies

Reviews, Inspection's and Walkthrough's are static testing methodologies. Static testing
could be manual or automated.

Inspection
It is a technique in which the work product is examined for its compliance to specific
standards and checked against a history of common errors.
Inspection is a more appropriately defined process than a walkthrough and usually is
associated with code. Several organizations following formal code inspections to improve
the code quality at a lower cost than suffered when dynamic testing is used. Organization
experienced substantial increases in productivity and software quality due to code
inspections.

Code inspection carried out by experienced team members and works according to an
inspection plan which consists of following elements.
• Statement of purpose
• Work product to be inspected, this includes code and associated documents needed
for inspection
• Team formation, roles, and tasks to be performed
• Rate at which the inspection task is to be completed
• Data collection forms where the team will record its findings such as defects
discovered, coding standard violations, and time spent in each task.

Page 7 of 25
Certificate in Software Testing Skill TCS Business Domain Academy

Members of the inspection team are assigned roles of moderator, reader, author and
recorder. The moderator is responsible of the process and leads the review. Actual code is
read by the reader, possibly with the help of a code browser and with large monitors for all
in the team to view the code. The recorder records any issues or errors discovered to be
looked into. The author is the actual developer whose main task is to help others in
understanding code. It is important that the inspection process be friendly and non-
confrontational.

Review
It is a technique in which the work product is discussed by a group of two or more persons
and re-examined for possible corrections. In other words review is an organised
examination of a document by one or more people with the aim of finding and removing
errors early in the SDLC. Reviews are used to verify documents like requirement docs,
system designs, code, test plans and test cases.

Review processes can differ usually in their levels of formality, where formality relates to
the level of structure and documentation associated with the activity. Some types of review
are fully informal while others are formal. Planning, Kick-off, Individual preparation, Review
Meeting, Rework and follow up are phase of formal review.

Figure 2 : Phases of formal review

Page 8 of 25
Certificate in Software Testing Skill TCS Business Domain Academy

The decision on the appropriate level for a review is generally based on combinations of the
following factors.

• Maturity of the development process. The more mature the process tend more
mature reviews.
• Regulatory or legal requirements. These are used to govern the software
development activities in certain industries, particularly in safety-critical areas such
as railway signalling, and determine what kinds of review should take place.
• Need of audit trail. Formal review processes ensure that is it is possible to trace
backwards throughout the SDLC. Level of formalities in the types of review can help
to raise the level of audit trial.

Reviewer can have many review objective and this identifies main focus of review. Usually
the review object include.

• Finding defects.
• Gaining understanding.
• Generating discussion.
• Decision making by consensus.

All reviews (Formal and informal) exhibit the same basic elements of process.

• Document under review is studied by the reviewers.

• Reviewers identify issues or problems and inform the author either verbally or in a
documented form, which might be as formal as raising a defect report or as
informal as annotating the document under review.
• Author decides on any action to take in response to the comments and updates the
document accordingly.

Benefit of the review process are

• Productivity of the development team is improved and time lines reduced because
of the correction of defects in early stages.
• Testing time and costs will reduce as there is enough time spent during initial phase.

Page 9 of 25
Certificate in Software Testing Skill TCS Business Domain Academy

Workflow of a formal review are show below Figure 3

Figure 3 workflow of a formal review

The role of each reviewer is to look at documents belonging to them from their assigned
perspective, this may include the use of checklists. In addition to assigned review roles, the
review process itself define specific roles and responsibilities that should be fulfilled for
formal review.

• Manager: The manager decides on what is to be reviewed (if not already defined),
ensures there is sufficient time allocated in the project plan for all of the required
review activities and also determines if the review objectives have been met.
Managers do not usually get involved in the actual review process unless they can
add real value, for example they have technical knowledge key to the review.
• Moderator: The moderator is sometimes known as the review leader. This is the
person who leads the reviews of the document or set of documents, including
planning the review, running the meeting, and follow-ups after the meeting. If
necessary, the moderator may mediate between the various points of view and is
often the person on whom the success of the review rests. The moderator will also
make the final decision as to whether to release an updated document.

Page 10 of 25
Certificate in Software Testing Skill TCS Business Domain Academy

• Author: Author is the writer or person with chief responsibility for the development
of the document(s) to be reviewed. The author will in most instances also take
responsibility for fixing any agreed defects.
• Reviewers: These are individuals with a specific technical or business background
(called checkers or inspectors). As discussed above, reviewers should be chosen to
represent different perspectives and roles in the review process and take part in any
review meetings.
• Scribe (or recorder): The scribe attends all review meetings and documents all of
the issues and defects, problems and open points that were identified during the
meeting.

The following suggested success factors should be considered while measuring the success
of a review.
• Each review should have a clearly predefined and agreed objective and the right
people should be involved to ensure that the objective is met. For example, in an
inspection, if the objective is technically based, each reviewer will have a defined
role and have the experience to complete the technical review, this should reflect
testers as valued reviewers.
• Any defects found are welcomed, and expressed objectively.
• The review should be seen as being conducted within an atmosphere of trust, so
that the output will not be used for the evaluation of the participants, and that the
people issues and psychological aspects are dealt with (e.g. making it a positive
experience for the author and all participants).
• Review techniques (both formal and informal) that are suitable to the type and level
of software work-products and reviewers.
• Checklists or roles should be used, where suitable, to increase effectiveness of
defect identification. For example, in an inspection, roles such as data entry clerk or
technical architect may be required to review a specific document.
• Management support is essential for a good review process (e.g. by incorporating
adequate time for review activities in project schedules).
• There should be an emphasis on learning and process improvement.

Page 11 of 25
Certificate in Software Testing Skill TCS Business Domain Academy

Walkthrough

It is a technique mostly done on the code developed, where the code is outlined manually to
monitor the state of the program variables as a way of analysing the logic.

Walkthroughs and inspections are an integral part of static testing. Walkthrough is a casual
process to review any application-related document. For example, requirements are
reviewed using a process termed requirements-walkthrough. Code is reviewed using code-
walkthrough, also known as peer code review. A detailed report contains list of concerned
items regarding the document reviewed.

While requirement walkthrough, the test team must review the requirements document to
ensure that the requirements matches the user expectation and from inconsistencies and
ambiguities. Requirements review process also improves the understanding of the test
team regarding what is preferred of the application. Both functional and non-functional
requirements are reviewed and a list of items of concern regarding requirement is
generated in a detailed report. The Key Characteristics of Walk Through are Scenario, Dry
Run and Peer Group.

Use of Static Code Analysis Tools in Static Testing

Like reviews static analysis looks for defects without executing the code and this will carried
out once the code has been written.

Static analysis tools add the highest value when used during component and integration
testing and will normally involves their use by developers to check against predefined rules
or standards, and by designers during software modelling.

A static analysis tools runs automatically and reports all defects it recognises, few of which
may be insignificant and require small work to correct, while other could be critical and
need urgent correction. These defects therefore require strong planning to ensure that the
full benefit is obtained from using the tool in priority.

Page 12 of 25
Certificate in Software Testing Skill TCS Business Domain Academy

Typical defects discovered by static analysis tools include

• Referencing a variable with an undefined value, for example using a variable as part
of a calculation before the variable has been given a value.
• Inconsistent interface between modules and components, for example module X
requests three values from module Y, which has only two outputs.
• Variables that are never used. This is not strictly an error, but if a programmer
declares a variable in a program and does not use it, there is a chance that some
intended part of the program has inadvertently been omitted.
• Unreachable (dead) code. This means lines of code that cannot be executed
because the logic of the program does not provide any path in which that code is
included.
• Programming standards violations, for example if the standard is to add comments
only at the end of the piece of code, but there are notes throughout the code, this
would be a violation of standards.
• Security vulnerabilities, for example password structures that are not secure.
• Syntax violations of code and software models, for example incorrect use of the
programming or modelling language.
An Early detection of defects, early warning about suspicious aspects of code or design and
detecting dependencies and inconsistencies in software models such as links etc. are
benefit of static testing.

3.2.2 Goal of static testing

In static testing process, software developers mainly focus on two goals first verification and
other validation. Verification confirms that the software in a particular test phase will pass
that phase and is hence ready for the next phase of development and testing whereas
validation is the overall presumption that the software in its entirely has necessary
requirement to function and meet the user expectations.

The purpose of both validation and verifications in software testing are nor similar. For
example validation ensures that the development of precise software by enabling the
developers to track back through the system to meet particular user requirements.

Meanwhile the purpose of the validation is to ensure that the software will pass a particular
phase during the time of development whereas verification means ensuring that the
software development is happening by using the right method.

Page 13 of 25
Certificate in Software Testing Skill TCS Business Domain Academy

Static testing also ensures the software quality of the product with without executing the
application using various methods. In software development, the core definition of quality is
subjective as different software applications have different purposes and goals. There is
three rules that the software needs to pass in order to considered as a quality software, the
failure rate of the software in actual use, and of course client satisfaction.

Below are some issues that will help you determine whether the software under testing can
pass the quality assurance or not.

• Software encounters nominal failures in testing and also during actual use.
• Software should be reliable means that the software needs to demonstrate
extended.
• The final consideration is the satisfaction of the end-users. This is itself an indication
of whether the software is of good quality or not.

3.2.3 List of static testing tools

Below are list of some popular static analysis tools language wise.
• Multiple language : Coverity Code Advisor, Black Duck Software Suite, CAST
Application Intelligence Platform, Cigital SecureAssist, ConQAT, HP Fortify
Software Static Code Analyser, IBM Rational AppScan Source Edition etc..
• Dot Net: .NET Compiler Platform, StyleCop, FxCop, CodeRush, CodeIt.Right,
Parasoft dotTEST, etc.
• Java: Jtest, ThreadSafe, FindBugs, Checkstyle, PMD, JArchitect, SourceMeter,
Squale, soot etc.
• Java Scripts: JSHint, ESLint, JSCS, JSHint, JSLint, Plato etc...
• C/C++: Parasoft C/C++test, BLAST, Astree, Clang, Eclipse, Frama-C, ECLAIR,
Polyspace, PVS-Studio, Splint etc…
• PHP: RIPS
• PowerBuilder: PB Code Analyser, Visual Expert for PowerBuilder etc…
• PL/SQL: TOAD, Visual Expert for PL/SQL etc…
• Python: PyCharm, Pylint, Quantified Code etc…
• Perl: Padre, PerlTidy etc.
• Objective-C : Clang

Page 14 of 25
Certificate in Software Testing Skill TCS Business Domain Academy

3.3 Box Approaches of Testing

There are many methods that can be used for software testing. White, black and grey box
are boxing methods for software testing.

3.3.1 White Box testing

White Box testing is the detailed analysis of the internal logic and structure of the code.
White Box testing is also called open box and glass testing. A tester needs to know the
internal flow of the code to perform this testing. In this testing the tester needs to have a
look deep inside the source code and find out which chunk/unit of the code is behaving
improperly.

White box testing is also known as clear box testing, Glass box testing, Transport box
testing, or Structure testing and is also a method of testing software that test internal
structures or workings of an applications. In white-box testing an internal perspective of the
system, as well as programming skills, are required and used to design test cases. The tester
chooses inputs to exercise paths through the code and determine the appropriate outputs.
It can be applied at unit, integration and system levels of software testing process. It is
designed to expose many error and problem and might not detect unimplemented parts of
the specification or missing requirements.

Figure 4 White Box Testing

White box testing completely trusts on the identified structure of the software as we can
see in the following examples

• Component level: the structure is that of the code itself, i.e. statements, decisions
or branches

Page 15 of 25
Certificate in Software Testing Skill TCS Business Domain Academy

• Integration level: the structure may be a call tree (a diagram in which modules call
other modules). Modules are checked for proper and correct integration with the
other modules
• System level: the structure may be a menu structure, business process or web page
structure
White box techniques include
• Data flow testing
• Decision testing and coverage
• Path testing
• Statement testing and coverage

Data flow testing

• Data-flow testing looks at the life-cycle of a particular piece of data (i.e. a variable)
in an application.
• Test cases are designed to check availability of the data.
• By looking for patterns of data usage, risky areas of code can be found and more
test cases can be applied.

Decision testing and coverage

• Decision coverage, related to branch testing, is the assessment of the percentage of
decision outcomes that have been exercised by a test case suite. E.g. The True and
False options of an IF statement.
• Decision testing derives test cases to execute specific decision outcomes, normally
to increase decision coverage.
• Decision testing is a form of control flow testing as it generates a specific flow of
control through the decision points.

Path testing
• In component testing, statement coverage is the assessment of the percentage of
executable statements that have been exercised by a test case suite.
• It indicates the total number of statements being executed.
• Statement testing derives test cases to execute specific statements, normally to
increase statement coverage.

Page 16 of 25
Certificate in Software Testing Skill TCS Business Domain Academy

Statement testing and coverage

• Path testing has been one of the first test methods implemented in white box
testing process.
• The procedure itself is similar to the walk-through.
• First, a certain path through the program is chosen. Possible inputs and the correct
results are written down.
• Then the program is executed by hand, and its result is compared to the predefined.
Possible faults have to be written down at once.
• Even though path testing is a typical white box test, it is nowadays also used in
black box tests.

Advantages of white box testing

There are various important advantages of white box testing.

• This test can disclose errors and weaknesses of the application during the
development phases. Therefore software developers can get an opportunity to
improve the program that can be both stable and robust in nature.
• White box testing helps you to know and understand the internal working patterns
of the application and will also help you in correcting any problem that may occurs
in the development phase.
• White box testing is a complete test that leads to the development of a standard,
fail-proof and complete software application
• Testing can be began at an earlier stage. One need not wait for the GUI to be
available. Testing is more thorough, with the possibility of covering most paths.

Disadvantages of white box testing

• Since tests can be very complex, highly skilled resources are required, with
thorough knowledge of programming and implementation.
• Test script maintenance can be a burden if the implementation changes too
frequently.
• Since this method of testing it closely tied with the application being testing, tools
to cater to every kind of implementation/platform may not be readily available.

Page 17 of 25
Certificate in Software Testing Skill TCS Business Domain Academy

3.3.2 Black Box testing

Black box testing is an enquiring kind of testing as it is somewhat mysterious to the person
who is testing the product. The tester will not have any prior knowledge or information
about the internal mechanisms of the system that will be tested. In a typical software
testing environment, the tester will only know what the inputs are and the expected output.

Figure 5 : Black Box Testing

Black Box Testing is also known as Behavioural 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.
Black box testing method that tests the functionality of an application as opposed to its
internal structures or workings. Specific knowledge of the application's code/internal
structure and programming knowledge in general is not required. Test cases are built
around specifications and requirements, i.e., what the application is supposed to do. It uses
external descriptions of the software, including specifications, requirements, and design to
derive test cases. These tests can be functional or non-functional, though usually functional.
The test designer selects valid and invalid inputs and determines the correct output. There
is no knowledge of the test object's internal structure.

It typically comprises most if not all testing at higher levels, but can also dominate unit
testing as well. It can be applied at all levels of software testing

In case of Requirements based technique (RBT), Models, either formal or informal, are used
for the specification of the problem to be solved, the software or its components. From
these models test cases can be derived systematically

Page 18 of 25
Certificate in Software Testing Skill TCS Business Domain Academy

Black Box testing method is applicable to the Integration, System and Acceptance levels of
software testing. The higher the level, and hence the bigger and more complex the box, the
more black box testing method comes into use.

Black box Techniques

Typical black-box test design techniques include

• Decision Table testing
• Use case testing
• State transition tables
• Equivalence partitioning
• Boundary value analysis

Decision Table testing

• Here Test cases are derived in order to execute the combination of inputs.
• Decision tables are a good way to capture system requirements that contain logical
conditions, and to document internal system design.
• They may also be used to record complex business rules that a system is to
implement. The specification is analysed, and conditions and actions of the system
are identified.
• The input conditions and actions are most often stated in such a way that they can
either be true or false (Boolean).
• The decision table contains the triggering conditions, often combinations of true
and false for all input conditions, and the resulting actions for each combination of
conditions.
• Each column of the table corresponds to a business rule that defines a unique
combination of conditions that result in the execution of the actions associated with
that rule.
• The coverage standard commonly used with decision table testing is to have at
least one test per column, which typically involves covering all combinations of
triggering conditions.
• The strength of decision table testing is that it creates combinations of conditions
that might not otherwise have been exercised during testing. It may be applied to
all situations when the action of the software depends on several logical decisions
• The four quadrants of decision table are

Page 19 of 25
Certificate in Software Testing Skill TCS Business Domain Academy

Figure 6 : Four quadrants of decision table

Use case testing

• Use case in software engineering is a description of steps or actions between a user

(actor) and a software system which lead the user towards something useful. The
user or actor might be a person or something more abstract, such as an external
software system or manual process
• Test cases are derived to execute user scenarios
• Use cases describe the process flow in a system and hence the test cases derived
from use cases are most useful in identifying defects in the process flows during
real-world use of the system
• They also help to find out integration defects caused by the interaction and
interference of different components, which individual component testing would
not see
• Use cases, often referred to as scenarios, are very useful for designing acceptance
tests with customer/user participation
• Best example can be a Chocolate Vending Machine

State transition tables

• A system may exhibit different responses depending on the current conditions or

previous history (its state)
• This change aspect of the system can be shown using State Transition Diagram
• It allows the tester to view the software in terms of its states, transitions between
the states, the inputs or events that result in transitions and the outcome actions
from those transitions
• The states of the system or object under test are separate, identifiable and finite in
number
• A state table shows the relationship between the states and inputs, and can
highlight possible transitions that are invalid

Page 20 of 25
Certificate in Software Testing Skill TCS Business Domain Academy

• Tests can be designed to cover a typical sequence of states, to cover every state, to
exercise every transition, to exercise specific sequences of transitions or to test
invalid transitions
• This technique is suitable for modelling a business object having specific states or
testing screen-dialogue flows (e.g. for internet applications or business scenarios)

Equivalence partitioning

• This technique divides the input data of a software unit into partitions of data from
which test cases can be derived. In principle, test cases are designed to cover each
partition at least once
• This technique tries to define test cases that uncover classes of errors, thereby
reducing the total number of test cases that must be developed
• In rare cases equivalence partitioning is also applied to outputs of a software
component, typically it is applied to the inputs of a tested component
• The equivalence partitions are usually derived from the requirements specification
for input attributes that influence the processing of the test object. An input has
certain ranges which are valid and other ranges which are invalid
• Invalid data here does not mean that the data is incorrect, it means that this data
lies outside of specific partition

Boundary value analysis

• Behaviour at the edge of each equivalence partition is more likely to be incorrect, so

boundaries are the areas where testing is likely to yield defects
• Boundary value analysis is a software testing technique in which tests are designed
to include representatives of boundary values
• Values can be on the edge of an equivalence partition or at the smallest value on
either side of an edge
• The values could be either input or output ranges of a software component
• Since these boundaries are common locations for errors that result in software
faults they are frequently exercised in test cases
• Boundary value analysis can be applied at all test levels. It is relatively easy to apply
and its defect finding capability is high; detailed specifications are helpful
• This technique is often considered an extension of equivalence partitioning

Page 21 of 25
Certificate in Software Testing Skill TCS Business Domain Academy

Advantages of black box testing

• Tests are done from a user’s point of view and will help in exposing discrepancies in
the specifications.
• Tester need not know programming languages or how the software has been
implemented.
• Tests can be conducted by a body independent from the developers, allowing for an
objective perspective and the avoidance of developer-bias.
• Test cases can be designed as soon as the specifications are complete.

Disadvantages of black box testing

• Only a small number of possible inputs can be tested and many program paths will
be left untested
• Without clear specifications, which is the situation in many projects, test cases will
be difficult to design
• Tests can be redundant if the software designer/ developer has already run a test
case
• Ever wondered why a soothsayer closes the eyes when foretelling events? So is
almost the case in Black Box Testing.

3.3.3 Grey Box testing

Grey box testing is a method to test applications with a limited knowledge of the internal
workings of an application. Mastering the domain of the system always gives the tester an
advantage over someone with limited domain knowledge.
Unlike black box testing, where the tester only tests the applications user interface, in grey
box testing, the tester has access to design documents and database.
Advantages of Grey Box
• Offers combined benefits of black-box and white-box testing wherever possible.
• Grey box testers don't rely on the source code; instead they rely on interface
definition and functional specifications.
• Based on the limited information available, a grey-box tester can design excellent
test scenarios especially around communication protocols and data type handling.
• The test is done from the point of view of the user and not the designer.

Page 22 of 25
Certificate in Software Testing Skill TCS Business Domain Academy

Disadvantages of Grey Box

• Since the access to source code is not available, the ability to go over the code and
test coverage is limited.
• The tests can be redundant if the software designer has already run a test case.
• Testing every possible input stream is unrealistic because it would take an
unreasonable amount of time; therefore, many program paths will go untested.

Summary

• Testing the software by performing a manual inspection, review or walkthrough is

termed as Static Testing
• Dynamic Testing involves working with the software, giving input values and
checking if the output is as expected.
• The simplest difference is that static testing evaluates the software when it is idle,
while dynamic testing operates the software to see if it functions properly.
• Reviews, Inspection's and Walkthrough's are static testing methodologies.
• Inspection is a technique in which the work product is examined for its compliance
to specific standards and checked against a history of common errors.
• Review is a technique in which the work product is discussed by a group of two or
more persons and re-examined or revaluated for possible corrections.
• Walkthrough is a technique mostly done on the code developed, where the code is
traced manually to monitor the state of the program variables as a way of analysing
the logic.
• In static testing process, software developers mainly concentrate on two goals first
verification and other validation.
• White, black and grey box are boxing methods for software testing.
• White Box testing is the detailed analysis of the internal logic and structure of the
code. White Box testing is also called open box and glass testing.
• White box techniques include
o Data flow testing
o Decision testing and coverage
o Path testing
o Statement testing and coverage

Page 23 of 25
Certificate in Software Testing Skill TCS Business Domain Academy

• Black box testing method that tests the functionality of an application as opposed
to its internal structures or workings. Specific knowledge of the application's
code/internal structure and programming knowledge in general is not required.
• Grey box testing is a method to test the application with a limited knowledge of the
internal workings of an application. Unlike black box testing, where the tester only
tests the applications user interface, in grey box testing, the tester has access to
design documents and database.

Page 24 of 25