This document discusses testing throughout the software development life cycle. It describes the V-model approach, which involves testing beginning early in the development process and continuing through later stages. The V-model includes four main test levels - component testing, integration testing, system testing, and acceptance testing - each with their own objectives to verify and validate different parts or the overall system. Testing activities should be carried out in parallel with development and involve collaboration between testers and developers.

1. Test design techniques and
Testing Throughout The Software Life
Cycle
Nama : MINI MARSIAH
Nim : 11453201774
Jurusan : SISTEM INFORMASI
Fakultas : SAINS DAN TEKNOLOGI
UNIVERSITAS ISLAM NEGERI SULTAN SYARIF KASIM RIAU

2. Testing may be performed with varying degrees of formality. Very formal testing would have
extensive documentation which is well controlled, and would expect the documented detail of
the tests to include the exact and specific input and expected outcome of the test. Very
informal testing may have no documentation at all, or only notes kept by individual testers,
but we'd still expect the testers to have in their minds and notes some idea of what they
intended to test and what they expected the outcome to be. Most people are probably
somewhere in between! The right level of formality for you depends on your context:
a commercial safety-critical application has very different needs than a one-off application to
be used by only a few people for a short time. outcome to be. Most people are probably
somewhere in between! The right level of formality for you depends on your context: a commercial
safety-critical application has very different needs than a one-off application to be used by only a few
people for a short time.
Formality of test documentation

3. • Test analysis is the process of looking at something that can be used to derive test
information. This basis for the tests is called the 'test basis'. It could be a system
requirement, a technical specification, the code itself (for structural testing), or a business
process. Sometimes tests can be based on an experienced user's knowledge of the system,
which may not be documented. The test basis includes whatever the tests are based on.
This was also discussed in Chapter 1. From a testing perspective, we look at the test basis
in order to see what could be tested – these are the test conditions. A test condition is
simply something that we could test. If we are looking to measure coverage of code
decisions (branches), then the test basis would be the code itself, and the list of test
conditions would be the decision outcomes (True and False). If we have a requirements
specification, the table of contents can be our initial list of test conditions.
•
Test analysis: identifying test conditions

4. • Test conditions can be rather vague, covering quite a large range of possibilities
as we saw with our mobile phone company example (e.g. a teenager in the mid-
west), or a test condition may be more specific (e.g. a particular male customer
on pay-as-you-go with less than $10 credit). However when we come to make a
test case, we are required to be very specific; in fact we now need exact and
detailed specific inputs, not general descriptions (e.g. Jim Green, age 17, living in
Grand Rapids, Michigan, with credit of $8.64, expected result: add to Q4
marketing campaign). Note that one test case covers a number of conditions
(teenager, male, mid-west area, pay-as-you-go, and credit of less than $10).
Test design: specifying test cases

5. • The next step is to group the test cases in a sensible way for executing
them and to specify the sequential steps that need to be done to run the
test. For example, a set of simple tests that cover the breadth of the system
may form a regression suite, or all of the tests that explore the working of
a given functionality or feature in depth may be grouped to be run
together.
Test implementation: specifying test procedures or scripts

6. 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.

7. V-model
• The V-model was developed to address some of the problems experienced using the
traditional waterfall approach. Defects were being found too late in the life cycle, as
testing was not involved until the end of the project. Testing also added lead time due to
its late involvement. The V-model provides guidance that testing needs to begin as early
as possible in the life cycle, which, as we've seen in Chapter 1, is one of the fundamental
principles of structured testing. It also shows that testing is not only an execution-based
activity. There are a variety of activities that need to be performed before the end of the
coding phase. These activities should be carried out in parallel with development
activities, and testers need to work with developers and business analysts so they can
perform these activities and tasks and produce a set of test deliverables.

9. 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.