Unit II

Clean Room
• Cleanroom software engineering is an approach that emphasizes the
need to build correctness into software as it is being developed.
Instead of the classic analysis, design, code, test, and debug cycle, the
cleanroom approach suggests a different point of view
• The philosophy behind cleanroom software engineering is to avoid
dependence on costly defect removal processes by writing code
increments right the first time and verifying their correctness before
testing. Its process model incorporates the statistical quality
certification of code increments as they accumulate into a system.
The Cleanroom Process Model
Tasks in cleanroom engineering
1. Incremental planning
• In this task, the incremental plan is developed.
• The functionality of each increment, projected size of the increment
and the cleanroom development schedule is created.
• The care is to be taken that each increment is certified and integrated
in proper time according to the plan.
Tasks in cleanroom engineering
• 2. Requirements gathering
• Requirement gathering is done using the traditional techniques like
analysis, design, code, test and debug.
• A more detailed description of the customer level requirement is
developed.
Tasks in cleanroom engineering
3. Box structure specification
• The specification method uses box structure.
• Box structure is used to describe the functional specification.
• The box structure separate and isolate the behaviour, data and
procedure in each increment.
Tasks in cleanroom engineering
• 4. Formal design
• The cleanroom design is a natural specification by using the black box
structure approach.
• The specification is called as state boxes and the component level
diagram called as the clear boxes.
Tasks in cleanroom engineering
• 5. Correctness verification
• The cleanroom conducts the exact correctness verification activities
on the design and then the code.
• Verification starts with the highest level testing box structure and
then moves toward the design detail and code.
• The first level of correctness takes place by applying a set of
'correcting questions'.
• More mathematical or formal methods are used for verification if
correctness does not signify that the specification is correct.
• Correctness verification is done before the software is ever executed,
so that the developers are not permitted to get into a "debugging"
mode of operation.
Tasks in cleanroom engineering
6. Code generation, inspection and verification
• The box structure specification is represented in a specialized
language and these are translated into the appropriate programming
language.
• Use the technical reviews for the syntactic correctness of the code.
Tasks in cleanroom engineering
7. Statical test planning
• Analyzed, planned and designed the projected usages of the
software.
• The cleanroom activity is organized in parallel with specification,
verification and code generation.
Tasks in cleanroom engineering
• 8. Statistical use testing
• The exhaustive testing of computer software is impossible. It is
compulsory to design limited number of test cases.
• Statistical use technique execute a set of tests derived from a
statistical sample in all possible program executions.
• These samples are collected from the users from a targeted
population.
• This approach differs from the traditional approach, in which testers
assume there are errors in the software and set out to find as many
as possible, with the faulty assumption that if enough errors are
found and fixed, the software quality would improve.
• Software Reliability is the probability of failure-free software
operation for a specified period of time in a specified environment
Tasks in cleanroom engineering
• 9. Certification
• Certification (the Cleanroom term for testing) is performed to certify
the software reliability, not test the software in the classical sense.
The methods used are statistical quality control (SQC) and statistical
usage testing.
• After the verification, inspection and correctness of all errors, the
increments are certified and ready for integration.
Functional Specification
• The modeling approach in cleanroom software engineering uses a
method called box structure specification.
• A “box” encapsulates the system (or some aspect of the system) at
some level of detail.
• Through a process of elaboration or stepwise refinement, boxes are
refined into a hierarchy where each box has referential transparency.
• Black box. The black box specifies the behavior of a system or a part
of a system. The system (or part) responds to specific stimuli (events)
by applying a set of transition rules that map the stimulus into a
response.
• State box. The state box encapsulates state data and services
(operations) in a manner that is analogous to objects. In this
specification view, inputs to the state box (stimuli) and outputs
(responses) are represented. The state box also represents the
“stimulus history” of the black box, that is, the data encapsulated in
the state box that must be retained between the transitions implied.
• Clear box. The transition functions that are implied by the state box
are defined in the clear box. Stated simply, a clear box contains the
procedural design for the state box.
Cleanroom Design
• Cleanroom software engineering makes heavy use of the structured
programming philosophy
• Cleanroom software engineering (CSE) is an engineering process for
the development of high quality software with certified reliability
with the emphasis on design with no defects and test based on
software reliability engineering concepts.
• CSE focuses on defect prevention instead of defect correction, and
certification of reliability for the intended environment of use.
Cleanroom Testing
• statistical use testing
• tests the actual usage of the program
• determine a “usage probability distribution”
• analyze the specification to identify a set of stimuli
• stimuli cause software to change behavior
• create usage scenarios
• assign probability of use to each stimuli
• test cases are generated for each stimuli according to the usage
probability distribution

