Starting a new project is nerve-racking. There are so many choices to make. How can you be sure you choose well? Whether it’s web development or mobile development, outstaffing or outsourcing, time and material or fixed price, healthcare or entertainment, one of the most important decisions you have to make is the team. The choice of the team has an immense impact on the future of your software project: will it thrive and generate profit, or be a painful failure?

In this article, my goal is to advise you against a mistake that can cost you a lot of money and nerves. I’ll describe the roles of software development and Quality Assurance specialists and explain why you shouldn’t hire these professionals as two separate teams. Developers and QAs are like coffee and croissant: these two work best if they’re together 😉 Yet, if you have no choice but to hire these two separately, I will provide a few suggestions on minimizing the risks.

Disclaimer: Below, I will talk about development and testing in the context of Agile projects. For Waterfall projects with their streamlined processes, the game’s rules will differ a lot.

The Role of QA and Developers in the Team 

The project team is defined as “a set of individuals performing the project’s work to achieve its objectives.”

I think you already know what kind of professionals a software development team may include: a Project Manager, Business Analysts, UI/UX designers. software developers, QAs, and DevOps professionals. In some projects, a few of these roles can be omitted. The only role that simply can’t be omitted is software developers because there would be no software (at least in the common understanding of it) without code written, reviewed, merged, and deployed. 

Another role that I would recommend never to omit is Quality Assurance engineers. These are the people who will not only make sure that your project is bug-free but also they will serve as project knowledge holders who will be able to consult you if you ever forget how some parts of the system should work. 

I often hear that there is no need to hire a QA because developers will test their code independently. There are four reasons why I don’t think it can work:

1. Developers won’t be able to zoom out and test the system as a whole. Even if they test their component perfectly, it’ll be hard for them to notice if their change breaks anything in a remote part of the project.
2. Developers follow the critical path of the user journey. They know how the user gets from A to Z and follow the optimal way. QAs, however, know all the workarounds and all possible ways to break the system. So they can discover a lot more problems than developers. And my experience tells me, users almost never behave the way you want them to.
3. Developers may need a fresh pair of eyes. After spending hours and days looking at the same piece of software, it’s very easy to miss something wrong or illogical.
4. Developers are mostly more expensive than QAs. It’s a very simple math problem. If the developer’s rate is 2 times higher than the QA’s rate, you’ll spend twice as much money on testing (or even more because QAs may perform testing faster as this is specifically what they are trained to do).

This is not to say that if you hire QAs, developers will do zero testing. They’re still required to check if their code works before pushing a merge request. They’ll also write unit tests, integration tests, and possibly end-to-end tests to make the system more reliable. But the major part of testing, trying to break the system, and trying to understand the user’s hardships will be done by the QA.

Why QA and Developers Should Work Together to Improve Quality

In most projects   I’ve worked with, the clients hired developers and QAs from the same agency — and it makes perfect sense. Yet, there were a few exceptions when the client hired developers from one agency and QAs from another one. There are e a few serious problems with this approach: at the end of the day, the teams may be unhappy with their life on the project, and the client may be dissatisfied with the end result.

If you consider employing developers and QAs as two separate teams, please read my reasons below. Here is why development and testing should be done by the same team. 

To be a cross-functional team — as Agile, and Scrum in particular, requires

Scrum Guide, the table book of a PM using Scrum, states the following: 

“Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.” 

Cross-functional means that the team has all kinds of professionals that the group needs to create a product. At the same time, it means  these professionals are skilled not only in their area of expertise but have some understanding or experience in the areas that their colleagues cover. This way, if anyone has to drop off for a few days or longer, the team won’t put all work on hold but will be able to continue even during the most turbulent times. Also, it’s a perfect environment for brainstorming serious issues, experience sharing, knowledge sharing, and the team contributing equally to the common goal.

Here is the chart which illustrates the concept of a cross-functional team:

To reduce the amount of work that needs to be done upfront  — as Project Management Body of Knowledge suggests

PMBOK (the main book of every Project Manager) says, when the project team consists of people from different organizations,

“… such arrangements often require more up-front work to establish a “one team” mindset, ensure project team members understand how everyone contributes to the project, and establish other enablers that integrate skills, capabilities, and processes.”

Before I explain my understanding of what the aforementioned quote means, let me provide you with a little bit of theory — for all of us to be on the same page.

Tuckman stages of group development

In his theory of stages of group development, Tuckman suggests that each team goes through five major stages throughout the course of its development:

1. Forming
2. Storming
3. Norming
4. Performing
5. Adjourning

Forming is the first stage of team development, where the team is brought together, and the individuals begin to establish their relationships as a group. Usually, this stage is quite positive since everyone tries to make a good first impression, and act polite and friendly.

