Quality software is the byproduct of a highly functioning team. Why duplicate effort, or have inefficient developer testing without oversight? Trust your Quality Assurance staff to lead the testing at all phases. There are discussion points around developer-based testing and testing performed primarily by the QA team. For this article, we’re assuming a balanced approach is being taken, with both QA and engineers participating in testing. We’re focused on the practice of developers and QA staff working from the same test plans to assure accountability.

Test Plans Increase Software Quality

Too often in the Software Development Life Cycle (SDLC), a “finished” feature by a developer is structurally sound overall, but with some primary use cases ignored, and polish lacking. As a result, QA begins testing the product with prevalent bugs. This situation leads to expensive back & forth iterations and incurs significant overhead. Your QA team specializes in effective methods to test essential scenarios, and that skill could (and should) be applied to all testing, regardless of who is executing it and at what phase of the SDLC.

Your team most likely has test plans documenting major features, along with plenty of edge cases and fragile system touch-points. Utilizing those existing test plans ensures the developers’ time spent testing is at its most efficient.

Keep your test plans relatively simple and select a subset of test cases that make the most sense for developers to utilize. Focus on the main create, read, update and delete (CRUD) operations, as well as any primary user paths. It doesn’t make sense to have developers run through entire complex test suites, but a select set of tests should prove helpful in guiding developers to test the essential paths. If you’re maintaining tests for developers as well as QA, then having a reusable set of tests for both teams should also reduce maintenance on the actual test cases, depending on your existing process. If the developers are testing based on memory, or shorthand notes, they’re likely not going to deliver the highest quality software to the QA phase. Similarly, testing purely based off just a user-story could also prove insufficient, and may not cover all regression cases related to the feature.

Employing this strategy leaves more QA effort to be focused on other testing concerns, such as regression & integration testing, performance & load testing, etc. If the QA team is engulfed in filing straightforward bugs that are readily apparent, then you’re missing the opportunity for wider and more targeted testing. The time & talent of your QA staff shouldn’t be wasted with obvious flaws; their time should be spent on more intricate testing and finding unexpected bugs.

Universal Test Plans

As a custom software company, we’ve created a multitude of different applications across platforms. But most projects we’ve encountered have a core set of features: login, logout, forgot password, list pages, search functionality, and modal dialogs for CRUD operations. To make testing these more efficient, we created universal test plans to be reused across projects. Instead of having a “login” test plan for every project, we have one test plan for the “login” process that every project must conform to.

Necessary oddities & edge cases for a given project are dealt with on a case-by-case basis, but we’ve found them to be infrequent, and rather small in scope. Employing this method also greatly reduces maintenance on part of the QA staff and helps keep us more agile – allowing testers to shift between projects with ease.

Hardened Process with Checks and Balances

Requiring a completed checklist, or proof of tests run, can help maintain accountability throughout the SDLC. Having a reliable, reproducible, and documented format for the handoff between developers and QA can also help measure the efficacy of your developers’ testing and aid in gauging the quality of your product at the beginning of the testing phase.

Your experience may vary widely depending on the project management and bug tracking software you’re using. We’re using Target Process, which offers Test Plans, with encapsulated Test Cases… which can then be executed as a Test Run. All Test Runs are tracked and archived. Evidence of successful Test Runs would be one way to ensure proper testing has been completed in the development phase.

Final Thoughts

The goal of course is to deliver the highest quality software to the customer. Start with the highest quality coming out of the development phase for better chances of a high-quality product at the end of the cycle. With both developers and QA running at higher efficiency, fewer bugs will reach the end user. Developers will likely be relieved, as they will stress less about their testing, knowing they’re following a path provided by the testing team, and QA will be pleased to be hunting for more interesting bugs rather than monotonous issues.