CHAPTER 2

2 Testing Throughout the Software Development Lifecycle

2.1 Software Development Lifecycle Models

1. this section discusses the relationships between software development activities and test activities in the
software development lifecycle

software development lifecycle model:describes the types of activity performed at each stage in a
software development project.

type of software development life cycle model:

● Sequential development models
○ Waterfall (doesn’t support early testing)
○ V-model (support early testing)

● Iterative and incremental development models

○ Rational Unified Process (support early testing)
○ Scrum (support early testing)
○ Kanban (support early testing)
○ Spiral (or prototyping, support early testing)

Sequential development models: A sequential development model describes the software development
process as a linear, sequential flow of activities.This means that any phase in the development process
should begin when the previous phase is complete.

Iterative and incremental development models: Incremental development involves establishing

requirements, designing, building, and testing a system in pieces, which means that the software’s features
grow incrementally.

In any software development lifecycle model, there are several characteristics of good testing:

● For every development activity, there is a corresponding test activity

● Each test level has test objectives specific to that level
● Test analysis and design for a given test level begin during the corresponding development activity
● Testers participate in discussions to define and refine requirements and design, and are involved in
reviewing work products as soon as drafts are available

2. Identify reasons why software development lifecycle models must be adapted to the context of project and
product characteristics

Software development lifecycle models must be selected and adapted to the context of project and product
characteristics. An appropriate software development lifecycle model should be selected and adapted
based on the project goal.
2.2 Test Levels
Test levels are groups of test activities that are organized and managed together. which include:
● Component testing
● Integration testing
● System testing
● Acceptance testing

Component testing

Objectives of component testing (also known as unit or module testing) focuses on components that are
separately testable. Objectives of component testing include:

● Reducing risk
● Verifying whether the functional and non-functional behaviors of the component are as designed
and specified
● Building confidence in the component’s quality
● Finding defects in the component
● Preventing defects from escaping to higher test levels

Test Basis Test Object Typical Defect

Detailed design Components, units or modules Incorrect functionality

Code Code and data structures Data flow problems

Data model Classes Incorrect code and logic

Component specifications Database modules

Note: Component testing is often done in isolation from the rest of the system, which may require mock
objects such as service virtualization, harnesses, stubs, and drivers.

Note: Defects are typically fixed as soon as they are found, often with no formal defect management.
However, when developers do report defects, this provides important information for root cause analysis
and process improvement.

Note: usually this type of testing is done by the developer of the code. (the author).

Test driven development (TDD): Test driven development is highly iterative and is based on cycles of
developing automated test cases, then building and integrating small pieces of code, then executing the
component tests, correcting any issues, and refactoring the code.
 Integration Testing
integration testing: focuses on interactions between components or systems. Objectives of integration
testing include:

● Reducing risk
● Verifying whether the functional and non-functional behaviors of the interfaces are as designed
and specified
● Building confidence in the quality of the interfaces
● Finding defects in the interfaces themselves or within the components or systems
● Preventing defects from escaping to higher test levels

Test Basis Test Object Typical Defect Components Typical Defect System

Software and system design Subsystems Incorrect data, missing data, or Inconsistent message structures
incorrect data encoding between systems

Sequence diagrams Databases Incorrect sequencing or timing of Incorrect data, missing data, or
interface calls incorrect data encoding

Interface and communication Infrastructure Interface mismatch Interface mismatch

protocol specifications

Use cases Interfaces Failures in communication between Failures in communication

components between systems

Architecture at component or APIs Unhandled or improperly handled Unhandled or improperly handled

system level communication failures between communication failures between
components systems

Workflows Microservices Incorrect assumptions about the Incorrect assumptions about the
meaning, units, or boundaries of meaning, units, or boundaries of
the data being passed between the data being passed between
components systems

External interface definitions Failure to comply with mandatory

security regulations

There are two different levels of integration testing:

● Component integration testing
○ focuses on the interactions and interfaces between integrated components.
● System integration testing
○ focuses on the interactions and interfaces between systems
○ System integration testing may be done after system testing or in parallel with ongoing
system test activities.
Note:Component integration testing is often the responsibility of developers. System integration testing is
generally the responsibility of testers.

Note: In order to simplify defect isolation and detect defects early, integration should normally be
incremental rather than “big bang” that’s why we tend to use Systematic integration strategies
Systematic integration strategies is based on the system architecture such as top-down and
bottom-up.
 System Testing
System testing focuses on the behavior and capabilities of a whole system or product, often
considering the end-to-end tasks the system can perform and the non-functional behaviors it
exhibits while performing those tasks. Objectives of ٍsystem testing include:
● Reducing risk
● Verifying whether the functional and non-functional behaviors of the system are as designed and
specified
● Building confidence in the of the system as a whole
● Finding defects
● Preventing defects from escaping to higher test levels or production
Note: System testing often produces information that is used by stakeholders to make release decisions.
System testing may also satisfy legal or regulatory requirements or standards.

Test Basis Test Object Typical Defect Components

System and software requirement Applications Incorrect calculations

specifications

Risk analysis reports Hardware/software systems Incorrect or unexpected system functional or

non-functional behavior

Use cases Operating systems Incorrect control and/or data flows within the
system

Epics and user stories System under test (SUT) Failure to properly and completely carry out
end-to-end functional tasks

Models of system behavior System configuration and Failure of the system to work properly in the
configuration data production environment

State diagrams Failure of the system to work as described in

system and user manuals

System and user manuals

