The Psychology of Testing – Foundation Level 2018 ISTQB

1.5 The Psychology of Testing

The software development process is not done on its own or by itself, there are human beings involved in the process of developing software, including software testing and human psychology has a significant role to play and the results of testing. This part always fascinated me as even though the systems are logical, it is either 0 (zero) or 1 (one), yes, or no, true or false and based on facts, but facts can be deceived by opinions, expression, interpretation, feelings, focus, ambiguity and many more other variations that can only be (half) explained from the psychological point of view.

Image: @Pixels by Kindel Media

I quote from ISTQB Foundation Level 2018 syllabus…

“Software development, including software testing, involves human beings. Therefore, human psychology has important effects on software testing.”

1.5.1 Identify The Psychological Factors That Influence The Success Of Testing – Human Psychology And Testing

This section is relatively simple but not easy to do, as it all depends on each individual; all I can say is, if you master the basics and understand this and strive to do the best that you can in your line of duty, you can take over the world (of testing).

When interviewing candidates, for a new role in testing, this is one of the most important things I consider in my list of questions and also to help me understand the potential tester I am allowing to get into my team.

The right set of test objectives was discussed earlier. Testers’ adherence to team objectives impacts their personal bias. It is important to understand this for psychological reasons. People tend to align their plans and behaviours with those within their team, management, and other stakeholders.

It can be difficult to accept negative feedback on a project, mainly if it is collected during a dynamic test or requirement review or story refinement session. When a product is evaluated statically, it can be challenging to accept that it has defects. The human psyche tends to accept “facts” (I say that in quotes as many times opinions can be masked as facts) that confirm previously held beliefs, a cognitive quirk known as confirmation bias.

For example, developers’ tendency to believe their code is error-free makes it difficult to accept that it’s wrong. In addition to confirmation bias, other cognitive biases may make it difficult for people to comprehend or get facts generated by testing. The bad news is shared in testing results, and it is natural for people to blame the messenger for it.

Some people may consider testing a destructive activity, despite its importance to project progress and product quality. Conflicts between testers and analysts, product owners, designers, and developers can be lowered by communicating information about defects and failures positively. This applies to both static and dynamic testing.

Testers and test managers must communicate effectively about defects, failures, test results, test progress, and risks, as well as establish positive working relationships with their colleagues. The following are examples of effective communication strategies:

Earlier, the correct test objectives were covered. Having the right test objectives is significant for psychological reasons. Most people align their plans and actions with those established by their team, management, and other stakeholders. Testers must also adhere to these objectives without introducing excessive personal bias.

Here’s a quote from the ISTQB Foundation Level 2018 syllabus…

Identifying defects during a static test such as a requirement review or user story refinement session, or identifying failures during dynamic test execution, may be perceived as criticism of the product and of its author. An element of human psychology called confirmation bias can make it difficult to accept information that disagrees with currently held beliefs. For example, since developers expect their code to be correct, they have a confirmation bias that makes it difficult to accept that the code is incorrect. In addition to confirmation bias, other cognitive biases may make it difficult for people to understand or accept information produced by testing. Further, it is a common human trait to blame the bearer of bad news, and information produced by testing often contains bad news.

As a result of these psychological factors, some people may perceive testing as a destructive activity, even though it contributes greatly to project progress and product quality (see sections 1.1 and 1.2). To try to reduce these perceptions, information about defects and failures should be communicated in a constructive way. This way, tensions between the testers and the analysts, product owners, designers, and developers can be reduced. This applies during both static and dynamic testing.

Testers and test managers need to have good interpersonal skills to be able to communicate effectively about defects, failures, test results, test progress, and risks, and to build positive relationships with colleagues. Ways to communicate well include the following examples:

• Start with collaboration rather than battles. Remind everyone of the common goal of better quality systems.
• Emphasize the benefits of testing. For example, for the authors, defect information can help them improve their work products and their skills. For the organization, defects found and fixed during testing will save time and money and reduce overall risk to product quality.
• Communicate test results and other findings in a neutral, fact-focused way without criticizing the person who created the defective item. Write objective and factual defect reports and review findings.
• Try to understand how the other person feels and the reasons they may react negatively to the information.
• Confirm that the other person has understood what has been said and vice versa.

