![V-Model
Note that the types of work products mentioned in Figure 2.2 on the left side
of the V-model are just an illustration. In practice they come under many different
names. References for generic work products include the Capability Maturity Model
Integration (CMMi) or the 'Software life cycle processes' from ISO/IEC 12207. The CMMi
is a framework for process improvement for both system engineering and software
engineering. It provides guidance on where to focus and how, in order to increase the
level of process maturity [Chrissis et ah, 2004]. ISO/IEC 12207 is an integrated
software life cycle process standard that is rapidly becoming more popular.](https://image.slidesharecdn.com/ppt2-171130165644/85/Testing-Throughout-The-Software-Life-Cycle-8-320.jpg)
![Iterative life cycles[a1]
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.
[a2]
[
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.](https://image.slidesharecdn.com/ppt2-171130165644/85/Testing-Throughout-The-Software-Life-Cycle-9-320.jpg)
![Dynamic System Development Methodology [DSDM] is a refined RAD process
that allows controls to be put in place in order to stop the process from getting out of
control. Remember we still need to have the 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 plan this very
carefully and update our plans regularly as things will be changing very rapidly (see
Chapter 5 for more on test plans).
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.](https://image.slidesharecdn.com/ppt2-171130165644/85/Testing-Throughout-The-Software-Life-Cycle-11-320.jpg)
![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:
a) It promotes the generation of business stories to define the functionality.
b) It demands an on-site customer for continual feedback and to define and carry out
functional acceptance testing .
c) It promotes pair programming and shared code ownership amongst the developers.
d) It states that component test scripts shall be written before the code is written and that
those tests should be automated.
e) It states that integration and testing of the code shall happen several times a day.
f) 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.](https://image.slidesharecdn.com/ppt2-171130165644/85/Testing-Throughout-The-Software-Life-Cycle-12-320.jpg)
Testing Throughout The Software Life Cycle
- 1. Program Studi S1 Sistem Informasi Fakultas Sains dan Teknologi Universitas Islam Negeri Sultan Syarif Kasim Riau
- 2. Testing Throughout The Software Life Cycle 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.
- 3. 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) 1.SOFTWARE DEVELOPMENT MODELS
- 4. 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. The life cycle model that is adopted for a project will have a big impact on the testing that is carried out. Testing does not exist in isolation; test activities are highly related to software development activities. It will define the what, where, and when of our planned testing, influence regression testing, and largely determine which test techniques to use. The way testing is organized must fit the development life cycle or it will fail to deliver its benefit. If time to market is the key driver, then the testing must be fast and efficient. If a fully documented software development life cycle, with an audit trail of evidence, is required, the testing must be fully documented. In every development life cycle, a part of testing is focused on verification testing and a part is focused on validation testing. Verification is concerned with evaluating a work product, component or system to determine whether it meets the requirements set. In fact, verification focuses on the question 'Is the deliverable built according to the specification?'. Validation is concerned with evaluating a work product, component or system to determine whether it meets the user needs and requirements. Validation focuses on the question 'Is the deliverable fit for purpose, e.g. does it provide a solution to the problem?'.
- 5. 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. V-model
- 7. 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. The various test levels are explained and discussed in detail in Section 2.2. In practice, a V-model may have more, fewer or different levels of development and testing, depending on the project and the software product. For example, there may be component integration testing after component testing and system integration testing after system testing. Test levels can be combined or reorganized depending on the nature of the project or the system architecture. For the integration of a commercial off-the-shelf (COTS) software product into a system, a purchaser may perform only integration testing at the system level (e.g. integration to the infrastructure and other systems) and at a later stage acceptance testing.
- 8. V-Model Note that the types of work products mentioned in Figure 2.2 on the left side of the V-model are just an illustration. In practice they come under many different names. References for generic work products include the Capability Maturity Model Integration (CMMi) or the 'Software life cycle processes' from ISO/IEC 12207. The CMMi is a framework for process improvement for both system engineering and software engineering. It provides guidance on where to focus and how, in order to increase the level of process maturity [Chrissis et ah, 2004]. ISO/IEC 12207 is an integrated software life cycle process standard that is rapidly becoming more popular.
- 9. Iterative life cycles[a1] 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. [a2] [ 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.
- 10. 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.
- 11. Dynamic System Development Methodology [DSDM] is a refined RAD process that allows controls to be put in place in order to stop the process from getting out of control. Remember we still need to have the 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 plan this very carefully and update our plans regularly as things will be changing very rapidly (see Chapter 5 for more on test plans). 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.
- 12. 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: a) It promotes the generation of business stories to define the functionality. b) It demands an on-site customer for continual feedback and to define and carry out functional acceptance testing . c) It promotes pair programming and shared code ownership amongst the developers. d) It states that component test scripts shall be written before the code is written and that those tests should be automated. e) It states that integration and testing of the code shall happen several times a day. f) 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.
- 13. Testing within a life cycle model In summary, whichever life cycle model is being used, there are several characteristics of good testing: a) for every development activity there is a corresponding testing activity; b) each test level has test objectives specific to that level; c) the analysis and design of tests for a given test level should begin during the corresponding development activity; d) testers should be involved in reviewing documents as soon as drafts are avail able in the development cycle.
- 14. http://sif.uin-suska.ac.id http://fst.uin-suska.ac.id http://www.uin-suska.ac.id Website Resmi Kampus Universitas Islam Negeri Sultan Syarif Kasim Riau