Involving QA engineers at the beginning of a project seems like a perfectly obvious choice, in hindsight. It’s not like we invented the concept.
But everyone has to learn on the job sometimes. Here are some examples of things we have learned about the value of paying someone to break our creations as soon as possible.
1. The earlier, the better
The QA tester should ideally be introduced to the project whenever the acceptance criteria are. Meaning, at the very beginning of the project. In some cases the tester should even be included in making the criteria themselves. Having intimate knowledge of user patterns and thought processes, they might prove to be the difference between a good and vague criterion.
The question they will keep asking is “But what happens if I do this?”, preventing us from taking shortcuts and pushing potential problems ahead of us. Involving one of them in the design and planning phase will therefore benefit us greatly, resulting in a tight and specific description for the developers to work from.
Our approach to testing was for a long time that the PM and developer would check the features for bugs during the project. Sometimes another developer would be assigned, but as a smaller company this wasn’t always possible. The QA engineers were mostly scheduled to do work in the final weeks of the project, when we could see how all the features worked in relation to each other.
The problem was that, being an agile company, it was difficult to tie any kind of certainty to the time it would take to actually test all features. This would sometimes result in the testing and bugfixing phase stretching until long after launch, when the developers ideally should have been focussing on some new and exciting project.
2. Avoid conflicts of interest
Conflicts of interest are not something we should be inviting into our development processes willingly. Yet, when it comes to testing and delivering software, we most definitely used to.
See, both a developer’s and a project manager’s main goal is to keep the project moving forward. “Done is beautiful” we think. And we’re right! We build technical and administrative structures around the core functionality of the project, make sure it looks neat and tidy, and move on to the next bit. This is how it’s supposed to work.
See the problem? Telling someone who is rewarded for progress to halt or delay a project to fix bugs is ultimately counterproductive. Besides, our jobs as managers is to make our employees’ jobs as straightforward and free of contradictions as possible.
3. If you can’t beat them, hire them
End users will, on purpose or not, try to dismantle everything you’ve built. It’s the basis of the joke:
A tester walks into a bar, orders a beer. Orders 0 beers.
Orders 99999999999 beers
Orders a lizard. Orders -1 beers.
Orders a kojoivjcxoi masfjn.
The first real customer walks in and asks where the bathroom is. The bar bursts into flames, killing everyone.
A PM or developer will most often test the path of least resistance. Does this work for the most common use case? Great, let’s move on. A conscientious PM might even “Order -1 beers”. But with the PM’s task queue and rewards for spending as little time as possible, we very easily end up with the aforementioned conflict of interest.
Enter someone whose sole purpose in life is to break your functionality ahead of time. And is paid to do it. The QA engineer will think like a user, actually spend time thinking about what a real person might try to achieve when visiting your page. And will most likely ask for the bathroom before real users try to.
4. Extra security and sleeping well at night
Given that your PM is decent at scope management, this means that their time is freed up to do what they do best: make sure that the project is delivered on specifications and on time.
Sure, it means that we have to add an extra resource to our estimates. But compared to the unstructured scramble of gluing together broken elements while users are scrambling to break them… We’d choose the planned-in-advance cost every time.
In fact, hiring QA engineers also makes our work more predictable and easier to organize. Leaving a percentage of time available for testing every feature means that we are finishing each task within the sprint on time, at a greater rate than before. How we used to do things, tasks would often end up sliding into the next sprint to some degree.
5. Having another set of eyes
As a project manager, involving a QA specialist as early as possible in the project comes with more benefits than less bug fixing time. Our QA team will also regularly join client meetings and ask insightful questions about the functionality of the solution. In some cases they bring their own development experience to the table and suggest new and better ways of doing things. Not only do we end up with smoother running code, but also more user friendly solutions based on expert opinions.
The value of this role simply cannot be overstated. Both from an agency and a client point of view, our lives are so much simpler when giving control of functionality to testers. We avoid conflicts of interest, and instead of bleeding hours at the end of a project, we can rest in the knowledge that if it can be broken, the QA team will break it ahead of time.
