Test planning

After test initiation by the project manager, the responsible test lead receives the test strategy and prepares a master test plan based on the test strategy document.

What is Test plan?

Test Plan describes the intended scope, approach, resources and schedule of testing activities.

Test Plan mainly describes the following
a. What to test - Scope for testing
b. How to test – In which Test environment it has to be tested
c. When to test – When to start/stop testing
d. Who to test – Responsible engineers for testing


Components in Test Plan Document:

As per IEEE format the test plan contains the following

a. Test Plan Id
b. Project Id
c. Introduction
d. Test items
e. Features to be tested
f. Features not be tested
g. Test approach
h. Entry criteria
i. Suspension criteria
j. Exit criteria
k. Test environment
l. Test deliverables
m. Staffing and training needs
n. Responsibilities
o. Schedule
p. Risks and mitigation
q. Approvals

Test initiation

Project Manager who is responsible to manage the project prepares a Test Strategy in this phase.

What is Test Strategy?

In general, strategy means making plans to achieve a goal.

The test strategy document focuses mainly on the following

a. Different types of testing that would be followed in the testing life cycle.
b. identifying risk issues etc, earlier so that progress can be evaluated more precisely
c. how testing is to be carried out and where special prominence on different aspects of the system has to be given so that best possible use of resource and time can be made use of. 

This test strategy also forms an important basis for an structured approach to testing which makes the testing process manageable.

Components in Test Strategy Document:

As per the IEEE standard Test strategy document contains the following

a. Scope and Objective
b. Business Issues
c. Test Approach
d. Roles and Responsibilities
e. Communication and Status Reporting
f. test deliverables
g. test automation and testing tools
h. Defect Reporting and Tracking
I. Testing measurements and metrics
j. Change and configuration management
k. Risks and assumptions
l. Training plan
m. test factors
n. Test Factors vs. Testing Techniques

Software Testing Life Cycle

Software Testing Life Cycle (STLC) refers to the steps involved in testing a software from release or in parallel to the development process. There are different stages and the activities to be done in each stage to bring out the quality product or software. 

The different stages are as below

~ Test initiation
~ Test planning
~ Test design
~ Test execution
~ Defect reporting and management
~ Test closure

V Model

According to the IEEE Standard Glossary of Software Engineering Terminology V&V is defined as the process of determining whether:

• Requirements for a system or component are complete and correct.
• Products of each development phase fulfill the requirements or conditions imposed by the previous phase.
• Final systems or components comply with specified requirements.

V-Model evolved from waterfall Model. Every phase must be completed before the next phase begins. Testing is done in all the phases. It is a structured approach to testing and brings high quality into the development of our products.

Stage containment:

The goal of stage containment is to identify defects in the system during development before they are passed to the next stage. This helps build quality into the system. Finding problems or errors in the stage they occur in is important because problems become more expensive and difficult to fix later in the project life cycle.

Requirement Analysis:

Business Analysts collect requirements from the customer and prepare a Business requirement specification (BRS) documents. Reviews are conducted to make sure that the requirements collected are accurate.

System Design:

Based on the BRS document, System engineers analyze and understand the business of the proposed system.Feasibility study is done on whether the requirements cab be implemented and is informed to the customer. System Requirements document containing the general system organization, menu structures, data structures, business scenarios, sample windows, reports for the better understanding and Other technical documentation like entity diagrams, data dictionary will be produced in this phase which serves as a blue print for the development phase. System testing documents are prepared in this phase

High Level Design:

A high level design document containing the list of modules, brief functionality of each module, their interface relationships, dependencies, database tables, architecture diagrams, technology details etc. The integration test plan is developed in this phase.

Module Level Design:

A Low Level design document containing detailed functional logic of the module, in pseudo code - database tables, with all elements, including their type and size - all interface details with complete API references- all dependency issues- error message listings- complete input and outputs for a module. The unit test plan is developed in this stage.

Unit testing

Unit testing is done based on Module level design document. A unit is the smallest testable software component. Units are tested in isolation to ensure it is working according to the detailed design/build specifications of the module. This testing is also known as component, module, or program testing. This is done by the developers.

Integration Testing

Testing of more than one (tested) unit together to determine if they function correctly is called Integration testing. This testing focuses on assembling incrementally a whole system to ensure the communication between modules and data flow from the first through the final component. This is also called interface testing or assembly testing. Integration testing is done based on High-level design document. This is done by the developers.

System Testing

Testing the complete system to determine if its working correctly as per the system design. Testers perform different types of functional, Non-functional and usability testing to ensure the functionality. System testing is done based on the system design document.

Acceptance testing