21
Certification
1. Usage scenarios must be created.
2. A usage profile is specified.
3. Test cases are generated from the profile.
4. Tests are executed and failure data are recorded and analyzed.
5. Reliability is computed and certified.

22
Certification Models
Sampling model. Software testing executes m random test cases and is certified if no failures or a
specified numbers of failures occur. The value of m is derived mathematically to ensure that required
reliability is achieved.
Component model. A system composed of n components is to be certified. The component model
enables the analyst to determine the probability that component i will fail prior to completion.
Certification model. The overall reliability of the system is projected and certified.

23
 Formal Methods
• “Formal methods used in developing computer systems
• mathematically based techniques for describing system properties.
• Such formal methods provide frameworks within which people can
specify, develop, and verify systems in a systematic, rather than ad
hoc manner.”
The Encyclopedia of Software Engineering [Mar01]

• The Problem with conventional specs:

• contradictions
• ambiguities
• vagueness
• incompleteness
• mixed levels of abstraction

24
 Formal Specification
• Objectives of formal specification : consistency, completeness,
and lack of ambiguity
• The formal syntax of a specification language enables
interpretation in only one way, Thus it eliminates ambiguity
that occurs when a natural language (e.g., English) or a
graphical notation must be interpreted.
• The use of set theory and logic notation enable clear
statement of facts .(requirements).
• Consistency is ensured by mathematically proving that initial
facts can be formally mapped (using inference rules) into later
statements within the specification.

25
 Formal Methods Concepts
• data invariant—A condition that is true throughout the
execution of the system that contains a collection of data
• state
• Many formal languages, such as OCL , use the notion of
states .A system can be in one of several states, each
represented by some externally observable behavior.
• The Z language defines a state as the stored data which a
system accesses and alters
• operation—an action that takes place in a system and reads or
writes data to a state
• precondition defines the circumstances in which a particular
operation is valid
• postcondition defines what happens when an operation has
completed its action

26
 An Example—Print Spooler

27
 States and Data Invariant
The state of the spooler is represented by the four
components 1.Queues 2. OutputDevices 3. Limits, and
4. Sizes.

The data invariant has five components:

• Each output device is associated with an upper limit of
print lines
• Each output device is associated with a possibly nonempty
queue of files awaiting printing
• Each file is associated with a size
• Each queue associated with an output device contains files
that have a size less than the upper limit of the output device
• There will be no more than MaxDevs output devices
administered by the spooler
28
 Operations
• An operation which adds a new output device to the spooler
together with its associated print limit
• An operation which removes a file from the queue associated
with a particular output device
• An operation which adds a file to the queue associated with a
particular output device
• An operation which alters the upper limit of print lines for a
particular output device
• An operation which moves a file from a queue associated
with an output device to another queue associated with a
second output device

29
 Pre- & Postconditions
For the first operation (adds a new output device to
the spooler together with its associated print limit):
Precondition: a) the output device name does not
already exist and b) there are currently less than
MaxDevs output devices known to the spooler
Postcondition: a) the name of the new device is
added to the collection of existing device names
b) a new entry is formed for the device with no files
being associated with its queue
c) the device is associated with its print limit.
30
 Mathematical Concepts*
• sets and constructive set specification
• set operators
• logic operators
• e.g., i, j: • i > j i2 => j2
• which states that, for every pair of values in the set
of natural numbers, if i is greater than j, then i2 is
greater than j2.
• sequences

31
 Sets and Constructive Specification

• A set is a collection of objects or elements and is used as a

