Test Preparation Process Baseline Documents Construction of an application and testing are done using certain documents.

These documents are written in sequence, each of it derived from the previous document. Business Requirement This document describes user’s needs for the application. This is done over a period of time, and going through various levels of requirements. This should also portrays functionality that are technically feasible within the stipulated times frames for delivery of the application. As this contains user perspective requirements, User Acceptance Test is based on this document. How to read a Business Requirement? In case of the Integrated Test Process, this document is used to understand the user requirements and find the gaps between the User Requirement and Functional Specification. User Acceptance Test team should break the business requirement document into modules depending on how the user will use the application. While reading the document, test team should put themselves as end users of the application. This document would serve as a base for UAT test preparation. Functional Specification This document describes the functional needs; design of the flow and user maintained parameters. These are primarily derived from Business Requirement document, which specifies the client’s business needs. The proposed application should adhere to the specifications specified in this document. This is used henceforth to develop further documents for software construction and validation and verification of the software. In order to achieve synchronization between the software construction and testing process, Functional Specification (FS) serves as the Base document. How to read a Functional Specification? The testing process begins by first understanding the functional specifications. The FS is normally divided into modules. The tester should understand the entire functionality that is proposed in the document by reading it thoroughly. It is natural for a tester at this point to get confused on the total flow and functionality. In order to overcome these, it is advisable for the tester to read the document multiple times, seeking clarifications then and there until clarity is achieved.

Testers are then given a module or multiple modules for validation and verification. These modules then become the tester’s responsibility. The Tester should then begin to acquire an in-depth knowledge of their respective modules. In the process, these modules should be split into segments like field level validations, module rules, business rules etc. In order to do the same module’s importance and precisely the tester should interpret its role within the application. A high level understanding of the data requirements for respective modules is also expected from the tester at this point. Interaction with test lead at this juncture is crucial to draw a testing approach, like an end-to-end test coverage or individual test. (Explained later in the document) Tester’s Reading Perspective Functional specification, is sometimes written assuming some level of knowledge of the Testers and constructors. We can categorize the explanations by Explicit Rules: Functionality expressed as conditions clearly in writing, in the document. Implicit Rules: Functionality that is implied based on what is expressed as a specification/condition or requirement of a user. The tester must also bear in mind, the test type i.e. Integrated System Testing (IST) or User Acceptance Testing (UAT). Based on this, he should orient his testing approach. Design Specification This document is prepared based on the functional specification. It contains the system architecture, table structures and program specifications. This is ideally prepared and used by the construction team. The Test Team should also have a detailed understanding of the design specification in order to understand the system architecture. System Specification This document is a combination of functional specification and design specification. This is used in case of small applications or an enhancement to an application. Under such situations it may not be advisable make two documents

SDLC MODELS: Waterfall Model This is the most common and classic of life cycle models, also referred to as a linear-sequential life cycle model. It is very simple to understand and use. In a waterfall model, each phase must be completed in its entirety before the next phase can begin. At the end of each phase, a review takes place to determine if the project is on the right path and whether or not to continue or discard the project. Unlike what I mentioned in the general model, phases do not overlap in a waterfall model.

Advantages: * Simple and easy to use. * Easy to manage due to the rigidity of the model – each phase has specific deliverables and a review process. * Phases are processed and completed one at a time. * Works well for smaller projects where requirements are very well understood Disadvantages: * Adjusting scope during the life cycle can kill a project * No working software is produced until late during the life cycle.

* High amounts of risk and uncertainty. * Poor model for complex and object-oriented projects. * Poor model for long and ongoing projects. * Poor model where requirements are at a moderate to high risk of changing. Spiral Model The spiral model is similar to the incremental model, with more emphases placed on risk analysis. The spiral model has four phases: Planning, Risk Analysis, Engineering and Evaluation. A software project repeatedly passes through these phases in iterations (called Spirals in this model). The baseline spiral, starting in the planning phase, requirements is gathered and risk is assessed. Each subsequent spiral builds on the baseline spiral. Requirements are gathered during the planning phase. In the risk analysis phase, a process is undertaken to identify risk and alternate solutions. A prototype is produced at the end of the risk analysis phase. Software is produced in the engineering phase, along with testing at the end of the phase. The evaluation phase allows the customer to evaluate the output of the project to date before the project continues to the next spiral. In the spiral model, the angular component represents progress, and the radius of the spiral represents cost. Advantages: * High amount of risk analysis * Good for large and mission-critical projects. * Software is produced early in the software life cycle Disadvantages * * * * Can be a costly model to use. Risk analysis requires highly specific expertise. Project’s success is highly dependent on the risk analysis phase. Doesn’t work well for smaller projects.

