2.1 Software Development & Testing Models (K2)

Testing does not exist in isolation; test activities are related to software development activities.
Different development life cycle models need different approaches to testing.


Waterfall Model                      
A software process model is an abstract representation of software. The basic concept of the waterfall model considers software development as a sequence of stages, and that software developers must clearly delineate the stages: First we design and after we finish designing, we begin coding. After we finish coding, we begin the testing and after we finish the testing, we deploy.

Using the Waterfall Model has some advantages. The testing is inherent to every phase of the model. We use an enforced discipline approach. We produce documentation at every stage.

Requirements in software change more often and more rapidly than in other engineering disciplines. In the Waterfall Model, the biggest challenge is that we must have complete requirements from the customers right from the start. Thus it is hard to modify and implement changes.




Fig. 3: V-Model

 The above figure shows V-Model testing. Every phase of the Testing Life Cycle (TLC) in this model corresponds to some activity in the Software Development Life Cycle (SDLC). The V proceeds from left to right, depicting the basic sequence of development and testing activities. This model highlights the existence of several levels of testing and depicts the way each relates to a different development phase.

We use the output of requirement analysis, the requirement specification document, as the input for writing system level test cases. We use the output of the design phase of SDLC, the design specification document, as the input for writing integration level test cases. We use the Program specifications created, as an input for writing unit level test cases.

Inspite of these activities, the testing activity formally starts at the end of the Coding phase or the Unit Testing activity by the developers. Note that V-model does not say that testing activity must formally start after coding. It is just a mapping of development phase with respect to various testing levels.

As a key point, we must conduct testing in conjunction with V diagram phases to minimize the testing effort in later stages.


When we do the designing later, fixings the defects found in requirement specification becomes more expensive. The program requires a lot of rework in all the subsequent stages in SDLC.



Fig. 4: Early Test Design


Ideally, the tests must be designed as early as possible. The earlier a defect is found, the cheaper the cost to fix it. Early design of tests leads to early finding of defects and hence makes it cheaper to fix defects. It also prevents defect multiplication because it prevents defects from leaking into the next stage. E.g. we can prevent a defect in the coding by finding it in the design stage. This ensures better quality and less time in running tests because fewer defects are found. This results in an overall cost and effort reduction.

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.
Software work products (such as business scenarios or use cases, requirement specifications, design documents and code) produced during development are often the basis of testing in one or more test levels. References for generic work products include Capability Maturity Model Integration (CMMI) or ‘Software life cycle processes’ (IEEE/IEC 12207). Verification and validation (and early test design) can be carried out during the development of the software work products.
Verification, Validation and Testing 
Verification and Validation, denoted as V and V, assures that a software system meets the needs of the users.

Verification is defined as a ‘process of evaluating a system or its components, to determine whether the products of the given development phase, satisfy the conditions imposed at the start of that phase’. In other words, the software must conform to its specification. Verification ensures that each function works correctly. Verification checks the quality of the built product’. In other words, we check that we built the product right.

Validation is defined as ‘the determination of the correctness of the products of software development with respect to the user needs and requirements’. Validation is the process of evaluating a system or a component, during or at the end of the development process, to determine whether it satisfies the specified requirements. Validation ensures that the system has implemented each of the requirements and that we can trace back each of the system functions to a particular requirement. In other words, we check that we have built the right product.

The following diagram indicates the V&V activities that can be conducted during a typical SDLC.. Please note although the following diagram is similar to the v-model, it is just a representation of the major development and testing phases  and there relevant  V & V activities





The Impact of Early Test Design on SDLC
By designing test cases early, we can specify the order in which to develop the software before we build it. This helps in executing the testing and development process in a parallel fashion. This enables us to have total test execution schedules of a shorter duration and gives a more even distribution of test effort across the SDLC.


2.1.2 Iterative-Incremental development models (K2)   
Iterative-Incremental development is the process of establishing requirements, designing, building and testing a system, done as a series of shorter development cycles. Examples are: prototyping, rapid application development (RAD) and agile development models. The resulting system produced by an iteration may be tested at several levels as part of its development. An increment, added to others developed previously, forms a growing partial system, which should also be tested. Regression testing is increasingly important on all iterations after the first one. Verification and validation can be carried out on each increment.

