ISTQB CTFL Tester Skills, Whole Team Approach and Independence of Testing

A tester needs six groups of generic skills, and the syllabus pairs each group with what it contributes. Knowing the pairing matters more than memorising the list, because a scenario usually describes a behaviour and asks which skill it shows.

Two near-twins are worth separating. Testing knowledge is about testing itself (techniques, levels, approaches); technical knowledge is about the technology and tools used to test. A tester designing tests with a test technique shows testing knowledge; a tester scripting test data or working with a tool shows technical knowledge. Likewise, domain knowledge is about the business the software serves, not about software or testing.

Testers must communicate defects constructively because they are often the bearers of bad news, and people tend to blame the bearer. A test result can be heard as criticism of the product and of its author, and some people see testing as a destructive activity, even though it contributes greatly to project success and product quality.

Confirmation bias makes this harder: it is the tendency to find it difficult to accept information that disagrees with what one currently believes. A business analyst who wrote a requirement may dismiss a failure reported against it because it contradicts their belief that the requirement is complete, not because the evidence is weak.

Constructive communication means:

• describing each failure objectively and factually: what was done, what was expected, what happened;
• keeping the report about the work product and its behaviour;
• reporting each defect clearly enough that it can be understood and acted on;
• presenting testing as a shared contribution to quality.

This is why communication skills are described as crucial for testers: the value of a found defect is lost if the report is not accepted.

The whole team approach is a practice, originating from Extreme Programming (XP), in which any team member with the necessary knowledge and skills can perform any task and everyone is responsible for quality. Job titles do not decide who does a task; skills do. Quality is a shared responsibility of everyone on the team.

Team members share a common workspace, which can be physical or virtual, because co-location makes communication and interaction easier. A distributed team working in a shared virtual workspace can still follow the approach.

The approach rests on closeness: people with different skills work together throughout development. Independent testing, covered later in this lesson, rests on the opposite idea of deliberate separation between author and tester.

The whole team approach has three advantages listed in the syllabus:

• Improved team dynamics;
• Enhanced communication and collaboration within the team;
• Synergy, because the various skill sets within the team can be leveraged for the benefit of the project.

All three advantages come from people working closely together. The benefits of independent testing, described below, come from separation instead, so the two practices pull in different directions and their advantages should be kept apart.

In a whole team, testers work closely with the other team members to make sure the desired quality levels are reached. The syllabus names two specific collaborations:

• with business representatives: helping them create suitable acceptance tests;
• with developers: agreeing on the test strategy and deciding on test automation approaches.

Through this collaboration testers transfer testing knowledge to other team members and so influence the development of the product, beyond the testing they do themselves. Their influence comes from sharing what they know and collaborating, while responsibility for quality stays with the whole team and developers continue to test their own work.

The whole team approach is not always appropriate, and the syllabus's example is safety-critical software, where a high level of test independence may be needed. Depending on the applicable standards, regulated domains such as avionics or medical devices may require verification by people outside the development team.

The syllabus does not prescribe a fix, but a common practical approach is to combine the two practices: the team keeps its collaboration and its own testing, and testing by people outside the team supplies the independence the context demands. Shared ownership of quality and independent verification answer different needs.

Independence of testing describes how far the person testing a work product is from its author. The syllabus defines four levels:

The level is decided by three questions about the tester: same person as the author? Same team? Same organization?

The main benefit of independent testing is that independent testers are likely to recognize different kinds of failures and defects than developers, because they have different backgrounds, technical perspectives and biases. The syllabus also states that a certain degree of independence makes the tester more effective at finding defects, due to differences between the author's and the tester's cognitive biases: an assumption the author never questioned can be one the tester naturally tests.

A second benefit is that an independent tester can verify, challenge or disprove assumptions made by stakeholders during specification and implementation of the system, for example by asking whether a stated peak-load figure in the specification was ever validated.

In both cases the value comes from a different perspective on the same work product.

Independent testing has three drawbacks:

• Isolation: independent testers may be isolated from the development team, leading to a lack of collaboration, communication problems or an adversarial relationship with the developers;
• Lost responsibility: developers may lose their sense of responsibility for quality, assuming the testers will catch everything;
• Bottleneck and blame: independent testers may be seen as a bottleneck or be blamed for delays in release.

Notice that the drawbacks come from separation and from shifted responsibility rather than from the different perspective itself. That is why a common practical way to limit them, beyond what the syllabus states, is to keep independent testers in regular, early contact with the developers while developers stay responsible for testing their own work.

Independence does not replace familiarity: developers can efficiently find many defects in their own code because they know it well. More independence is therefore not automatically better.

For most projects it is usually best to test with multiple levels of independence, for example:

• developers performing component and component integration testing (familiarity);
• a test team performing system and system integration testing (high independence);
• business representatives performing acceptance testing.

Each level contributes something the others lack. The author knows the code and finds many defects quickly; someone further away brings different assumptions. Suppose a developer builds a monthly report expecting it only ever to be run over one month of data. A tester from another team, who never shared that expectation, runs it over several years of data and it times out. Combining both perspectives catches more than either alone.