Testing Throughout the Software Life Cycle part.2 - Andika Dwi Ary Candra

TESTING THROUGHOUT THE SOFTWARE LIFE
CYCLE
PART.2
ANDIKA DWI ARY CANDRA
SISTEM INFORMASI
SAINS AND TECHNOLOGY
UNIVERSITAS ISLAM NEGERI SULTAN SYARIF KASIM RIAU

2.2 Iterative life cycles
Not all life cycles are sequential. There are also iterative or incremental
cycles where, instead of one large development time line from beginning
end, we cycle through a number of smaller self-contained life cycle
the same project. As with the V-model, there are many variants of
cycles.

A common feature of iterative approaches is that the delivery is divided into
increments or builds with each increment adding new functionality. The initial increment
will contain the infrastructure required to support the initial build functionality. The
increment produced by an iteration may be tested at several levels as part of its
development. Subsequent increments will need testing for the new functionality,
regression testing of the existing functionality, and integration testing of both new and
existing parts. Regression testing is increasingly important on all iterations after the first
one. This means that more testing will be required at each subsequent delivery phase
which must be allowed for in the project plans.
This life cycle can give early market presence with critical functionality, can be
simpler to manage because the workload is divided into smaller pieces, and can reduce
initial investment although it may cost more in the long run. Also early market presence
will mean validation testing is carried out at each increment, thereby giving early
feedback on the business value and fitness-for-use of the product.
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

Rapid Application Development
Rapid Application Development (RAD) is formally a parallel
development of functions and subsequent integration.
Components/functions are developed in parallel as if they were mini
projects, the developments are time-boxed, delivered, and then assembled
into a working prototype. This can very quickly give the customer something
to see and use and to provide feedback regarding the delivery and their
requirements. Rapid change and development of the product is possible
using this methodology. However the product specification will need to be
developed for the product at some point, and the project will need to be
placed under more formal controls prior to going into production. This
methodology allows early validation of technology risks and a rapid response
to changing customer requirements.

Dynamic System Development Methodology [DSDM] is a
refined RAD process that allows controls to be put in place in order to
the process from getting out of control. Remember we still need to
essentials of good development practice in place in order for these
methodologies to work. We need to maintain strict configuration
management of the rapid changes that we are making in a number of
parallel development cycles. From the testing perspective we need to
this very carefully and update our plans regularly as things will be
very rapidly
The RAD development process encourages active customer
feedback. The customer gets early visibility of the product, can provide
feedback on the design and can decide, based on the existing
functionality, whether to proceed with the development, what
functionality to include in the next delivery cycle or even to halt the
project if it is not delivering the expected value. An early business-
focused solution in the market place gives an early return on
investment (ROI) and can provide valuable marketing information for
the business. Validation with the RAD development process is thus an
early and major activity.

Agile development
Extreme Programming (XP) is currently one of the most well-known agile
development life cycle models. (See [Agile] for ideas behind this approach.) The
methodology claims to be more human friendly than traditional development
methods. Some characteristics of XP are:
• It promotes the generation of business stories to define the functionality.
• It demands an on-site customer for continual feedback and to define and carry
out functional acceptance testing .
• It promotes pair programming and shared code ownership amongst the
developers.
• It states that component test scripts shall be written before the code is written
and that those tests should be automated.
• It states that integration and testing of the code shall happen several times a
day.
• It states that we always implement the simplest solution to meet today's
problems.

With XP there are numerous iterations each requiring testing.
XP developers write every test case they can think of and automate
them. Every time a change is made in the code it is component
tested and then integrated with the existing code, which is then
fully integration-tested using the full set of test cases. This gives
continuous integration, by which we mean that changes are
incorporated continuously into the software build. At the same time,
all test cases must be running at 100% meaning that all the test
cases that have been identified and automated are executed and
pass. XP is not about doing extreme activities during the
development process, it is about doing known value-adding
activities in an extreme manner.

Testing within a life cycle model
In summary, whichever life cycle model is being used,
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
begin during the corresponding development activity;
• testers should be involved in reviewing documents as
as drafts are avail able in the development 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.

From Section 2.2, you should know the typical levels of testing.
You should be able to compare the different levels of testing with
respect to their major objectives, typical objects of testing, typical
targets of testing (e.g. functional or structural) and related work
products. You should also know which persons perform the testing
activities at the various test levels, the types of defects found and
failures to be identified. You should know the glossary terms alpha
testing, beta testing, component testing, driver, functional
requirements, integration, integration testing, non-functional
functional testing, operational testing, regulation acceptance
acceptance testing (compliance testing), robustness testing, stub,
testing, stub, system testing, test-driven development, test
environment and user acceptance testing.

From Section 2.3, you should know the four major types of test
(functional, non-functional, structural and change-related) and should be
able to provide some concrete examples for each of these. You should
understand that functional and structural tests occur at any test level and be
able to explain how they are applied in the various test levels. You should be
able to identify and describe non-functional test types based on non-
functional requirements and product quality characteristics. Finally you
should be able to explain the purpose of confirmation testing (re-testing) and
regression testing in the context of change-related testing. You should know
the glossary terms black-box testing, code coverage, confirmation testing
(re-testing), functional testing, interoperability testing, load testing,
testing, maintainability testing, performance testing, portability testing,
testing, regression testing, reliability testing, security testing, specification-
specification-based testing, stress testing, structural testing, test suite,
suite, usability testing and white-box testing

BIBLIOGRAPHY
GRAHAM ET.AL.(2011). ISTBQ-FONDATION OF SOFTWARE
TESTING LONDON : CENGAGE LEARNING EMEA.

LINK:
HTTP://SIF.UIN-SUSKA.AC.ID/
HTTP://FST.UIN-SUSKA.AC.ID/
HTTP://WWW.UIN-SUSKA.AC.ID/

Testing Throughout the Software Life Cycle part.2 - Andika Dwi Ary Candra

More Related Content

What's hot (20)

Similar to Testing Throughout the Software Life Cycle part.2 - Andika Dwi Ary Candra (20)

Recently uploaded (20)

Testing Throughout the Software Life Cycle part.2 - Andika Dwi Ary Candra