LECTURE NOTES

SOFTWARE ENGINEERING
UNIT FIVE
Lecturer: Engr George Essah Yaw Okai
Tel:0547452532
Email: geyokai@umat.edu.gh
SOFTWARE TESTING
 OBJECTIVES
• The objective of this lecture is to discuss software testing methods
and strategies

• At the end of this lecture students are expected to understand:

• Fundamentals of Testing;
• Forms of Testing;
• Types of Testing and
• Software Testing lifecycle;
3
INTRODUCTION TO SOFTWARE TESTING

• “Testing is the process of executing a program with the intent of finding

errors.”

Why should We Test?

• Although software testing is itself an expensive activity, launching software
without testing may lead to costs potentially much higher than that of
testing, especially in systems where human safety is involved.

• In the software life cycle, the earlier the errors are discovered and removed,
the lower the cost of their removal.
 INTRODUCTION TO SOFTWARE TESTING
• A strategy for software testing must accommodate low-level tests that are
necessary to verify that a small source code segment has been correctly
implemented as well as high-level tests that validate major system functions
against customer requirements.

• A strategy should provide guidance for the practitioner and a set of milestones
for the manager.

• Because the steps of the test strategy occur at a time when deadline pressure
begins to rise, progress must be measurable and problems should surface as
early as possible.
 VALIDATION AND VERIFICATION
• Software testing is one element of a broader topic often called Verification and
Validation (V&V).

• Verification refers to the set of tasks that ensure that software correctly
implements a specific function.

• Validation refers to a different set of tasks that ensure that the software that
has been built is traceable to customer requirements
• Verification: “Are we building the product right?”

• Validation: “Are we building the right product?”

 VALIDATION AND VERIFICATION
• Verification and Validation include a wide array of Software Quality Assurance
(SQA) activities: technical reviews, quality and configuration audits,
performance monitoring, simulation, feasibility study, documentation review,
database review, algorithm analysis, development testing, usability testing,
qualification testing, acceptance testing, and installation testing.

• Although testing plays an extremely important role in V&V, many other

activities are also necessary.

Testing = Verification+Validation
 FAILURES AND FAULTS
• Failure: Software does not deliver the service expected by the user
(e.g., mistake in requirements, confusing user interface)
• Fault (BUG): Programming or design error whereby the delivered
system does not conform to specification (e.g., coding error,
interface error)
• Fault avoidance: Build systems with the objective of creating fault-
free (bug-free) software
• Fault tolerance :Build systems that continue to operate when faults
(bugs) occur
• Fault detection (testing and validation):Detect faults (bugs) before
the system is put into operation.
 ALPHA, BETA AND ACCEPTANCE TESTING
• The term Acceptance Testing is used when the software is
developed for a specific customer.

• A series of tests are conducted to enable the customer to validate

all requirements.

• These tests are conducted by the end user/customer and may

range from ad-hoc tests to a well-planned systematic series of tests.

• The terms alpha and beta testing are used when the software is
developed as a product for anonymous customers.
 ALPHA AND BETA
• Alpha Tests are conducted at the developer’s site by some potential customers.

• These tests are conducted in a controlled environment.

• Alpha testing may be started when the formal testing process is near
completion.

• Beta Tests are conducted by the customers/end users at their sites.

• Unlike alpha testing, the developer is not present here.

• Beta testing is conducted in a real environment that cannot be controlled by the

developer.
SOFTWARE TESTING STRATEGY
• Testing within the context of Software Engineering is a series of four steps that
are implemented sequentially

• Initially, tests focus on each component individually, ensuring that it functions

properly as a unit. Hence, the name Unit Testing.

• Unit testing makes heavy use of testing techniques that exercise specific paths
in a component’s control structure to ensure complete coverage and
maximum error detection.

• Next, components must be assembled or integrated to form the complete

software package.
SOFTWARE TESTING STRATEGY
• Integration testing addresses the issues associated with the dual problems of
verification and program construction. Test case design techniques that focus
on inputs and outputs are more prevalent during integration, although
techniques that exercise specific program paths may be used to ensure
coverage of major control paths.
• After the software has been integrated (constructed), a set of high-order tests
is conducted.
• Validation criteria (established during requirements analysis) must be
evaluated.
• Validation testing provides final assurance that software meets all
informational, functional, behavioural, and performance requirements.
 SOFTWARE TESTING STRATEGY
• The last high-order testing step falls outside the boundary of software
engineering and into the broader context of computer system
engineering.

• Software, once validated, must be combined with other system elements

(e.g., hardware, people, databases).

• System testing verifies that all elements mesh properly and that overall
system function/performance is achieved.
BLACK-BOX TESTING
• BLACK BOX TESTING, 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.
• 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
• Behaviour or performance errors
• Initialization and termination errors
BLACK-BOX TESTING

• The Black Box Testing method applies to the following levels of

software testing:
• Integration Testing
• System Testing
• Security Testing
• Usability Testing
• Acceptance Testing
WHITE BOX TESTING

• WHITE BOX TESTING (also known as Clear Box Testing, Open Box Testing, Glass
Box Testing, Transparent Box Testing, Code-Based Testing or Structural Testing)
is a software testing method in which the internal
structure/design/implementation of the item being tested is known to the
tester.
• The tester chooses inputs to exercise paths through the code and determines
the appropriate outputs.
• Programming know-how and implementation knowledge are 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

• The White Box Testing method applies 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.
• Security Testing: Identifying vulnerabilities and security flaws

• However, it is mainly applied to Unit Testing.

 DIFFERENCES BETWEEN BLACK BOX AND WHITE BOX TESTING

CRITERIA BLACK BOX TESTING WHITE BOX TESTING

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

Mainly applicable to higher levels of

Mainly applicable to lower levels of testing:
Levels Applicable To testing: Acceptance Testing and System
Unit Testing and Integration Testing
Testing

Responsibility Generally, independent Software Testers Generally, Software Developers

Programming Knowledge Not Required Required

Implementation
Not Required Required
Knowledge
Basis for Test Cases Requirement Specifications Detail Design
Thank You