Storming is the stage that the team enters when the first conflicts or issues occur. It’s hard for team managers to please all team members equally, so oftentimes someone will be dissatisfied and provoke open or latent conflicts. This stage, however unpleasant and dangerous it is, is inevitable as people have to learn to work together and smooth their edges.

Norming is the stage where conflicts and issues begin to be resolved, and the team learns to work with each other effectively. This is the stage where trust is built, and honest connections are established.

Performing, as the name suggests, is the stage when the team shows great performance results. Team members have already put their differences behind and work towards the common good, keeping the team goal in sight.

Adjourning is a stage that Tuckman added later, so it’s often omitted from the articles and books. The idea of this stage is that the group’s work together has ended, the goals have been achieved, and everybody says “thank you, bye” and goes their separate ways.

***

Coming back to the PMBOK idea highlighted above, the up-front work encompasses the first three stages of team development. At these stages, the team can’t unlock its full potential and perform up to your expectations. If the experts you hire to work on your project belong to a single organization and aren’t separated by some bureaucratic processes or formalities, the forming, storming, and norming stages should pass quicker than when the team consists of people from different organizations. 

After all, the sooner the team starts performing, the sooner your project will become profitable.

To minimize communication issues

Communication is the area that suffers the most when developers and QAs are separate teams. The duties of those who build an app and those who test it are extremely interconnected. 

Developers often turn to QAs for help when they don’t understand how something works or is supposed to work. Imagine that you set a task for your developers to update the styles of the buttons across all pop-ups in the system. It’s great if you have well-written and regularly updated documentation that developers could consult with. But let’s be honest, in most cases, documentation is often very high-level, and the developers need to ask the QAs to help them. Sometimes, while working on a task, the developer will have to do something different from what the requirements say. They must inform the QA or else their ticket will soon be returned with the comment “task description is not followed”. 

It works the other way around too. QAs may need developers’ help in understanding which parts of the system could be affected by some change. This way, they are able to do smoke testing of a single change request and its dependencies instead of having to run full regression testing. Some tasks that the QA is assigned to test may be very technical and difficult to understand. Normally, the QA would ask the developer: “Hey, you have rewritten this React component from class to functional. How can I test it?”.

People developing and testing a project absolutely must be able to communicate freely. This communication needs to be open, obstacle-free, and preferably face-to-face or via Google Meet/Zoom/Skype with cameras on. There is no need to write long letters and endless messages involving other team members if something can be discussed in five minutes one-to-one, face-to-face. To prove my last point, one of the twelve principles of the Agile manifesto says:

“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” 

When development and testing teams are separate, such a communication flow is almost impossible. People don’t trust each other enough to ask possibly stupid questions, and they feel like they need to involve a manager for any outreach to the other team.

For everyone to feel equally responsible for the project

Product value should be the centerpiece of the project development process. In order to contribute to the value, the team should treat the product as their own: respect the business, care about the users, think critically about the product requirements, and promote project quality. If people don’t feel responsible about the project, they are likely to care very little about its future. 

At the same time, there is a psychological phenomenon called “diffusion of responsibility”. If many people are responsible for something, there is nobody responsible. It works the same with groups of people. If there are two or more groups responsible for the end result, no group actually bears the responsibility for the project’s growth and value.

If developers and QAs are two separate groups, none will feel responsible for the end result. The developers will believe: “It’s up to QAs to test the project and make sure that it works great”. The QAs will think: “It’s up to developers to follow the requirements, discuss them with the client, and make sure that the project delivers value.”

Of course, this negative effect can be reduced by a thorough recruitment process. If you hire professionals with strong soft skills and a good cultural fit, they are more likely to do their job conscientiously. Yet, the risk I highlighted above remains.

How to Bring Your QA and Developers Closer if You Have No Choice but to Hire Separate Teams

If for some reason you need to hire developers and QAs separately or you have already done so, all hope is not lost. There are some things you can do to minimize the risks I have mentioned above.

Engage both developers and testers in the requirements discussions and demo calls

There is a model called Shift-Left testing, the idea of which is to push testers from the right end of the software development life cycle to the left end of it.

Here is a chart, which illustrates the software development life cycle:

Usually, QAs are engaged quite late in the SDLC, at the testing stage, when everything has already been planned, discussed, designed, developed, and just needs to be verified. The followers of the Shift-Left testing model (and I am one of them) believe that if you engage QAs at the earlier stages of the SDLC when the requirements are discussed, you will get a better-motivated team, better-written user stories, and a higher-quality product.

So, once you conduct a meeting to present project requirements to the development team, make sure to invite the QAs too. If they’re on the same page about what’s required, there’ll be less room for misinterpretation. QAs will feel valued and trusted as they’ll be engaged on equal terms with the developers. They’ll have the opportunity to ask questions that nobody thought about and offer useful suggestions as their experience with the system is the closest to that of the end user.

Similarly, invite them to demo and retrospective calls. Not only will it be helpful for the project team to hear the ideas of everyone involved. It will also be very useful for the QAs personally as it’s important for them to receive feedback about the results of their work.

