Independent testing corresponds to the testing performed by an independent team. Any entity other than the developer can be considered as an independent team, and the main purpose of this type of testing is to avoid author bias and is often more effective at finding defects and failures.

There are four levels of independent testing which I have stated below:

1. Tests done by the person who wrote the item. This is the lowest level of independence.
2. Tests done by another person within the same team, like another programmer or team member.
3. Tests performed by a person from a different group or team such as an independent test team.
4. Tests performed by a person(s) from a completely different organization or company, such as an outsourced testing or certification by an external body.

The levels are mentioned in the order of increasing levels of independence, with the last (fourth) level providing the highest level of independence.

I will state a scenario in which I was involved with independent testing of both the highest level as well as the second level.

The Sign Up page of a project that is currently under development was assigned to a vendor for independent testing. At the same time, the testing of browser compatibility of an html was assigned to a member of the same development team.

From the results that this experiment brought in, I was clear that both methods have their pros and cons. Here are a few to state.

Pros and Cons:

– The independent testing done by a vendor out of the organization was effective in its test coverage.
– The quality of output by the independent testing team was commendable and good, with no misleads.
– While the browser compatibility test done by the team member did not meet the test coverage in entirety, the output was quick and within deadline.
– The independent testing team provided by the vendor delayed its turnaround time and had to be followed up constantly.

The quality of output by the independent testing team was commendable and good, with no misleads.

While the browser compatibility test done by the team member did not meet the test coverage in entirety, the output was quick and within deadline.

The independent testing team provided by the vendor delayed its turnaround time and had to be followed up constantly.

To put it in a nutshell, the method or level of independence required depends on several factors including the project, involved teams, nature of requirements, methodology adopted, and so on. On an overall perspective, while the quality and output from an independent testing team of the highest level is certainly much better, there is a slight loss of control when it comes to time and deadlines.

Being an outside organization, it becomes slightly difficult to exert control over the deadlines and their involvement. When independent testing is done within the team, there is a sense of bias towards team members and thereby can have compromises on the quality of testing output.

I have outlined the benefits and risks of independent testing based on my reads, trials and experience.

The benefits of independent testing:

1. An independent tester can bring in a different set of assumptions to testing and reviews, and this can help in exposing new dimensions, hidden defects (if any) and issues.
2. An independent tester can be honest irrespective of whom he reports to, without having concerns for pointing out his/her colleagues in the process.
3. An independent test team often has a separate budget, which enables to keep track of the expenses on tester training, testing tools, test equipment, etc.

Risks:

As I mentioned above, there certainly are risks to an extent with handing over the testing part of an application/software being developed, to an entirely independent team.

1. Interpersonal isolation by other members of development: For example, the testers could possibly get isolated from the programmers, designers and the rest of the project team.
2. It could result in the refusal of prioritisation of defects from a business objective or obsession over finding defects in the developed/developing application/system.
3. This can certainly, as you know, lead to discomfort or hostility lurking into the working environment and culture.
4. Of course, this in turn can cascade into more serious disruption of harmony through blame games, lack of support for the overall project goals, lack of relating or associating with any issue thereby, etc.
5. Apart from within the project team, other stakeholders involved with the project can view the independent test team as a bottleneck or a potential delay to overall progress of the project.
6. Another risk that could arise is the developers / programmers can relinquish responsibility of quality deliverance in the project. They could develop an attitude that there is an independent test team, which is supposed to handle and dig out all defects, and thereby not perform religious unit testing on their code, etc.

Therefore, as with any concept that is put in to use, independent testing is both useful as well as risky, depending on the nature and situation the project is in. In an ideal world, we shall have an independent testing team within the organization for which there is a separate budget and a specific goal. And yet an environment that is harmonious for the successful completion of the project. It will also depend on the role played by the organization as a whole in achieving this.

On the whole, it is certainly beneficial in most occasions to perform independent testing on an application (or parts of it) in order to uncover as many defects as possible, and develop an application that has near to zero issues.