cornerstone of formal methods.
• Enumeration
• {C++, Pascal, Ada, COBOL, Java}
• #{C++, Pascal, Ada, COBOL, Java} implies cardinality = 5
• Constructive set specification is preferable to enumeration because it enables
a succinct definition of large sets.
• {x, y : N | x + y = 10 (x, y2)}

32
 Set Operators
• A specialized set of symbology is used to represent set and logic
operations.
• Examples
• The P operator is used to indicate membership of a set. For example,
the expression
• xPX
• . The predicate A subset B
- has the value true if the members of the set A are contained in the
set B and has the value false otherwise.
• The union operator, ∪, takes two sets and forms a set that
contains all the elements in the set with duplicates
eliminated.
• {File1, File2, Tax, Compiler} ∪ {NewTax, D2, D3, File2} is the set
• {Filel, File2, Tax, Compiler, NewTax, D2, D3}

33
Logic Operators
• Another important component of a formal method is logic: the
algebra of true and false expressions.
• Examples:
• V or
• ¬ not
• => implies
• Universal quantification is a way of making a statement about
the elements of a set that is true for every member of the set.
Universal quantification uses symbol, . An example of its use
is
• i, j : N i > j => i2 > j2
• which states that for every pair of values in the set of natural
numbers, if i is greater than j, then i2 is greater than j2.

34
Sequences
• Sequences are designated using angle brackets. For example,
the preceding sequence would normally be written as
• k Jones, Wilson, Shapiro, Estavezl
• Catenation, X, is a binary operator that forms a sequence
constructed by adding its second operand to the end of its first
operand. For example,
• K 2, 3, 34, 1 l X k 12, 33, 34, 200 l
= k 2, 3, 34, 1, 12, 33, 34, 200 l
• Other operators that can be applied to sequences are head,
tail, front, and last.
• head k 2, 3, 34, 1, 99, 101 l = 2
• tail k 2, 3, 34, 1, 99, 101 l = k 3, 34, 1,99, 101 |
• last k 2, 3, 34, 1, 99, 101 l = 101
• front k 2, 3, 34, 1, 99, 101 l = k 2, 3, 34, 1, 99|

35
 Formal Specification
• The block handler:
• The block handler maintains a reservoir of unused blocks and will also keep
track of blocks that are currently in use. When blocks are released from a
deleted file they are normally added to a queue of blocks waiting to be added
to the reservoir of unused blocks.
• The state
used, free: P BLOCKS
BlockQueue: seq P BLOCKS
• Data Invariant
Used ∩ free = ∅
used ∪ free = AllBlocks
ALL i: dom BlockQueue . BlockQueue i subset = used
i, j : dom BlockQueue i ≠ j . BlockQueue i ∩ BlockQueue j = ∅
• Precondition
#BlockQueue > 0
• Postcondition
used' = used - head BlockQueue
free’ = free ∪ head BlockQueue
BlockQueue' = tail BlockQueue
36
Management Spectrum
• Effective software project management focuses on the four P’s:
People, Product, Process, and Project. The order is not
arbitrary.
• The manager who forgets that software engineering work is
an intensely human endeavor will never have success in
project management.
• A manager who fails to encourage comprehensive stakeholder
communication early in the evolution of a product risks
building an elegant solution for the wrong problem.
• The manager who pays little attention to the process runs the
risk of using competent technical methods and tools into a
vacuum.
• The manager who begins without a solid project plan failure
the success of the project.
 The Four P’s
• People — the most important element of a successful
project
• Product — the software to be built
• Process — the set of framework activities and software
engineering tasks to get the job done
• Project — all work required to make the product a reality

38
People
• Motivated and highly skilled software people are
extremely important.
• In fact, the “people factor” is so important that the
Software Engineering Institute has developed a People
Capability Maturity Model (People-CMM)
• “Every organization needs to continually improve its
ability to attract, develop, motivate, organize, and retain
the workforce needed to accomplish its strategic business
objectives”
• The people capability maturity model defines the
following key practice areas: staffing, communication and
coordination, work environment, performance
management, training, compensation, competency
analysis and development, career development,
workgroup development, team/culture development etc
The Product
Before a project can be planned:
• Product objectives and scope should be established
• Alternative solutions should be considered
• Technical and management constraints should be
identified
Estimates of cost, effective assessment of risk, realistic
breakdown of project tasks, or manageable project
schedule
 Product
