Testing is a Process, not just a Phase

Should Testing just be another Phase?

We all accept that Testing forms an important part of the software development life cycle (SDLC). However, the reason why a lot of organizations fail is the fact that they segregate testing as a single unit – a phase. When Testing is treated as just another ‘phase’, the implementation of this business-critical task suffers. Organizations try to club all sorts of tests and try to test their product for all possible areas at the fag-end of the development cycle. This naturally is impacted by the looming deadlines of the product launch, as also other pressures due to which the testing is not fool-proof. A product that has not been tested fully will naturally not be robust. There will always be a doubt regarding its security, performance, and functionality. So what can these organizations do to improve their testing process?

The answer is actually fairly simple.

Instead of trying to overburden the tester to test for completeness just before launching the product, plan your test related activities. While planning the product development phases, identify the types of tests you need to execute for your product. Then, allocate specific time and resources for performing tests related to the different phases. This also helps verifying and validating the product, as also drastically reduces the number of bugs that may otherwise be found later. Performing tests specific to a phase helps save a lot of time and efforts of the developers as the issues found are far easier to fix.

In essence, if we treat Testing as a process that supports the entire development process – instead of just a single phase – we can ensure products that are far more dependable and robust.

What to Test under each phase?

Based on the common experience shared across industries, following are a few tests that can be executed under the different phases:

1. Requirements Gathering phase: The main focus of this phase is to gather the business requirements such as who will use what type of data in what manner. Thus, it is only common sense to test and confirm (read validate) the basic requirements for the creation of a product before actually starting the development process. This ensures that we create what we initially planned to create – and not something else that got created while on the way due to unclear and ambiguous requirements. The output of this phase is a Requirement Specification document that acts as the guideline for the product development.
2. Design phase: The Design phase uses the Requirement Specification document to prepare the layout of the system and software design. If a comprehensive and end-to-end test plan and strategy is thought of and implemented in this phase, it will help build a stable system architecture. Testing the ease of design will also help establish what and how to test in the product.
3. Development phase: As the name suggests, the development phase involves the actual writing of code for the different modules. As a lot of code is generated in this phase that covers implementation of different features, it makes sense to test the features being developed. It also is a good time to implement regression testing on the code generated so far to verify that the software being developed performs correctly even if it is modified or interfaced with other software.
4. Deployment phase: The deployment phase usually has two sub-phases – Beta-deployment, and Final Deployment. In the Beta-deployment phase issues are caught before a product is launched to the market. This is the time when you can implement tests related to product usage analytics, Real User Monitoring, & Automated smoke tests. Based on the results of these tests, and the other issues reported, the development team will make the final changes before the final deployment of the product.

As seen above, if Testing is implemented across all the phases of SDLC, the end result will be a product that is stable, reliable, and supports features and functions that will grab the attention of the end user. It is no surprise that the more a product is liked and appreciated, the better ROI an organization gets.