Back to resources

Involving QA in the Development Process

QA Team
Collaboration
Cross-Functional Collaboration

6 August, 2021

Zeev Vax
Zeev Vax

Sr. Engineering Manager, Mobile Platform at Homebase

Zeev Vax, Director of Engineering at Wonolo, discusses the importance of getting QA involved in the development process early on.

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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Myth Busting

10 December

Supporting principles on why being data led (not driven) helps with the story telling.

Alignment
Managing Expectations
Building A Team
Leadership
Collaboration
Productivity
Feedback
Psychological Safety
Stakeholders
Vikash Chhaganlal

Vikash Chhaganlal

Head of Engineering at Xero

DevSecOps: Why, Benefits and Culture Shift

29 November

Why DevSecOps matter and what's really in it for you, the team and the organisation?

Innovation / Experiment
Building A Team
Leadership
Ownership
Stakeholders
Cross-Functional Collaboration
Vikash Chhaganlal

Vikash Chhaganlal

Head of Engineering at Xero

The Growth Mindset in Modern Product Engineering

28 November

The impact you can have with a Growth Mindset' and the factors involved in driving orchestrated change.

Building A Team
Leadership
Collaboration
Feedback
Ownership
Stakeholders
Vikash Chhaganlal

Vikash Chhaganlal

Head of Engineering at Xero

How to improve engagement and retention in remote engineering teams?

25 October

Mrunal Kapade, an Engineering leader, based in Silicon Valley, shares tips that helped reduce attrition in the remote engineering teams while leading multiple teams from startups to Fortune 500 companies.

Remote
Company Culture
Collaboration
Motivation
Team Processes
Mrunal Kapade

Mrunal Kapade

Director of Engineering at Inspire Energy

How to Organize, Manage, and Grow Your Team

12 July

Vineet Puranik, Senior Engineering Manager at DocuSign, discusses the impact of roadmaps, organization, and proper management for your teams to procure growth.

Managing Expectations
Delegate
Collaboration
Roadmap
Strategy
Vineet Puranik

Vineet Puranik

Senior Engineering Manager at DocuSign