Note: System testing should focus on the overall, end-to-end behavior of the system as a whole, both
functional and non-functional.

Acceptance Testing
Acceptance testing, like system testing, typically focuses on the behavior and capabilities of a
whole system or product. Objectives of acceptance testing include:
● Establishing confidence in the quality of the system as a whole
● Validating that the system is complete and will work as expected
● Verifying that functional and non-functional behaviors of the system are as specified
Note: Acceptance testing may produce information to assess the system’s readiness for deployment and
use by the customer (end-user). Defects may be found during acceptance testing, but finding defects is
often not an objective, and finding a significant number of defects during acceptance testing may in some
cases are considered a major project risk. Acceptance testing may also satisfy legal or regulatory
requirements or standards.

Common forms of acceptance testing include the following:

● User acceptance testing (UAT):
○ The main objective is building confidence that the users can use the system to meet their
needs, fulfill requirements, and perform business processes with minimum difficulty, cost, and
risk.
● Operational acceptance testing (OAT):
○ The acceptance testing of the system by operations or systems administration staff is usually
performed in a (simulated) production environment. such as:
■ Testing of backup and restore
■ Installing, uninstalling and upgrading
■ Disaster recovery, User management. Maintenance tasks
■ Data load and migration tasks
■ Checks for security vulnerabilities
■ Performance testing
● Contractual and regulatory acceptance testing:
○ The main objective of contractual and regulatory acceptance testing is building confidence
that contractual or regulatory compliance has been achieved.
■ Contractual acceptance testing is performed against a contract’s acceptance criteria
■ Regulatory acceptance testing is performed against any regulations that must be adhered
to. The results will be witnessed or audited by regulatory agencies.
● Alpha and beta testing:
○ Alpha and beta testing are typically used by developers of commercial off-the-shelf (COTS)
software who want to get feedback from potential or existing users before the software
product is put on the market.
■ Alpha testing is performed at the developing organization’s site, not by the development
team, but by potential or existing customers, and/or operators or an independent test team.
■ Beta testing is performed by potential or existing customers, and/or operators at their own
locations.
Note: One objective of alpha and beta testing is building confidence among potential or existing
customers, and/or operators that they can use the system under normal, everyday conditions, and in the
operational environment(s) to achieve their objectives.
 Test Basis Test Object Typical Defect Components

Business processes Business processes for a fully integrated System workflows do not meet
system business or user requirements

User or business requirements Recovery systems and hot sites (for Business rules are not implemented
business continuity and disaster recovery correctly
testing)

Use cases Operational and maintenance processes System does not satisfy contractual or
regulatory requirements

Regulations, legal contracts and System under test (SUT) Non-functional failures
standards

System requirements System configuration and configuration

data

System or user documentation Forms

Installation procedures Reports

Risk analysis reports Existing and converted production data

2.3 Test Types

● Functional Testing:
○ Functional testing of a system involves tests that evaluate functions that the system should perform.
Functional testing concerned with “what” the system should do.

○ Functional testing considers the behavior of the software, so black-box techniques may be used to
derive test conditions and test cases for the functionality of the component or system

○ The thoroughness of functional testing can be measured through functional coverage. Functional
coverage is the extent to which some type of functional element has been exercised by tests.

● Non-functional Testing:
○ Non-functional testing of a system evaluates characteristics of systems and software such as
usability, performance efficiency or security.

○ Black-box techniques may be used to derive test conditions and test cases for nonfunctional testing.

○ The thoroughness of non-functional testing can be measured through non-functional coverage.

Nonfunctional coverage is the extent to which some type of non-functional element has been
exercised by tests.

● White-box Testing:
○ White-box testing derives tests based on the system’s internal structure or implementation.

○ The thoroughness of white-box testing can be measured through structural coverage. Structural
coverage is the extent to which some type of structural element has been exercised by tests.
 ● Change-related Testing:
○ When changes are made to a system, either to correct a defect or because of new or changing
functionality, testing should be done to confirm that the changes have corrected the defect or
implemented the functionality correctly. and have not caused any new defects

■ Confirmation testing: After a defect is fixed, the software may be tested with all test cases that
failed due to the defect.
■ Regression testing: It is possible that a change made in one part of the code, may accidentally
affect the behavior of other parts of the code

2.4 Maintenance Testing

When any changes are made as part of maintenance, maintenance testing should be performed, both to
evaluate the success with which the changes were made and to check for possible side-effects

The scope of maintenance testing depends on:

● The degree of risk of the change
● The size of the existing system
● The size of the change

Triggers for Maintenance:

There are several reasons why software maintenance, and thus maintenance testing, takes place, both for
planned and unplanned changes:
● Modification
● Migration
● Retirement

Impact Analysis for Maintenance:

Impact analysis evaluates the changes that were made for a maintenance release to identify the intended
consequences as well as expected and possible side effects of a change, and to identify the areas in the
system that will be affected by the change. Impact analysis can also help to identify the impact of a change
on existing tests. The side effects and affected areas in the system need to be tested for regressions,
possibly after updating any existing tests affected by the change.

Impact analysis may be done before a change is made, to help decide if the change should be made,
based on the potential consequences in other areas of the system.

Impact analysis can be difficult if:

● Specifications are out of date or missing
● Test cases are not documented or are out of date
● Bi-directional traceability between tests and the test basis has not been maintained
● Tool support is weak or non-existent
● The people involved do not have domain and/or system knowledge
● Insufficient attention has been paid to the software's maintainability during development