Spiral Model

V-Shaped Model Just like the waterfall model, the V-Shaped life cycle is a sequential path of execution of processes. Each phase must be completed before the next phase begins. Testing is emphasized in this model more so than the waterfall model though. The testing procedures are developed early in the life cycle before any coding is done, during each of the phases preceding implementation. Requirements begin the life cycle model just like the waterfall model. Before development is started, a system test plan is created. The test plan focuses on meeting the functionality specified in the requirements gathering. The high-level design phase focuses on system architecture and design. An integration test plan is created in this phase as well in order to test the pieces of the software systems ability to work together. The low-level design phase is where the actual software components are designed, and unit tests are created in this phase as well. The implementation phase is, again, where all coding takes place. Once coding is complete, the path of execution continues up the right side of the V where the test plans developed earlier are now put to use.

Advantages: * Simple and easy to use. * Each phase has specific deliverables. * Higher chance of success over the waterfall model due to the development of test plans early on during the life cycle. * Works well for small projects where requirements are easily understood. Disadvantages: * Very rigid, like the waterfall model. * Little flexibility and adjusting scope is difficult and expensive. * Software is developed during the implementation phase, so no early prototypes of the software are produced. * Model doesn’t provide a clear path for problems found during testing phases. Prototyping Model This is a cyclic version of the linear model. In this model, once the requirement analysis is done and the design for a prototype is made, the development process gets started. Once the prototype is created, it is given to the customer for evaluation. The customer tests the package and gives his/her feed back to the developer who refines the product according to the customer's exact expectation. After a finite number of iterations, the final software package is given to the customer. In this methodology, the software is evolved as a result of periodic shuttling of information between the customer and developer. This is the most popular development model in the contemporary IT industry. Most of the successful software products have been developed using this model - as it is very difficult (even for a whiz kid!) to comprehend all the requirements of a customer in one shot. There are many variations of this model skewed with respect to the project management styles of the companies. New versions of a software product evolve as a result of prototyping.

Advantages: * May provide the proof of concept necessary to attract funding * Early visibility of the prototype gives users an idea of what the final system looks like * Encourages active participation among users and producer * Enables a higher output for user * Cost effective (Development costs reduced) * Increases system development speed * Assists to identify any problems with the efficacy of earlier design, requirements analysis and coding activities * Helps to refine the potential risks associated with the delivery of the system being developed Disadvantages: * User’s expectation on prototype may be above its performance * Possibility of causing systems to be left unfinished * Possibility of implementing systems before they are ready. * Producer might produce a system inadequate for overall organization needs * Producer might get too attached to it (might cause legal involvement) * Often lack flexibility * Not suitable for large applications * Project management difficulties

Rapid Application Development (RAD) Model: The RAD models a linear sequential software development process that emphasizes an extremely short development cycle. The RAD model is a "high speed" adaptation of the linear sequential model in which rapid development is achieved by using a component-based construction approach. Used primarily for information systems applications, the RAD approach encompasses the following phases: 1. Business modeling The information flow among business functions is modeled in a way that answers the following questions: What information drives the business process? What information is generated? Who generates it? Where does the information go? Who processes it? 2. Data modeling The information flow defined as part of the business modeling phase is refined into a set of data objects that are needed to support the business. The characteristic (called attributes) of each object is identified and the relationships between these objects are defined. 3. Process modeling The data objects defined in the data-modeling phase are transformed to achieve the information flow necessary to implement a business function. Processing the descriptions are created for adding, modifying, deleting, or retrieving a data object. 4. Application generation The RAD model assumes the use of the RAD tools like VB, VC++ and Delphi etc... Rather than creating software using conventional third generation programming languages. The RAD model works to reuse existing program components (when possible) or create reusable components (when necessary). In all cases, automated tools are used to facilitate construction of the software.

5. Testing and turnover Since the RAD process emphasizes reuse, many of the program components have already been tested. This minimizes the testing and development time. MADHU BABU…………………..

Sign up to vote on this title
UsefulNot useful