A chef should not certify the dish they made. Developers who wrote the code should not also be testing it entirely. Businesses hire objective software testing teams for a reason; the most notable is that developers shouldn’t certify their code. If they do, that just outrightly infringes the central principle of software testing. 

In this article, we will compare the differences between choosing external independent testers vs. choosing testers within the project’s organization.

First of all, we hope we can all agree that giving testers a certain degree of independence often makes finding bugs more effective. This happens because there are certain differences between the author’s and the tester’s cognitive biases. 

However, independence is not a replacement for familiarity, and developers can efficiently find many defects in their own code.

Test Independence Degrees (From Low To High)

  1. No independent testers – the only form of testing available is developers testing their own code.
  2. Independent developers or testers within the development teams or the project team – developers are testing their colleagues’ products.
  3. Independent test team or group within the organization, reporting to project management or executive management.
  4. Independent testers from the business organization
  5. Independent testers external to the organization, either working on-site (in-house) or off-site (outsourcing).

It’s usually best to have multiple test levels, with some of these levels handled by independent testers. We have found that it works best for most projects.

Additionally, developers should participate in testing, especially at the lower levels. By doing that, they can exercise control over the quality of their own work.

How testing independence is implemented varies depending on the software development lifecycle model. 

For example, in Agile development, testers may be part of a development team. In some organizations using Agile methods, these testers may be considered part of a larger independent test team. 

Additionally, product owners may perform acceptance testing to validate user stories at the end of each iteration.

Working with an In-house Testing Team

  1. The development team can be biased toward testing their own product. An unbiased and fresh point of view reveals defects that couldn’t be discovered otherwise.
  2. We regularly see the development manager reaching the testers – that’s harmful to the project. You cannot get the best out of your test engineers if they report issues to the person whose other team is responsible for it. In such scenarios, the metrics and quality might be manipulated. When testers are free from inhibitions, they can seek out more defects or discrepancies than those already working within the developing team.
  3. Testers might work in the same environment/location as the development team. Not having a different environment at a completely different location might hide certain bugs from happening.
  4. Sometimes, developers don’t like the idea of a testing team member in the same office. Since developers expect their code to be correct, they have a confirmation bias that makes it difficult to accept that the system is incorrect. Besides, it is a universal human trait to blame the bearer of bad news. And unfortunately, reports produced by testing often contain bad news.
  5. Limited staff pool. Having a local testing team will require finding talents from a limited pool of candidates in your surrounding area, along with their management and training expenses.
  6. Limited devices to test with, since they most likely will need to share them with the developers.

Potential benefits of working with independent testers external to the organization:

  1. We are likely to recognize different kinds of failures than developers because of our diverse backgrounds, technical perspectives, and biases.
  2. We testers can verify, challenge, or disprove stakeholder assumptions during the system’s specification and implementation.
  3. We report directly and objectively about the system under test without (political) pressure from the hiring company.
  4. Less management work. No need to hire and train testers.
  5. New discipline within the development team. People are always more careful when they know somebody will review their work.
  6. Impartiality. You get a fair assessment of the quality of the code. The metrics, data, and reports are relevant, honest, and unbiased.
  7. All the skills you need under one roof. You can rely entirely on one provider to take care of your QA needs. This is more likely to happen with an independent, specialized QA firm than with a software development firm.
  8. We have a broader knowledge of the application’s regression history than a developer. We have become familiar with all the nuances of the system and are proficient at testing. We are confident, self-assured, and think creatively.
  9. We are not afraid of trial and error. Failing to find a bug the first time only means that we need to think outside the box. We don’t accept that bugs are fixed unless we have proof.

Let’s talk more test independence benefits here:


Note: the information provided on this document can also appear in the ISTQB documentation.