1.testing Throughout The Software Life Cycle
1.testing Throughout The Software Life Cycle
1.testing Throughout The Software Life Cycle
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. Each of these methodologies has its place in modern
software development and the most appropriate development process should be applied to each
project. The models specify the various stages of the process and the order in which they are
carried out.
A. V-MODEL
Although variants of the V-model exist, a common type of V-model uses four test levels. The
four test levels used, each with their own objectives, are:
• component testing: searches for defects in and verifies the functioning of software
components (e.g. modules, programs, objects, classes etc.) that are separately testable;
• integration testing: tests interfaces between components, interactions to different parts of a
system such as an operating system, file system and hard ware or interfaces between systems;
• system testing: concerned with the behavior of the whole system/product as defined by the
scope of a development project or product. The main focus of system testing is verification
against specified requirements;
• acceptance testing: validation testing with respect to user needs, require ments, and
business processes conducted to determine whether or not to accept the system.
2.1.2 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.
RAPID APPLICATION DEVELOPMENT
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.
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.
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.
REFERENSI
http://www.uin-suska.ac.
id/
http://sif.uin-suska.ac.id
http://fst.uin-susk
a.ac.id