- 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 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.
- 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.
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.