A product life cycle (PLC) depicts the series of stages involved in the development of the product. These stages of software development involve various testing methodologies and procedures, and test automation has come to the fore as a formula to reduce the overall costs and enhance quality. However, effectively analyzing the need and accordingly integrating the automation testing to the traditional stages of PLC is a complex phenomenon, and is not a standalone effort. It runs parallel to the software development stages, and entails resources and schedules to be synergized in a coherent manner. Moreover, there are rules and limitations to its application at various stages of PLC that needs to be abided by for maximum benefits. Let us reflect on the applicability of automation testing at different stages of the SDLC.
Design Stage: The stage is too early for the automation process because changes are bound to happen as we progress. With automated test scripts, it is difficult to implement these changes and the script may have to be completely scrapped off and redone, adding to the unnecessary load. Creating manual test cases is thus a vital element here. These cases also set the stage for a consistent format and workflow clarifying the project requirements along with highlighting the parts that may be problematic in the future. Based on these formalized manual testing processes already in place, the QA automation tools and tests can be roughly decided at this stage for the entire project along with clarification on the scope of automation QA required. Hence, at this stage, the role of automation shall be quite limited.
Build Stage: At this stage, the code is complete yet not debugged. This is the stage where the process of writing automated test cases should commence. The initial tests should be able to judge the overall status of the product but should not be too exhaustive. They should verify that critical functionalities of the program are working fine, and the product is stable and ready for further fine grained testing. Before this stage is complete, it is also important to finalize the manual tests processes that must be automated for the future use, and the QA automation tools required for the testing purposes. The right mix of recording or scripting modes to be used needs to be decided at this stage. This should be a meticulous process or you may end up incurring higher costs and spending more time than required. Now the product shall be ready for full-scale QA automation.
Alpha Stage: This is a crucial stage to find and fix the problems in the software before it is released to the user base. At this stage, a well crafted methodological test plan should be in place along with a set of comprehensive automated test cases to fine tune the product. Breadth tests must be run for every build along with the performance and compatibility tests at least once before treading to the Beta phase. Alpha testing is thus a long process and involves a lot of testing, re-testing, bug fixes and defect logging. Automation testing is quite helpful at this stage.
Beta Stage: The product reaches this stage with merely few non essential bugs to be fixed and the functionality and performance of the product should be acceptable, else the product shall roll back to the previous stage.The product is released to a limited number of people at this stage. Ad hoc testing will take most of the time in this phase and reliability defects may remain. The beta releases will pass through a series of automated regression tests to detect the undiscovered bugs, and there are many test automation tools available for the purpose at this stage. The objective is to either postpone or repair all the known defects as this is the final stage before releasing the product to the masses.
Deployment: Once the product shows no unacceptable defects, we declare it as ‘Gold’ or ‘Release Candidate’. This stage marks the end of product development life cycle. This stage is completely devoid of any testing as the product is now with end users. Now users may discern new defects or defects that have been postponed that must be logged and tracked into the defect management database for further action.
Conclusion: QA Automation in all these stages has not served as a replacement rather an enhancement of the manual testing process. Before Automation can be deployed at various stages of PLC, manual testing has to prepare the pedestal. Deciding the right time to go for automation, defining its scope, and selection of apt tools for automation needs a well planned and thoughtful approach. Any loopholes in this process may cause the entire automation process to backfire, while a heedful approach will ensure user-friendliness, flexibility, re-usability and extensibility. Hence, automation testing is a great idea but is complementary to the manual testing process, and can never be a full-blown substitute to it.