• As a software developer and other stakeholders must
meet to define product objectives and scope.
• Objectives identify the overall goals for the product
(from the stakeholders’ points of view) without
considering how these goals will be achieved.
• Scope identifies the primary data, functions, and
behaviors that characterize the product
• Once the product objectives and scope are understood,
alternative solutions are considered.
• The alternatives enable managers and practitioners to
select a “best” approach, given the constraints of
delivery deadlines, budget restrictions, personnel
availability etc.
Process
• A software process provides the framework from which a
comprehensive plan for software development can be
established.
• A small number of framework activities are applicable to all
software projects, regardless of their size or complexity.
• Tasks, milestones, work products, and quality assurance points
are the framework activities to be carried out for the project
• Finally, umbrella activities—such as software quality assurance,
software configuration management, and measurement,
Software project tracking and control , Formal technical reviews
, Software quality assurance , Risk management overlay the
process model.
• Umbrella activities are independent of any one framework
activity and occur throughout the process.
• Milestones are tools used in project management to mark specific
points along a project timeline. These points may signal such as
a project start and end date
Project
• To manage complexity
• To avoid failure
• To develop a common sense approach for planning, monitoring, and
controlling the project.
People
• The Players
• Team Leaders
• The Software Team
• Coordination and Communication Issues
The Players(Stake holders)

Five categories:
1. Senior Managers: defines business issues
2. Project (technical) managers: plan, motivate,
organize, and control the practitioners
3. Practitioners: deliver the technical skills
4. Customers: specify the requirements for the
software
5. End-Users: interact with the software once it is
released
Team Leaders
• The MOI Model
• Motivation. The ability to encourage technical people
to produce to their best ability.
• Organization. The ability to mould existing processes
(or invent new ones) for translating the initial concept
into a final product.
• Ideas or innovation. The ability to encourage people to
create and feel creative even when they must work
within bounds established for a particular software
product or application.
 Software Teams
The following factors must be considered when
selecting a software project team structure ...
• the difficulty of the problem to be solved
• the size of the resulting program(s) in lines of code or
function points
• the time that the team will stay together (team lifetime)
• the degree to which the problem can be modularized
• the required quality and reliability of the system to be
built
• the rigidity of the delivery date
• the degree of sociability (communication) required for
the project
48
 Organizational Paradigms
• closed paradigm—structure : traditional hierarchy of
authority. This team can work well when producing software
which is quite similar to past efforts.
• The works done by this paradigm are less likely to be
innovative.
• random paradigm—structure: loose structure and depends
on individual initiative of the team members.
This team does not deal with the work what is similar to
past efforts. When innovation or technological
breakthrough is required, teams following the random
paradigm will excel.

49
• open paradigm— structure: some of the controls associated with the
closed paradigm but also much of the innovation that occurs when
using the random paradigm
• This paradigm is like the mixer of closed and random paradigm.
• It suits for complex problems.
• Work is performed collaboratively,
• synchronous paradigm— structure : Natural compartmentalization of
a problem and organizes team members to work on pieces of the
problem with little active communication among themselves
 Avoid Team “Toxicity”
• A frenzied work atmosphere in which team members waste
energy and lose focus on the objectives of the work to be
performed.
• High frustration caused by personal, business, or technological
factors that cause friction among team members.
• “Fragmented or poorly coordinated procedures”
• Unclear definition of roles resulting in a lack of accountability and
resultant finger-pointing.
• “Continuous and repeated exposure to failure” that leads to a loss
of confidence and a lowering of morale.