Develop a clear definition of done

There is a huge temptation for the developers to deem the task as done as soon as it has been submitted to testing. Once QAs start sending back tasks and creating bug reports, it can cause a lot of frustration: “This task has been done already, why would you reopen it?!”. To prevent conflicts, there needs to be a very clear definition of done — for everyone to be on the same page about when a task can be considered truly finished.

Definition of done can be very simple or quite complex — it all depends on what your project needs. Moreover, the DoD can evolve as your project grows. The most important thing is that everyone is informed and agrees to comply with it.

An example of a simple DoD

The task is done if:

• It’s deployed to production
• There are no critical bugs on production

An example of a complex DoD

The task is done if:

• It’s deployed to production
• There are no critical bugs on production
• Unit tests are written
• Integration tests are written
• E2E tests are updated
• Performance tests are run successfully
• Load tests are run successfully
• Acceptance tests are passed successfully
• Regression testing is done successfully
• Responsive testing is done successfully
• Translations are added for all countries
• Release notes are written
• User documentation is updated

Develop a bug report template that covers everything

Another thing that can easily frustrate developers is a bug they can’t reproduce. Nobody enjoys admitting their own mistakes, so there is an urge to say, “It works fine on my end”. 

To make sure that developers get all they need to reproduce a bug, create a bug report template that covers all the info they might need:

1. Steps to reproduce
2. Actual result vs Expected result
3. Environment (browser and its version, OS and its version)
4. User roles, for which the bug happened
5. Timestamp of when the bug happened
6. Severity and priority
7. Attachments (photos or videos of the bug (a picture is worth a thousand words 😉))

In case the bug report is incomplete, encourage the developers to provide feedback to QAs.

Don’t forget to leave some time for testing in your project roadmap

One of the problems, which is VERY likely to happen, is the developers passing the tasks to QA late, right before the release date. The developers aren’t to blame: if they think   the deadline is the day of the release, they’ll deliver according to the plan. The plan is what needs changing.

Testing is a process that takes time. Bug fixing also takes time. So when creating the roadmap of your project, make sure to leave some time specifically for QA and communicate the deadlines clearly to all project participants. After all, what is the purpose of hiring QAs to find the bugs if nobody has the time to fix them?  

Organize regular sync-ups

Lack of communication is among the biggest risks, so prevent it proactively by scheduling regular team sync-ups. 

• Depending on the size and pace of the team, these calls can happen daily or weekly. Schedule a repetitive call, add the agenda to the meeting details, and communicate your expectations from such meetings. These sync-ups should become a habit for your teams.
• I would recommend that these meetings take place as video calls with cameras on. There are enough communication obstacles already, don’t create another obstacle in the form of a lack of non-verbal communication.
• Don’t underestimate the importance of icebreakers. The atmosphere at such meetings will inevitably be cold and tense. You can use different tools and games for facilitation to help people overcome fear and stiffness, inspire less formal communication, and give people a chance to establish a connection with each other.

Conduct team-building activities

Unfortunately, the two teams from different agencies are very unlikely to ever feel like a single project team. Yet, there are ways to bring them a little bit closer together. Team-building activities should be a great help here.

To conduct a team building, your employees don’t have to be located in the same building or city. There are activities that can be done online:

• Organize a quiz about the project or about something random using kahoot!
• Play an online game, for example, Dixit or Alias
• Encourage people to prepare a presentation about something personal, for example, about their pets or hobbies
• Get involved together in a volunteering opportunity, for example, One Tree Planted

Create an extra chat for informal communication

This suggestion is somewhere in between the previous two, and although it won’t substitute any of them, it will become a nice addition to the team atmosphere. In the messenger in which you communicate, should it be Slack or Microsoft Teams, create an informal chat and call it something simple and fun. Encourage people to share jokes, interesting articles, nice songs or movies, or great recipes here. To do so, lead by example, ask questions, and nudge people directly.

Conclusion

By design, developers and QAs are the two roles which conflict. Developers do the work, and QAs strive to find mistakes in their work. Developers aim to release new features to production, while QAs prefer to have an old and stable rather than new and buggy version on production. 

The main goal of establishing a sound developer-QA relationship is to switch from “You’re guilty! — No, you’re guilty!” to “What can we do together to minimize mistakes? What can we do to react to mistakes quickly?”. Splitting development and testing into two teams makes achieving this goal harder.

Keeping developers and QAs separate is a challenge, which isn’t always simple to manage but which is very easy to avoid. Yet, if you’re sure that you and your stakeholders can handle this challenge, we’ll gladly support your idea and help you find your perfect software developers or testers. Yet, I feel it’s my responsibility to warn you about the potential risks for you to make a weighted decision. After all, transparency, honesty, and trust are the pillars of a successful project.