6. Automate
This step has been put at the end, although it could come in earlier depending on the stage the software development is at. Automation of software should only be considered after the code has stabilized and test cases being considered have "almost" entered the maintenance phase. Given that automation in itself is a mammoth task to undertake involving many different aspects, knowing certain key steps listed below can help in making it a successful experience:
- Defining the right set of test cases. Remember, the purpose of automation is not to replace manual testing but to complement it. So choose the test set carefully.
- Automation tools are not bug free. Choose the automation tool after doing a small end-to-end experiment with the software.
- As part of the prep work, ensure developers include appropriate name tags and "behind the scenes" content in their code to facilitate automation.
- Ensure the scripts are expansible. Review the architecture thoroughly before proceeding with the actual scripting.
- Finally, ensure the automated test case execution and reporting is linked up appropriately with your test case naming conventions and structures.
Now that you have had a taste of the testing methodology, let's talk a little about the flavors which some key industries present. Note that the information provided here is generic and does not essentially constitute the characteristics of every company's STLC process.
- Financial Services. This industry generally looks at software development as a backend support for the business. This means the focus is not on building bullet-proof software, it is more on churning out good features as soon as possible. This in turn translates to frequent software releases and inappropriate level of documentation (unless the information being displayed is sensitive from an audit perspective). Change control processes and typically in place but more liberal when implemented. One point to be noted here is that financial services encompasses the banking, brokerage, insurance, mortgage and other domains; hence the testing methodology implementation differs.
- Pharmaceutical. In general, contrary to the financial world this industry gives a lot of importance to documentation and insists on a highly structured process. Every change is marked by one or multiple approvals depending on the extent of the change. Sign off processes are more elaborate and change control is meticulously administered. The audit process is strict and robust for the most part. The trade off is that you have longer release cycles, more buffers at each stage and less flexibility in changing processes, at least in the short run.
- Telecommunications. This industry is similar to the pharmaceutical industry in testing procedures and approach. It is characterized by long release cycles (some times maybe one a year) with restricted amount of change, elaborate regression testing and extensive use of automation - functional and performance related. Documentation is always kept up to date. Team sizes tend to be larger on an average.
- Information Technology, Product-based. The testing processes and procedures in this industry are characterized by a lot of variance depending on the revenue that is generated or will be generated by a given product. A product may or may not make it to the market to begin with and may or may not be successful. More prominent products enjoy a 1:1 ratio of developers to testers or possibly even higher given the criticality of success. This industry is also characterized with elongated beta testing periods with an increasing target audience.
Conclusion
Testing can make or break an application depending on the importance given to it. Just knowing this is not enough though. It is the "undefined" responsibility of every tester and testing manager to constantly work towards improving the testing process and increasing their contribution to the SDLC. Remember, as the software changes, so do the resources testing it. So always build appropriate documentation along the way to streamline the training process. This goes a long way in keeping the testing procedure intact and the software quality consistent.
Tushar is a project lead with DATA Inc.. As an authority in software quality assurance, Tushar has managed on-site and off-shore development and testing teams; developing and implementing methodologies for quality assurance activities across organizations ranging from start-up dot com organizations to Fortune 100 MNCs with product- and project- based delivery models.
