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.
Degrees of independence in testing include the following (from low to high):
- No independent testers – the only form of testing available is developers testing their own code.
- Independent developers or testers within the development teams or the project team – developers are testing their colleagues’ products.
- Independent test team or group within the organization, reporting to project management or executive management.
- Independent testers from the business organization or user community or testers specialized in usability, security, performance, regulatory/compliance, or portability.
- 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. It works best for most projects.
Also, 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.
Having a software testing team on site has its pros and cons. Here, we’re going to compare local vs. independent QA teams.
Disadvantages of working with an in-house team:
- A chef should not certify the dish they made. Developers who coded the product should not also be testing it. Businesses hire objective 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.
- Independent testers are likely to recognize different kinds of failures than developers because of their diverse backgrounds, technical perspectives, and biases.
- An independent tester can verify, challenge, or disprove stakeholder assumptions during the system’s specification and implementation.
- Independent testers report directly and objectively about the system under test without (political) pressure from the company that hired them.
- 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. It can be essential for the market success of the software product.
- We regularly see testers reaching to the development manager – that’s harmful to the project. You cannot get the best out of your QA leads and QA 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.
- Sometimes developers don’t like the idea of a QA 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.
- Limited staff pool. Having a personal QA team will require finding talents from a limited pool of candidates in your surrounding area, along with their management and training expenses.
Advantages of working with an unbiased remote team:
- Less management work. No more hassle hiring and training testers.
- New discipline within the development team. People are always more careful when they know somebody will review their work.
- We align our quality goals with the customers. The SLA’s are decided between us.
- Impartiality. You get a fair assessment of the quality of the code. The metrics, data, and reports are relevant, honest, and unbiased.
- All the skills you need under one roof. You can rely entirely on one provider to take care of all your QA needs. This is more likely to happen with an independent, specialized QA firm than with a software development firm.
- Good testers have a broader knowledge of the application’s regression history than a developer. They are familiar with all the nuances of the system and are proficient at testing. They are confident, self-assured, and can think creatively.
- We are not afraid of trial and error. Failing to find a bug the first time only means that we need to execute extra creative tests. Our testers believe in defects and don’t accept that bugs are fixed unless they have proof.
- QA testers and developers work best together. Pure code-based testing fails because it lacks the human factor. QA testers enhance the success of tests by providing a human element to anticipate that.
Let’s talk more third-party testing benefits here:
Note: the information provided on this document can also appear in the ISTQB documentation.