51
W5HH Principle
• Barry Boehm gave a philosophy that prepares easy and manageable
designs or outlines for software projects.
• He also gave a technique to discuss objectives, management, duties,
and technical approach of the project and its necessary resources.
• The W5HH principle in software management exists to help project
managers guide objectives, timelines, responsibilities, management
styles, and resources.
W5HH questions
• Why the system is going to be developed?
• What is activities are needed to be done in this?
• When is this done?
• Who are the reasons for these activities in this project?
• Where are these authoritatively located?
• How is the job technically and managerially finished?
• How much part of each resource is required?
Critical Practices for Software Projects
• The Airlie Council8 has developed a list of “critical software practices
for performance-based management.
• Formal risk management. What are the top ten risks for this project? For
each of the risks, what is the chance that the risk will become a problem and
what is the impact if it does?
• Empirical cost and schedule estimation. What is the current estimated size of
the application software (excluding system software) that will be delivered
into operation? How was it derived?
• Metric-based project management. Do you have in place a metrics program
to give an early indication of evolving problems? If so, what is the current
requirements volatility?
Critical Practices for Software Projects
• Earned value tracking. Do you report monthly earned value metrics? If so, are
these metrics computed from an activity network of tasks for the entire effort
to the next delivery?
• Defect tracking against quality targets. Do you track and periodically report
the number of defects found by each inspection (formal technical review) and
execution test from program inception and the number of defects currently
closed and open?
• People-aware program management. What is the average staff turnover for
the past three months for each of the suppliers/developers involved in the
development of software for this system?
Software Testing Strategies
Software Testing Strategies
• Verification: “Are we building the product right?”
• Validation: “Are we building the right product?”
A Strategic Approach to Software Testing
• To perform effective testing, you should conduct effective technical reviews
By doing this, many errors will be eliminated before testing commences.
• Testing begins at the component level and works “outward” toward the
integration of the entire computer-based system.
• Different testing techniques are appropriate for different software
engineering approaches and at different points in time.
• Testing is conducted by the developer of the software and (for large
projects) an independent test group.
• Testing and debugging are different activities, but debugging must be
accommodated in any testing strategy.
Software Testing Steps
Test Strategies for Conventional Software
Unit Testing
Unit Testing
• UNIT TESTING is a level of software testing where individual units/
components of a software are tested.
• The purpose is to validate that each unit of the software performs as
designed.
• A unit is the smallest testable part of any software.
Unit Testing - Definition
• A unit test is a way of testing a unit - the smallest piece of code that
can be logically isolated in a system. In most programming languages,
that is a function, a subroutine, a method or property.
Unit Testing - Technicalities
• Unit Testing Method
• It is performed by using the White Box Testing method.
• When is it performed?
• Unit Testing is the first level of software testing and is performed prior to
Integration Testing.
• Who performs it?
• It is normally performed by software developers themselves or their peers. In
rare cases, it may also be performed by independent software testers.
Unit Testing Benefits
• Unit testing increases confidence in changing/ maintaining code.
• Codes are more reusable. In order to make unit testing possible,
codes need to be modular. This means that codes are easier to reuse.
• Development is faster.
• The cost of fixing a defect detected during unit testing is lesser in
comparison to that of defects detected at higher levels.
• Debugging is easy. When a test fails, only the latest changes need to
be debugged.
• Codes are more reliable.
Integration Testing
Integration Testing
• INTEGRATION TESTING is a level of software testing where individual
units are combined and tested as a group. The purpose of this level of
testing is to expose faults in the interaction between integrated units.
Test drivers and test stubs are used to assist in Integration Testing.
Integration Testing - Definition
• integration testing: Testing performed to expose defects in the
interfaces and in the interactions between integrated components or
systems. See also component integration testing, system integration
testing.
• component integration testing: Testing performed to expose defects
in the interfaces and interaction between integrated components.
• system integration testing: Testing the integration of systems and
packages; testing interfaces to external organizations (e.g. Electronic
Data Interchange, Internet).
Integration Testing - Method
• Any of Black Box Testing, White Box Testing and Gray Box Testing
methods can be used. Normally, the method depends on your
definition of ‘unit’.
Integration Testing - Technicalities
• When is Integration Testing performed?
• Integration Testing is the second level of testing performed after Unit Testing
and before System Testing.
• Who performs Integration Testing?
• Developers themselves or independent testers perform Integration Testing.
Integration Testing – Approaches
• Big Bang is an approach to Integration Testing where all or most of
the units are combined together and tested at one go.
• Top Down is an approach to Integration Testing where top-level units
are tested first and lower level units are tested step by step after that.
• Bottom Up is an approach to Integration Testing where bottom level
units are tested first and upper-level units step by step after that.
• Sandwich/Hybrid is an approach to Integration Testing which is a
combination of Top Down and Bottom Up approaches.
System Testing
System Testing
• SYSTEM TESTING is a level of software testing where a complete and
integrated software is tested. The purpose of this test is to evaluate
the system’s compliance with the specified requirements.
System Testing - Definition
• system testing: The process of testing an integrated system to verify
that it meets specified requirements.
System Testing - Method
• Black Box Testing method is used.
System Testing - Technicalities
• When is it performed?
• System Testing is the third level of software testing performed after
Integration Testing and before Acceptance Testing.
• Who performs it?
• Normally, independent Testers perform System Testing.
Acceptance Testing
• ACCEPTANCE TESTING is a level of software testing where a system is
tested for acceptability. The purpose of this test is to evaluate the
system’s compliance with the business requirements and assess
whether it is acceptable for delivery.
Acceptance Testing
Acceptance Testing - Definition
• Acceptance Testing: Formal testing with respect to user needs,
requirements, and business processes conducted to determine
whether or not a system satisfies the acceptance criteria and to
enable the user, customers or other authorized entity to determine
whether or not to accept the system.
Acceptance Testing - Method
• Usually, Black Box Testing method is used in Acceptance Testing.
Testing does not normally follow a strict procedure and is not scripted
but is rather ad-hoc.
Acceptance Testing - Who performs it?

