Many organizations postpone all software testing activities to the end of development, after the implementation has started, or even after implementation has ended. By waiting until late in the process, testing ends up compromised. Not enough resources (time or budget) remain, problems with previous stages have been solved by taking time and dollars from testing, and we do not have enough time to plan for testing. Instead of planning and designing tests, the developers have time only to run tests, usually in an ad hoc manner. However, a tester cannot show up at the last minute and make a bad product good; high quality has to be part of the process from the beginning.
This article discusses how to integrate testing with development, where testing activities begin as soon as development activities begin, and are carried out in parallel with the development stages. Specific activities, including planning, active testing, and development-influencing activities, allow the tester to detect and prevent faults throughout the software development process.
For most stages, the testing activities can be broken into three broad categories: test actions–testing the product or artifacts created at that stage; test design–using the development artifacts of that stage or testing artifacts from a previous stage to prepare to test the final software; and test influence–using development or test artifacts to influence future development stages.
1. Requirements analysis and specification
A software requirements and specifications document contain a description of the external behaviour of the software system. It provides a way to communicate with the other stages of the development and defines the contents and boundary of the software system. The major test action goal is to evaluate the requirements themselves. Many methods have been presented to do this, most commonly inspections and prototyping. Further, the test design goal is to prepare for system testing and verification activities and test influence goal is to influence the software architectural design.
2. System and software design
System and software design partitions the requirements into hardware or software systems and builds the overall system architecture. The software design should represent the software system functions so that they can be transformed into executable programs or program components.
The goals should be-
- To verify the mapping between the requirements specification and the design.
- To prepare for acceptance and usability testing.
- To influence the design of the user interface.
3. Intermediate design
In intermediate design, the software system is broken into components, and then classes are associated with each component. Design specifications are written for each component and class. Many problems in large software systems arise from component interface mismatches. The major test action goal is to avoid mismatches of interfaces and to prepare for unit testing, integration testing, and system testing by writing the test plans.
4. Detailed design
At the detailed design stage, testers write subsystem specifications and pseudo-code for modules. The major test action goal at the detailed design stage is to make sure that all test materials are ready for testing when the modules are written. Testers should prepare for both unit and integration testing. Testers must refine detailed test plans, generate test cases for unit testing, and write detailed test specifications for integration testing.
Eventually, the programmers start writing and compiling classes and methods. The major test action goal is to perform effective and efficient unit testing. The effectiveness of unit testing is largely based on the coverage criterion used and test data generated. Unit testing performed at this stage is as specified by the unit test plan, test criteria, test cases, and test support tools that were made ready at the earlier stages. The major test design goal is to prepare for integration and system testing.
Integration and integration testing begin as soon as the needed components of an integrated subsystem pass unit testing. A simple way to decide what order to integrate and test classes is to integrate them as soon as they are delivered from unit testing. Although a convenient default, this can lead to significantly more work during integration testing—similar to maintenance debt. A better approach is to decide ahead of time what order classes should be delivered for the most efficient integration, and encourage the developers to complete in that order. Integration testing itself is concerned with finding errors that result from unexpected interactions among components.
7. System deployment
At this stage, the action goal is to perform system testing, acceptance testing and usability testing. System testing compares the software system to its original objectives, in particular, validating whether the software meets the functional and non-functional requirements. System test cases are developed from the system and project test plan from the requirements specification and software design phase. Acceptance testing ensures that the complete system satisfies the customers’ needs, and should be done with their involvement. On the other hand, usability testing evaluates the user interface of the software. It should also be done with user involvement.
8. Operation and maintenance
After the software is deployed, users will find new problems and request new features. When the software is changed, it must be regression tested. Regression testing helps ensure that the updated software still possesses the functionality it had before the updates, as well as the new or modified functionality.
Testing has different objectives during each stage, and these objectives are achieved in different ways. These sub-objectives of testing at each stage will then help achieve the overall objective of ensuring high-quality software.
Give us 30 minutes and we will show you how many millions you can save by outsourcing software testing. Make Your product quality top notch. Talk to us to see how