Involving QA in the Development Process

Problem

The relationship between QA and development is a peculiar one and can take many shapes and forms. In many places, the two are distinctly separated. Once developers complete a project, they will hand it over to QA to take it from there. In other places, test-driven development is a norm that entails that developers write tests -- mainly unit tests -- and develop to pass those tests.

I find myself somewhere in between these two most common approaches.

Actions taken

I had to experience the best -- and worst -- of both worlds to be able to come up with my own approach. Expanding experience in different types of development was critical to understand the nuances of the QA-development relationship. For example, test-driven development may work well in some situations, but it is hard to implement in UI-heavy projects. QA needs to be involved in those projects because being automation-ready for a new UI in mobile apps, especially in an Agile environment, is exceptionally difficult.

Learning about QA-development challenges made me confident that having a QA team that is part of the development team from the get-go is the most effective approach one could take. By being part of development, I am not saying that QA should report to development managers. What I am saying is that QA should be included in the development process in the same way product managers and designers are included. Furthermore, this approach resonates well with Agile and supports creating the proper tests ahead of time.

While there is no doubt that this approach will improve the quality of a product, it will also increase development velocity by eliminating a hand-over phase at the end of the development cycle. By being involved from the start, QA will be familiar with key concepts and expectations. Also, because they were not involved in every line of code, they could tell if some detours had been made from the original design and product requirements.

Next, involving QA early on implies creating an opportunity to identify problems early on. The earlier you identify problems, the faster you will solve them. If you happen to identify an issue in architecture before doing development, you will avoid making the mistake of building the wrong product. If you identify an issue when things are shipped into production, that will be much harder to tackle. From the standpoint of someone working in mobile development, it’s much more difficult to make any changes when things reach production.

Finally, with overlapping timelines and multitasking, one can arrange that QA looks at their next feature while testing the past feature or doing regression tests on the last release. Even if QA allocates 20 percent of time early on for the next feature development, the overlap will be highly beneficial. They would start a bit later and finish after developers, but again, that will overlap with the feature development of the next cycle.

Lessons learned

• QA should join your design planning, requirements planning, standups, and all other relevant meetings. If included from the start, they will have sufficient context, be familiar with product requirements and design, and thus be able to contribute more efficiently.
• By including QA, you will gain development velocity and product quality. But most importantly, you will increase their engagement. Unfortunately, QA feels like second-rate citizens in many development organizations; by including them in all processes, you can make them feel like first-rate citizens. They will be committed and proud about what they are doing and how they are contributing to development.