• Internal Acceptance Testing (Also known as Alpha Testing) is performed by

members of the organization that developed the software but who are not
directly involved in the project (Development or Testing). Usually, it is the
members of Product Management, Sales and/or Customer Support.
• External Acceptance Testing is performed by people who are not employees of
the organization that developed the software.
• Customer Acceptance Testing is performed by the customers of the organization that
developed the software. They are the ones who asked the organization to develop the
software. [This is in the case of the software not being owned by the organization that
developed it.]
• User Acceptance Testing (Also known as Beta Testing) is performed by the end users of the
software. They can be the customers themselves or the customers’ customers.
 Acceptance Testing - When is it performed?
• Acceptance Testing is the fourth and last level of software testing
performed after System Testing and before making the system
available for actual use.
Test Strategies for Object-Oriented Software
• Unit Testing in the OO Context
• Integration Testing in the OO Context
• Cluster testing is one step in the integration testing of OO software.
Test Strategies for WebApps
1. The content model for the WebApp is reviewed to uncover errors.
2. The interface model is reviewed to ensure that all use cases can be accommodated.
3. The design model for the WebApp is reviewed to uncover navigation errors.
4. The user interface is tested to uncover errors in presentation and/or navigation
mechanics.
5. Each functional component is unit tested.
6. Navigation throughout the architecture is tested.
7. The WebApp is implemented in a variety of different environmental configurations and is
tested for compatibility with each configuration.
8. Security tests are conducted in an attempt to exploit vulnerabilities in the WebApp or
within its environment.
9. Performance tests are conducted.
10. The WebApp is tested by a controlled and monitored population of end users.
System Testing
• Recovery testing is testing where the test engineer will test the
application to check how well the Software or the application
recovers from disasters or crashes.

• Stress Testing is testing used to check the accessibility and robustness

of software beyond usual functional limits. It mainly considers for
critical software but it can also be used for all types of software
applications.
System Testing
• Security testing is an important aspect of software testing focused on
identifying and addressing security vulnerabilities in a software
application. It aims to ensure that the software is secure from
malicious attacks, unauthorized access, and data breaches.

• Performance testing is the practice of evaluating how a system

performs in terms of responsiveness and stability under a particular
workload. Performance tests are typically executed to examine speed,
robustness, reliability, and application size.
System Testing
• Deployment testing refers to multiple layers of testing any software
must go through before being released to production. It is required to
ensure that software does not find its way to real-world users while
riddled with bugs, errors, and bad UX.
Functional Testing
• Called as Specification-Based Testing or black box testing
• With the specification-based approach to test case identification, the
only information used is the specification of the software.
Functional Testing
• Advantages
• They are independent of how the software is implemented, so if the
implementation changes, the test cases are still useful;
• test case development can occur in parallel with the implementation, thereby
reducing the overall project development interval.

