by: Whitney Dueitt
Standard projects are often customized software that will not go through multiple versions over the course of a year. Products, on the other hand, are essentially the opposite. Products go through multiple versions while customizing for specific customers.
At CTS, no matter the category, all pieces of software go through a testing cycle. Though types of testing may change, the end goal is the same: to create a high quality product that adheres to the specified requirements or test basis. Even though the end goal is the same, treating products as multiple projects can cause costly issues.
On previous engagements, the QA team followed the basic manual testing strategy for each round of Customer Specifications on a specific product. Each resource had a dedicated amount of time for ramping up, importing requirements, and creating test cases. The amount of time spent in the analysis and design phase was not decreasing, as was expected. While tracking testing metrics, the QA resource noticed that, not only was time not spent where it should be, but also the number of defects were increasing in later cycles of testing. This caused more defect fixes and retesting late in the project schedule.
After a few of these similar engagements, the team identified the repetitiveness between all of the projects. Instead of writing similar tests for each engagement, the team began using shared steps and reusing previously created tests. Taking this step back allowed CTS to take advantage of wideband Delphi, enhancing estimating capabilities while utilizing group think. The team outlined all product information, while only slightly changing it for individual versions. The outlined list included standard product risks and all criteria needed for testing. Finalizing testing tools and environments occurred, including cloning previously used environments. Utilizing product version similarities helped cut down the Analysis and Design phase for QA resources.
The benefits extended past manual test execution. Automating regression tests allowed developers to execute tests at will, without waiting for a testing cycle. This resulted in developers identifying and fixing defects while in the development cycle. The more basic defects caught during the development cycle, the more the QA team could focus on more in-depth testing, increasing the quality of the product.
Taking this approach has allowed the QA team to work smarter to create high quality, versatile products at a lower cost.