Testing throughout the software life cycle

“Testing Throughout The Software Life Cycle”
MUHAMAD IQBAL SAKTI
11453101976
PROGRAM STUDI S1 SISTEM INFORMASI
FAKULTAS SAINS DAN TEKNOLOGI
UIN SUSKA RIAU
2017
http://sif.uin-suska.ac.id/
http://fst.uin-suska.ac.id/
http://www.uin-suska.ac.id/

Testing is not a stand-alone activity. It has its place within a software
development life cycle model and therefore the life cycle applied will
largely determine how testing is organized.
There are many different forms of testing. Because several disciplines,
often with different interests, are involved in the development life cycle, it
is important to clearly understand and define the various test levels and
types. This chapter discusses the most commonly applied software
development models, test levels and test types. Maintenance can be seen as
a specific instance of a development process. The way maintenance
influences the test process, levels and types and how testing can be
organized is described in the last section of this chapter.
TESTING THROUGHOUT THE
SOFTWARE LIFE CYCLE

SOFTWARE DEVELOPMENT MODELS
1. Understand the relationship between development, test activities and work products in
the development life cycle and give examples based on project and product
characteristics and context. (K2)
2. Recognize the fact that software development models must be adapted to the context of
project and product characteristics. (Kl)
3. Recall reasons for different levels of testing and characteristics of good testing in any life
cycle model. (Kl)
SOFTWARE LIFE CYCLE

SOFTWARE LIFE CYCLE
Before discussing the V-model, we will look at the model which came before
it. The waterfall model was one of the earliest models to be designed. It has a
natural timeline where tasks are executed in a sequential fashion. We start at
the top of the waterfall with a feasibility study and flow down through the
various project tasks finishing with implementation into the live environment.
Design flows through into development, which in turn flows into build, and
finally on into test. Testing tends to happen towards the end of the project life
cycle so defects are detected close to the live implementation date. With this
model it has been difficult to get feedback passed backwards up the waterfall
and there are difficulties if we need to carry out numerous iterations for a
particular phase. Before discussing the V-model, we will look at the model
which came before it. The waterfall model was one of the earliest models to
be designed. It has a natural timeline where tasks are executed in a sequential
fashion. We start at the top of the waterfall with a feasibility study and flow
down through the various project tasks finishing with implementation into the
live environment. Design flows through into development, which in turn
flows into build, and finally on into test. Testing tends to happen towards the
end of the project life cycle so defects are detected close to the live
implementation date. With this model it has been difficult to get feedback
passed backwards up the waterfall and there are difficulties if we need to
carry out numerous iterations for a particular phase.

Iterative life cycles
Not all life cycles are sequential. There are also iterative or incremental life cycles where, instead of one large development
time line from beginning to end, we cycle through a number of smaller self-contained life cycle phases for the same
project. As with the V-model, there are many variants of iterative life cycles.
Examples of iterative or incremental development models are prototyping, Rapid Application Development (RAD), Rational
Unified Process (RUP) and agile development. For the purpose of better understanding iterative development models and the
changing role of testing a short explanation of both RAD and agile development is provided.
SOFTWARE LIFE CYCLE

Testing within a life cycle model
In summary, whichever life cycle model is being used, there are several
characteristics of good testing:
for every development activity there is a corresponding testing activity;
each test level has test objectives specific to that level;
the analysis and design of tests for a given test level should begin during the
corresponding development activity;
testers should be involved in reviewing documents as soon as drafts are avail able in
the development cycle.
SOFTWARE LIFE CYCLE

TEST LEVELS
Compare the different levels of testing: major objectives, typical objects of testing, typical targets of
testing (e.g. functional or structural) and related work products, people who test, types of defects and
failures to be identified. (K2)
The V-model for testing was introduced in Section 2.1. 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.
SOFTWARE LIFE CYCLE

Integration 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. Note that integration testing
should be differentiated from other integration activities. Integration testing is often carried out by the
integrator, but preferably by a specific integration tester or test team.
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.
SOFTWARE LIFE CYCLE

System 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 is most often the final test on behalf of
development to verify that the system to be delivered meets the specification and its purpose may be to
find as many defects as possible. Most often it is carried out by specialist testers that form a dedicated, and
sometimes independent, test team within development, reporting to the development manager or project
manager. In some organizations system testing is carried out by a third party team or by business analysts.
Again the required level of independence is based on the applicable risk level and this will have a high
influence on the way system testing is organized.
System testing should investigate both functional and non-functional requirements of the system.
Typical non-functional tests include performance and reliability. Testers may also need to deal with
incomplete or undocumented requirements. System testing of functional requirements starts by using the
most appropriate specification-based (black-box) techniques for the aspect of the system to be tested. For
example, a decision table may be created for combinations of effects described in business rules. Structure-
based (white-box) techniques may also be used to assess the thoroughness of testing elements such as
menu dialog structure or web page navigation (see Chapter 4 for more on the various types of technique).
SOFTWARE LIFE CYCLE

Acceptance 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 is most often the responsibility of the user or customer, although other stakeholders may be involved as
well. The execution of the acceptance test requires a test environment that is for most aspects, representative of the
production environment ('as-if production').
The goal of acceptance testing is to establish confidence in the system, part of the system or specific non-functional
characteristics, e.g. usability, of the system. Acceptance testing is most often focused on a validation type of testing,
whereby we are trying to determine whether the system is fit for purpose. Finding defects should not be the main focus in
acceptance testing. Although it assesses the system's readiness for deployment and use, it is not necessarily the final level
of testing. For example, a large-scale system integration test may come after the acceptance of a system.
Acceptance testing may occur at more than just a single level, for example:
• A Commercial Off The Shelf (COTS) software product may be acceptance tested when it is installed or integrated.
• Acceptance testing of the usability of a component may be done during component testing.
• Acceptance testing of a new functional enhancement may come before system testing.
SOFTWARE LIFE CYCLE

TEST TYPES: THE TARGETS OF TESTING
Compare four software test types (functional, non-functional, structural and change-related) by example. (K2)
Recognize that functional and structural tests occur at any test level. (Kl)
Identify and describe non-functional test types based on non-functional requirements. (K2)
Identify and describe test types based on the analysis of a software
system's structure or architecture. (K2)
Describe the purpose of confirmation testing and regression testing. (K2)
A test type is focused on a particular test objective, which could be the testing of a function to be performed by the
component or system; a non-functional quality characteristic, such as reliability or usability; the structure or architecture of
the component or system; or related to changes, i.e. confirming that defects have been fixed (confirmation testing, or re-
testing) and looking for unintended changes (regression testing). Depending on its objectives, testing will be organized
differently. For example, component testing aimed at performance would be quite different to component testing aimed at
achieving decision coverage.
SOFTWARE LIFE CYCLE

Testing throughout the software life cycle

More Related Content

What's hot (20)

Similar to Testing throughout the software life cycle (16)

Recently uploaded (20)

Testing throughout the software life cycle