• Disadvantages
• significant redundancies may exist among
• test cases, compounded by the possibility of gaps of untested software.
Structural Testing
• Called as Code-based testing also called white box testing
White Box Testing
• White-box testing is a method of software testing that tests internal
structures or workings of an application, as opposed to its
functionality. In white-box testing an internal perspective of the
system, as well as programming skills, are used to design test cases.
Black Box 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.
White Box Testing
• It also known as Clear Box Testing, Open Box Testing, Glass Box Testing,
Transparent Box Testing, Code-Based Testing or Structural Testing
• Here the internal structure/design/implementation of the item being tested
is known to the tester.
• The tester chooses inputs to exercise paths through the code and determines
the appropriate outputs.
• Programming know-how and the implementation knowledge is essential.
• White box testing is testing beyond the user interface and into the nitty-gritty
of a system.
• This method is named so because the software program, in the eyes of the
tester, is like a white/transparent box; inside which one clearly sees.
White Box Testing - Definition
• white-box testing: Testing based on an analysis of the internal
structure of the component or system.

• white-box test design technique: Procedure to derive and/or select

test cases based on an analysis of the internal structure of a
component or system.
White Box Testing - Example
• White Box Testing is like the work of a mechanic who examines the
engine to see why the car is not moving.

• A tester, usually a developer as well, studies the implementation code

of a certain field on a webpage, determines all legal (valid and invalid)
AND illegal inputs and verifies the outputs against the expected
outcomes, which is also determined by studying the implementation
code.
White Box Testing – Used by
• White Box Testing method is applicable to the following levels of
software testing:
• Unit Testing: For testing paths within a unit.
• Integration Testing: For testing paths between units.
• System Testing: For testing paths between subsystems.
• However, it is mainly applied to Unit Testing.
White Box Testing – Advantages
• Testing can be commenced 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.
White Box Testing – Disadvantages
• Since tests can be very complex, highly skilled resources are required,
with a thorough knowledge of programming and implementation.
• Test script maintenance can be a burden if the implementation
changes too frequently.
• Since this method of testing is closely tied to the application being
tested, tools to cater to every kind of implementation/platform may
not be readily available.
Black Box Testing
• It is also known as Behavioral Testing,
• is a software testing method in which the internal
structure/design/implementation of the item being tested is not
known to the tester.
• These tests can be functional or non-functional, though usually
functional.
White Box Vs Black Box Testing
Black Box Testing
• This method is named so because the software program, in the eyes
of the tester, is like a black box; inside which one cannot see. This
method attempts to find errors in the following categories:
• Incorrect or missing functions
• Interface errors
• Errors in data structures or external database access
• Behavior or performance errors
• Initialization and termination errors
Black Box Testing - Definition
• black box testing: Testing, either functional or non-functional,
without reference to the internal structure of the component or
system.

• black box test design technique: Procedure to derive and/or select

test cases based on an analysis of the specification, either functional
or non-functional, of a component or system without reference to its
internal structure.
Black Box Testing - Example
• A tester, without knowledge of the internal structures of a website,
tests the web pages by using a browser; providing inputs (clicks,
keystrokes) and verifying the outputs against the expected outcome.
Black Box Testing – Used by
• Black Box Testing method is applicable to the following levels of
software testing:
• Integration Testing
• System Testing
• Acceptance 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 Testing – Techniques
• Equivalence Partitioning: It is a software test design technique that
involves dividing input values into valid and invalid partitions and
selecting representative values from each partition as test data.
• Boundary Value Analysis: It is a software test design technique that
involves the determination of boundaries for input values and
selecting values that are at the boundaries and just inside/ outside of
the boundaries as test data.
• Cause-Effect Graphing: It is a software test design technique that
involves identifying the cases (input conditions) and effects (output
conditions), producing a Cause-Effect Graph, and generating test
cases accordingly.
Black Box Testing – Advantages
• 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.
Black Box Testing – Disadvantages
• 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.