All too often, QA is perceived as the bottleneck in getting software out the door. This makes sense when you only see QA as just the “bug finder” in a world where you build, test, and release. But how can you leverage your QA team to improve your pipeline to delivery? There are many ways that you can do this, but let’s look at using defect prevention and analysis to test wisely and improve your pipeline. Prevention The scenario: a designer has sent specifications (and if you’re lucky, wireframes) for a new feature. Depending on your development process, you would probably see the following happen:
A developer writes some code
A tester goes off and writes some tests
Once the developer finishes code, the tester executes the tests, finds bugs, and tells the developer to fix the bugs that were found.
The above scenario seems simple, however at the later stages often one finds that the test cases do not 100% align with code. To fix this, what if you changed this process to look more like this?
The designer, engineer, and tester meet to discuss the feature.
QA starts guiding the team into the tests that are needed to ensure the feature works.
The engineer and designer see what is going to be tested, and also contribute - identifying areas that were missed in the spec or wireframes.
The team agrees to the tests.
The engineer builds the feature, running each test until all are passing.
In the first approach, QA is relegated to be only the bug finder. But in the latter, QA helps drive the team towards bug prevention. In writing tests first, before anything is built, there are a few advantages:
A shared understanding of the requirements early in the development process puts everyone on target for the same goal. Have you ever worked on (or managed) a project where the engineer and tester’s interpretation of a feature was completely different? The end result is code that does not pass the test, and time spent trying to reconcile the issue delays future work. When tests are written first, the guessing game is taken away; it highlights bugs earlier in the process as well as gaps in feature to final product issues.
Issues found early save resources. Consider how expensive it is to find a bug late in the cycle, after Development is ‘finished’ (a term I use loosely here). When QA facilitates tests before features, developers catch bugs before QA even sees them. Then there are no bugs to track, therefore no need to review the bug in triage or write specific regression tests that make sure that one specific bug is fixed (those test were already written before the feature was coded). It also eliminates the need to perform those specific regression tests on every build since the bug does not exist in the first place. Lastly, there’s no need to hold a meeting to justify the cost of fixing the bug versus the cost of leaving it in, and no need to document its presence and or implement its workaround. You do the math; this translates to hours -even days- of time saved.
Holes in design are found early and rework is minimized. In leveraging your QA team to guide test development, usability (UX) should also be a consideration when designing tests. It is not possible to anticipate the success of all features when they meet the user. Perhaps there is a technical aspect that has not been considered, and the team will need to rethink the design. This is much easier to do up front than after things have started developing. Everyone in Development should be involved in a UX discussion early on in the process.
Of course there is much more we could dive into, but it is pretty clear that using your QA team to prevent bugs can only help in your product’s delivery pipeline. Test Wisely Defects are inevitable. Try as we might to prevent them, they are just going to happen. But what do you do with bugs that you do find? Your QA team can look at results and identify trends in the system. Perhaps the majority of the bugs are in a certain area. Your team can quickly adapt testing to areas that seem to be in more trouble, spending resources prudently as you get ready to deliver your product. If you need to get a product out the door – does it make more sense to spend resources in areas that have had no (or few) bugs reported? Or rather to add more to a feature that has had more problems than others? As you can see there are not just implementation questions, there are strategic ones as well. Summary Let’s start getting rid of the perception that QA is the reason things get delayed, and instead look at the point of view that QA gets your product out the door faster, and with better quality! Work with your QA teams to learn to drive defect prevention and to analyze those that do come in, and you should see a path to improving your pipeline. QA is then a facilitator of success, not a blocker. About The Author
Ashley Hunsberger is a Quality Architect at Blackboard, Inc. and co-founder of Quality Element. She’s passionate about making an impact in education and loves coaching team members in product and client-focused quality practices. Most recently, she has focused on test strategy implementation and training, development process efficiencies, and preaching Test Driven Development to anyone that will listen. In her downtime, she loves to travel, read, quilt, hike, and spend time with her family.
T: @aahunsberger L: https://www.linkedin.com/in/ashleyhunsberger