Prototyping Model is a systems development method (SDM) in which a prototype (an early approximation of a final system or product) is built, tested, and then reworked as necessary until an acceptable prototype is finally achieved from which the complete system or product can now be developed. This model works best in scenarios where not all of the project requirements are known in detail ahead of time. It is an iterative, trial-and-error process that takes place between the developers and the users.
There are several steps in the Prototyping Model:
1. The new system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the departments or aspects of the existing system.
2. A preliminary design is created for the new system.
3. A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product.
4. The users thoroughly evaluate the first prototype, noting its strengths and weaknesses, what needs to be added, and what should to be removed. The developer collects and analyzes the remarks from the users.
5. The first prototype is modified, based on the comments supplied by the users, and a second prototype of the new system is constructed.
6. The second prototype is evaluated in the same manner as was the first prototype.
7. The preceding steps are iterated as many times as necessary, until the users are satisfied that the prototype represents the final product desired.
8. The final system is constructed, based on the final prototype.
9. The final system is thoroughly evaluated and tested. Routine maintenance is carried out on a continuing basis to prevent large-scale failures and to minimize downtime.

RAD
RAD is an acronym for Rapid Application Development. As the name suggests this methodology deals with developing applications within a very short time frame. This is achieved by a number of ways like :
§ collecting all the requirements right at the beginning so that the delivered application is complete
§ Making use of programming systems which have rich features to reduce the development time
§ Making use of reusable components instead of coding the entire application
§ Making use of COTS ( explained below)

COTS
COTS is an acronym for Commercial off-the-shelf software. COTS  based systems are systems wherein multiple off-the shelf parts from multiple suppliers are integrated to achieve new or expanded system functionality.

The main advantage of COTS based systems is that the delivery time and cost is reduced because of the reduced total development time.

The challenges of COTS based systems are as follows :
§ Limited visibility into the COTS code and behaviour
§ Limited control of frequency or content of COTS releases
§ ‘New Business’ issues like licensing, data rights, warranties
§ Frequent, continual change of COTS products and market place
§ COTS products are driven by the marketplace and not by the systems whose  development is based on them
§ Dependencies between components to be moved to the proper location.

Agile methodology is a development methodology which attempts to minimize risk by developing software in short time boxes, called iterations. Each iteration is like a miniature software project of its own. It includes all the tasks necessary to release the mini-increment of new functionality: planning, requirements analysis, design, coding, testing, and documentation. While an iteration may not add enough functionality to warrant releasing the product, an agile software project intends to be capable of releasing new software at the end of every iteration. At the end of each iteration, the team reevaluates project priorities. Agile methods emphasize real-time communication, preferably face-to-face, over written documents

Most agile teams are located in a bullpen and include all the people necessary to finish software. At a minimum, this includes programmers and their "customers." (Customers are the people who define the product. They may be product managers, business analysts, or actual customers.) The bullpen may also include testers, interaction designers, technical writers, and management.

Agile methods also emphasize working software as the primary measure of progress. Combined with the preference for face-to-face communication, agile methods produce very little written documentation relative to other methods. This has resulted in criticism of agile methods as being undisciplined hacking.

RUP
RUP is an acronym for Rational Unified Process. It  is a Software Engineering Process. Its goal is to ensure the production of high-quality software that meets the needs of its end-users, within a predictable schedule and budget. It is observed that most of projects take a longer development time because of improper communication amongst development teams and also between development teams and customers. RUP aims at improving this by the following means :
§ providing a disciplined approach to assigning tasks and responsibilities within a development organization
§ providing every team member with easy access to a knowledge base with guidelines, templates and tool mentors for all critical development activities
§ ensuring that all team members share a common language, process and view of how to develop software
§ focusing on creating and maintaining models (semantically rich representations of the software system under development) rather than focusing on production of large amount of paper documents
§ using UML (Unified Modeling language) which is a industry-standard language that allows to clearly communicate requirements, architectures and designs.
  
2.1.3Testing within a life cycle model (K2)
In any life cycle model, there are several characteristics of good testing:
§ For every development activity there is a corresponding testing activity

 Eg in V-model we use the output of requirement analysis, the requirement specification document, as the input for writing system level test cases.

§ Each test level has test objectives specific to that level.
Eg  in  iterative development model, the objective of testing at the proto-type level is to get the application flow and GUI reviewed by the user.

§ The analysis and design of tests for a given test level should begin during the corresponding development activity.
Eg. The analysis and design of system test should begin after the requirement specifications are ready and high-level design is in progress. This will help to find out gaps, if any , in requirements,  early enough.

§ Testers should be involved in reviewing documents as soon as drafts are available in the development life cycle.
Eg If the testers are involved in reviewing the draft program specifications, they can find out topics missed out and also ensure that the document is written in an unambiguous way. If this is not done then there is a possibility that the missed out requirements are not discovered until the User acceptance testing phase and / or the developers misinterpret the specifications while coding and the coding defects may get detected during component/unit
testing.

Test levels can be combined or reorganized depending on the nature of the project or the system
architecture. For example, for the integration of a commercial-off-the-shelf (COTS) software product into a system, the purchaser may perform integration testing at the system level (e.g. integration to the infrastructure and other systems, or system deployment) and acceptance testing (functional and/or non-functional, and user and/or operational testing).


0 comments:

Post a Comment