Be on the same page with us
Subscribe to our latest news
By clicking the button Subscribe you give a permission for the automatic sending of e-mails

Are QA engineers necessary for the Test Driven Development approach?

For the recent years, we often hear about holy wars between engineering managers concerning the role of QA engineers in such environments. There are teams which have great products with QA engineers as a part of the team. And there are teams with great products with a complete absence of QA guys. So, where is the trick?
May 21, 2018
Tool vs. Role

"Test" is the place where this confusion happens.

First of all, it's crucial to draw the line between TDD and QA: they are not interchangeable. TDD is NOT about verification of actual result to match the expected one, it's about a better understanding of the feature design you need to implement.

Secondly, whether you have testers on your board or not, someone still tests you products and controls the quality process, meaning the QA role is still there happening in a structured or an ad hoc way.

With common language set, we come to the real question here: who should do testing?
Testing: Developers vs. QA Engineers

There's nothing in the QA world that can't be done by an experienced developer.

However, your project often has the following types of constraints:

  1. Cost. Compare the salary of your developer and QA engineer, capable of doing the same testing job. Often you'll see the difference is 2, 3 etc. times in a developer's favor. It turns out that you're paying the price of developing skills for testing skills. Remember the paradox about 80% of the cost giving only 20% of result?
  2. Multiple layers. API integration, localization, performance, compatibility, security, field usage, compliance with standards – all these areas can contain showstoppers for your product. The amount of details you need to take into account is huge, and the specific experience of the tester is a great help through this process. Professional testing is all about system approach to the product quality.
  3. Time vs. skill set. In order to dig into the aspects of performance or security testing, an average front-end developer will need some good amount of time to learn things. Your project often doesn't have time for this.
  4. Testing eye. Testers with senior-level experience are very FAST in catching lots of things in the logic and UI experience between different screen sizes, platforms, and devices. Problems identified early in the game are cheaper and faster to fix, since the code tends to become more and more complicated with each iteration.
  5. Routine. When you have rare releases automation often has negative ROI. This means a lot of stuff should be checked manually. Cover the most widespread combinations of OS versions, devices models/manufacturers (phones/tablets), browsers. And this is the time of your developers not accustomed to these operations.
  6. False tests. Your tests won't catch mismatches between product vision and implementation if you understand the requirements the wrong way. Having team member of the opposite role testing your feature is often better.
  7. Blind spots in your tests. TDD is still more reliable than common Unit Testing because a developer inevitably ponders over the solution of a problem prior to writing any code, but acceptance testing is better to be performed separately anyways. A developer may be more interested in writing a code that makes tests pass than trying different test scenarios.
  8. Specific projects. There are certain types of projects when having a QA engineer/team is a must, e.g.: the functionality is non-trivial, associated with complex integrations, calculations/heavy loads/security, and requires a specific toolset to verify if the actual behavior of the system matches the expected one.
  9. Different mindsets. Developers live in "construction space", they are great at abstraction level, and their job is to solve problems. Testers live in "destruction space" and their job is to understand the problem from the reverse side – and know how to break your code before it's even written.
What is the optimal solution?

Per our empirical experience, certain projects don't require a QA team or separate test engineers, since your cross-functional team is capable of fulfilling the needs of a project – MVP phases, small apps and sites, a small audience – or low cost of failure in production. If it's cheap for you to fix bugs identified by your users, you probably don't need to worry much.

But if this is not true, a mix of developers and QA on your project makes your skill sets and productivity set to a maximum. The key is the right integration of the QA. Devs and testers should share knowledge and cross-train each other. A tester who understands the code base will find loose ends earlier – and will break the system successfully. A developer who understands how to build better tests will implement better feature and product.

You uncover the problems fast. It keeps the team members focused on their desired job. And most importantly, it saves your budget.