Great quality assurance is what turns great software into great product. Testing is a crucial part of any software development process, whether to ensure safety in a medical device, to minimize risk in a financial application, or to improve user satisfaction in a web site. As consultants, Geisel Software works with a variety of organizations, gaining exposure to many different products, development processes, and testing approaches. This provides the firm with a unique opportunity to see what succeeds for almost any project, along with common blunders. Here are some of the best practices we've encountered or employed in software testing.
Plan for the Span of the Life Cycle
When determining the test needs for a project, divvy it up by stage and identify the required resources — both personnel and systems. Too often program managers are surprised during the final, formal test period. They may find the SQA group needs an additional prototype, or that a tester only addressed the screen UI and workflow testing was left uncovered.
One way to help save time is to delay formal test case authoring or automation until specifications and/or implementation are under way. In too many cases, a schedule calls for test case writing to start on a certain date but when development falls behind, that test authoring schedule doesn't change. Test cases end up being rewritten repeatedly, exhausting the test budget early and sabotaging quality.
Prioritize for the Good of Quality
One hundred percent coverage should never be the goal because it's never practical, even for quality critical systems such as medical devices. Instead, focus first on the areas that present the greatest risk to the success of the product. It's a common practice to just add a test case for every bug found because there's an obvious trigger and it's easy to do. But there is far more value in providing sufficient coverage for each major product area. And for efficiency, start by considering each case the way you would do for a smoke test. For example, if a series of tests for 20 similar controls fail for the first three, don't continue because something other than what's being tested for is probably wrong and more testing likely won't yield any worthwhile results.
Explain Your Tracking System
All modern development groups use a bug tracking system, but they use them differently. Rather than assume team members know how to use the system your way, provide key guidelines. For example, a non-QA team member may mistakenly think only QA is allowed to enter bugs because that was done at his or her last company. Or after a developer completes a task, he or she moves it to Done, skipping over the verification step because it's his or her first time using a sprint-based process. And don't just give the overview at the development kickoff meeting — that leaves out the team members who join the project once it's already under way. Make sure your process is documented and everyone involved in the project is aware of how to access it.
Adapt to Survive
Rigid adherence to plans can be inefficient with little benefit to quality. Throughout the life cycle, QA should look for ways to adapt given unexpected constraints. If a schedule calls for a QE to spend 30 weeks of test case authoring to meet a fixed end date but development is delayed, reschedule the writing. Line up a second QE to join the project later to get the 30 weeks done on time, perhaps adding the first QE to the second QE's project in the meantime. When a prototype system isn't available for QA use, have all groups stagger work schedules so one group begins using it earlier in the day and the other uses it later in the day.
Bonus Best Practice — Look for Root Causes Along the Way
Finding the root causes of problems presents the best opportunity for significant and lasting quality improvement. Smart organizations conduct sprint or project retrospectives. At those sessions, identify bugs that caused memorable pain and perform a root cause analysis and make changes to aid prevention going forward. In some cases, don't wait for a retrospective, but pause when a particularly egregious or annoying issue arises and conduct the root cause analysis right then.
While most companies have at least some testing practices, every company can improve upon them. Given that testing is such an important element in the process, it's advantageous to review your processes and consider new approaches.
This article was written by Brian Geisel, CEO, Geisel Software, Worcester, MA. For more information, visit here.