Testing to determine whether a system satisfies its acceptance criteria and business requirements or not. Testing is done the real users of the system.

Sprial Model

Spiral Model includes the best features of both the prototyping and waterfall model Software is developed in a series of incremental releases in the spiral model. At the early stage/iteration, the incremental release might be a paper model or prototype. Each iteration consists of Planning, Risk Analysis, Engineering, Construction & Release & Customer Evaluation

These regions include

Customer Communication task - Tasks required to establish effective communication between developer and customer

Planning task -Tasks required to define resources, timeliness, and other project related information.

Risk Analysis task - Tasks required to assess both technical and management risks.

Engineering task - Tasks required for building one or more representatives of the application.

Construction & Release task - (Tasks required to construct, test, install and provide user support e.g., documentation and training)

Customer Evaluation task - Tasks required to obtain customer feedback based on evaluation of the software representations created during the engineering stage and implemented during the installation state

The steps in the spiral model can be generalized as follows:

• New system requirements collected by interviewing a number of external or internal users and considering other aspects of the existing system are clearly defined 

• An initial design is created for the new system.
 

• Based on the initial design a first prototype of the new system is constructed
• Second prototype is evolved by a fourfold procedure:
 

(1) evaluating the first prototype in terms of its strengths, weaknesses, and risks;
(2) defining the requirements of the second prototype;
(3) planning and designing the second prototype;
(4) constructing and testing the second prototype.
 

• Entire project can be aborted at customer’s opinion if the risk is too high. Risk factors include development cost overruns, operating-cost miscalculation, or any other factor that could result in a less-than-satisfactory final product.
 

• The existing prototype is evaluated in the same manner as was the previous prototype, and, if necessary, another prototype is developed from it according to the fourfold procedure outlined above.
 

• The above steps are iterated until the customer is satisfied. The final system is constructed, based on the refined prototype.
 

• The final system is thoroughly evaluated and tested. Regular maintenance is carried out on a continuing basis to prevent large-scale failures and to reduce downtime.

Advantages:

• Provide better risk management
• Requirements are better defined

Disadvantages:

• Requires considerable risk assessment expertise
• Increases development costs and schedule

RAD Model

RAD is incremental software development process model that allows usable systems to be built in extremely short development cycle using a component based construction approach. If the requirements are well understood and defined, and the project scope is constraint, the RAD process enables a development team to create a fully functional system with in very short time period.

The RAD model contains the following phases:

1. Business Modeling:
The information flow among business functions is modeled in a way that answers questions like what information drives the business process, what information is generated, who generates it, where does the information go, who process it and so on.

2. Data Modeling:
The information defined as part of the business modeling phase is refined into a set of data objects (entities) that are needed to support the business. The characters of each entity (called attributes) are identified and the relation between these data objects (entities) are defined.

3. Process Modeling:
The data object defined in the data modeling phase are transformed to achieve the information flow necessary to implement a business function. Processing descriptions are created for adding, modifying, deleting or retrieving a data object.

4. Application Generation:
RAD assumes the use of RAD tools like VB, VC++, Delphi etc rather than creating software using conventional third 3G programming languages. RAD works to reuse the existing program, components or create reusable components.

5. Testing and Turn over:
As RAD process emphasizes reuse, many of the programs components have already been tested. This reduces overall testing time. But new components must be tested and all interfaces must be completely exercised.

Advantages

• Increased Speed - RAD reduces the development time as reusability of components help to speed up development. Modularized functions that makes easy to work with.

Disadvantages

• Reduced Scalability - As RAD focuses on development of a prototype that is iteratively developed into a full system, the delivered resolution may lack the scalability of a resolution that was designed as a full application from the start.
• Reduced Features - As RAD focuses on delivery of application in short time some of the features may be moved to later versions which results in incomplete application development.

Prototype Model

A prototype is toy implementation of the system. There are many reasons for developing a prototype. The main purpose is to illustrate the input data formats, messages, reports and the interactive dialogs to the customer. This is a valuable mechanism for gaining better understanding of the customer’s needs. Another main use of the prototyping model is that it helps critically examine the technical issues associated with the product development

In this model, once the requirement analysis is done and the quick design for a prototype is made, the development process gets started. Once the prototype is built it is given to the customer for evaluation. The customer tests the package and gives his feedback to the developer who then 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.

Advantages:

• Provides a toy model of the original system.
• Users have an idea of what the final system looks like
• Encourages active participation among customers and developers
• Efficiently identify problems
• Faster feedback from the customer

Disadvantages:

• Damage in the structure of the system because of many changes
• Difficult to document as the requirements keep on changing
• Excessive time and cost for developing a prototype.