Typical test objectives were discussed earlier (see section 1.1). Clearly defining the right set of test objectives has important psychological implications. Most people tend to align their plans and behaviors with the objectives set by the team, management, and other stakeholders. It is also important that testers adhere to these objectives with minimal personal bias.

ISTQB 2018 Foundation Level

1.5.2 Explain the difference between the mindset required for test activities and the mindset needed for development activities – Tester’s and Developer’s Mindsets

This section is pretty simple, and I have expanded this a bit more in another post I have published here on this website. Which Mindset Are you? Tester or Developer, in which I cover what is a mindset and how it is shaped throughout our lives and the influences that we collect throughout our life journey it could not be different here with the development and testing approach, but crucially, you got to understand these few fundamentals so you can succeed well in the testing career.

Image: FreeImages

And I quote from my own previous post here the relevant part that will be in the ISTQB exam.

TESTER MINDSET

As a tester, your primary responsibility is to determine whether a business problem has been solved. That is, you test if the software meets the customer’s requirements. You will also identify problems or risks that could impact the project and provide recommendations on how to overcome these risks. A tester’s job revolves around risk management, decision-making, and critical thinking. A tester’s mindset is rule-based. They rely on their experience and past knowledge to make decisions. If a new situation is similar to one they’ve experienced before, they will apply a similar solution. Testers are rule-based thinkers, meaning they base their decisions on existing frameworks and rules. They are driven by the question, “What if something goes wrong?”. Their primary goal is to prevent mistakes and risks.

DEVELOPER MINDSET

As a developer, your primary responsibility is to create a solution to a business problem. This could mean designing, coding, testing, and deploying the solution, or it could mean collaborating with other team members to do it. Developers are primarily driven by curiosity – they are constantly asking “Why?” and “How?”. The “why” part comes from the need for problem-solving and exploration. The “how” part comes from their desire to build things. Developers are curious thinkers, meaning they are motivated by the desire to create new things. They are driven by the question “How can we make this better?”. Their primary goal is to create something useful.

The ISTQB specifically covers the tester objectives including “verifying and validating the product, finding defects prior to a release, and so on” and the Developer’s objective is to “design and build a product” with the eye to what it can work rather than what could go wrong with it. On both parts, there are exceptions to the rule and that comes also with experience and common sense throughout the career lifespan.

Here’s the quote from the ISTQB Foundation Level 2018 syllabus…

“Developers and testers often think differently. The primary objective of development is to design and build a product. As discussed earlier, the objectives of testing include verifying and validating the product, finding defects prior to release, and so forth. These are different sets of objectives which require different mindsets. Bringing these mindsets together helps to achieve a higher level of product quality.

A mindset reflects an individual’s assumptions and preferred methods for decision making and problem-solving. A tester’s mindset should include curiosity, professional pessimism, a critical eye, attention to detail, and a motivation for good and positive communications and relationships. A tester’s mindset tends to grow and mature as the tester gains experience.

A developer’s mindset may include some of the elements of a tester’s mindset, but successful developers are often more interested in designing and building solutions than in contemplating what might be wrong with those solutions. In addition, confirmation bias makes it difficult to become aware of errors committed by themselves.

With the right mindset, developers are able to test their own code. Different software development lifecycle models often have different ways of organizing the testers and test activities. Having some of the test activities done by independent testers increases defect detection effectiveness, which is particularly important for large, complex, or safety-critical systems. Independent testers bring a perspective which is different than that of the work product authors (i.e., business analysts, product owners, designers, and developers), since they have different cognitive biases from the authors.”

ISTQB 2018 Foundation Level

That’s it for this section. Please tell me what you think. Any feedback is welcome. Thank you and see you at the next one.

If you prefer to watch the whole video about this section in one go instead of parts of the video as I have embedded them above, go and watch it here…

Don’t forget to subscribe, like and share. It will support this channel, will help others and will motivate me to create even more content for everyone.