Testing throughout the software life cycle

“Testing Throughout The
Software Life Cycle”
Graham et al (2006)
Oleh :
Chayo Rona Fakhquilla (11453205753)
Program Studi S1 Sistem Informasi
Fakultas Sains dan Teknologi
Universitas Islam Negeri Sultan Syarif Kasim Riau
http://sif.uin-suska.ac.id/ http://fst.uin-suska.ac.id/ http://www.uin-suska.ac.id/

The development process adopted for a
project will depend on the project aims and
goals. There are numerous development life
cycles that have been developed in order to
achieve different required objectives. These life
cycles range from lightweight and fast
methodologies, where time to market is of the
essence, through to fully controlled and
documented methodologies where quality and
reliability are key drivers.
SOFTWARE DEVELOPMENT MODELS

The V-model for testing was introduced
This section looks in more detail at the various
test levels. The key characteristics for each test
level are discussed and defined to be able to
more clearly separate the various test levels. A
thorough understanding and definition of the
various test levels will identify missing areas and
prevent overlap and repetition. Sometimes we
may wish to introduce deliberate overlap to
address specific risks. Understanding whether
we want overlaps and removing the gaps will
make the test levels more complementary thus
leading to more effective and efficient testing.
TEST LEVELS

Component testing, also known as unit,
module and program testing, searches for
defects in, and verifies the functioning of
software (e.g. modules, programs, objects,
classes, etc.) that are separately testable.
Component testing

Integration testing tests interfaces between components,
interactions to different parts of a system such as an
operating system, file system and hardware or interfaces
between systems.
There may be more than one level of integration
testing and it may be carried out on test objects of varying
size. For example:
➜component integration testing tests the interactions
between software com ponents and is done after component
testing;
➜system integration testing tests the interactions between
different systems and may be done after system testing. In
this case, the developing organiza tion may control only one
side of the interface, so changes may be destabilizing.
Business processes implemented as workflows may involve
a series of systems that can even run on different platforms.
Integration testing

System testing is concerned with the
behavior of the whole system/product as defined
by the scope of a development project or
product. It may include tests based on risks
and/or requirements specification, business
processes, use cases, or other high level
descriptions of system behavior, interactions with
the operating system, and system resources.
System testing

When the development organization has
performed its system test and has corrected all
or most defects, the system will be delivered to
the user or customer for acceptance testing.
The acceptance test should answer questions
such as: 'Can the system be released?', 'What,
if any, are the outstanding (business) risks?'
and 'Has development met their obligations?'.
Acceptance testing

TEST TYPES: THE
TARGETS OF
TESTING

Test types are introduced as a means of
clearly defining the objective of a certain test
level for a programme or project. We need to
think about different types of testing because
testing the functionality of the component or
system may not be sufficient at each level to
meet the overall test objectives. Focusing the
testing on a specific test objective and, therefore,
selecting the appropriate type of test helps
making and communicating decisions against
test objectives easier.
TEST TYPES: THE TARGETS OF TESTING

Testing of function
(functional testing)

Functional testing considers the
specified behavior and is often also referred to
as black-box testing. This is not entirely true,
since black-box testing also includes non-
functional testing.
Testing of function (functional testing)

Testing of software
product
characteristics (non-
functional testing)

The characteristics and their sub-characteristics are, respectively:
• functionality, which consists of five sub-characteristics: suitability, accuracy,
security, interoperability and compliance; this characteristic deals with func
tional testing as described in Section 2.3.1;
• reliability, which is defined further into the sub-characteristics maturity
(robustness), fault-tolerance, recoverability and compliance;
• usability, which is divided into the sub-characteristics understandability,
learnability, operability, attractiveness and compliance;
• efficiency, which is divided into time behavior (performance), resource uti
lization and compliance;
• maintainability, which consists of five sub-characteristics: analyzability,
changeability, stability, testability and compliance;
• portability, which also consists of five sub-characteristics: adaptability,
installability, co-existence, replaceability and compliance.
Testing of software product characteristics (non-
functional testing)

Testing of software
structure/architecture
(structural testing)

The third target of testing is the structure
of the system or component. If we are talking
about the structure of a system, we may call it
the system architecture. Structural testing is
often referred to as 'white-box' or 'glass-box'
because we are interested in what is happening
'inside the box'.
Testing of software structure/architecture
(structural testing)

Testing related to
changes (confirmation
and regression
testing)

➜Confirmation testing (re-testing)
When doing confirmation testing, it is
important to ensure that the test is executed in
exactly the same way as it was the first time,
using the same inputs, data and environment.
➜Regression testing
The term 'regression testing' is
something of a misnomer. It would be better if it
were called 'anti-regression' testing because we
are executing tests with the intent of checking
that the system has not regressed (that is, it does
not now have more defects in it as a result of
some change).
Testing related to changes (confirmation and
regression testing)

The development and test process
applicable to new developments does not
change fundamentally for maintenance
purposes. The same test process steps will apply
and, depending on the size and risk of the
changes made, several levels of testing are
carried out: a component test, an integration test,
a system test and an acceptance test. A
maintenance test process usually begins with the
receipt of an application for a change or a
release plan. The test manager will use this as a
basis for producing a test plan. On receipt of the
new or changed specifications, corresponding
test cases are specified or adapted.
MAINTENANCE TESTING

Impact analysis and
regression testing

Usually maintenance testing will consist of two
parts:
➜testing the changes
➜regression tests to show that the rest of the
system has not been affected by the
maintenance work.
➜In addition to testing what has been changed,
maintenance testing includes extensive
regression testing to parts of the system that
have not been changed. A major and important
activity within maintenance testing is impact
analysis.
Impact analysis and regression testing

Triggers for
maintenance testing

As stated maintenance testing is done on an
existing operational system. It is triggered by
modifications, migration, or retirement of the system.
Modifications include planned enhancement changes
(e.g. release-based), corrective and emergency
changes, and changes of environment, such as
planned operating system or database upgrades, or
patches to newly exposed or discovered vulnerabilities
of the operating system. Maintenance testing for
migration (e.g. from one platform to another) should
include operational testing of the new environment,
as well as the changed software.
Triggers for maintenance testing

Testing throughout the software life cycle

More Related Content

What's hot (20)

Similar to Testing throughout the software life cycle (17)

Recently uploaded (20)

Testing throughout the software life cycle