In my previous blog post, I wrote about the importance of testing and how testing can reduce cost. Once testing is complete, the quality of the system can be improved by addressing any issues found. I hope that the article has helped to make testing clearer to those who are unfamiliar with it. Unfortunately, I’ve felt on many occasions that people are reluctant to commit to testing on a project. What is the reason for this? There is actually a psychological aspect that plays an important role here. You may question that statement but in this article I will explain everything.
Feedback from the testing process
As a tester, the delivery of test results with a list of defects for the developers to address is often seen as criticism. In my experience, the information presented by the testers is often seen as “bad news”. Instead of sharing an update that the system has been developed and that the product is ready, testers must often share the news that something isn’t working – meaning that the product is not ready.
I have worked on many projects where there is tension between the developer and the software tester whilst discussing the issues identified during testing. It is human nature to feel emotion towards something you have put a lot of time and effort into. Developers often feel that their ‘baby’ has been unfairly treated by testers who claim that something is wrong and needs to be fixed.
However, working in a professional capacity means you cannot let emotions take over. It is important to think about how you will deliver the news to the developers so that they do not feel criticised or take your feedback personally. I can say from my own experience that this is not always easy!
Psychological factors in Testing
All of this potential conflict is a product of psychological factors. One of the more common factors is called ‘confirmation bias’, which describes the difficulty in accepting that something you believe to be correct is actually recognised as being incorrect. Another factor, ‘cognitive bias’, describes the difficulty in accepting or understanding the information provided from the testing. These psychological factors tend to make some people view testing as being destructive, which is why it is often ignored or undervalued.
What we should not forget is that regardless of what your role is, be it developer, tester, project manager or business stakeholder, we are all working towards the same goal. Ultimately, we all want a software that meets the quality standard and ensures a happy customer. In order to minimise these psychological factors, there are a few things to keep mind.
It’s all about how you deliver the test results (it is not “bad news”!)
The information provided as a result of testing should be constructive, fact-based and neutral when shared. There should be no criticism of the developers or the quality of the software. No one is your enemy, it’s a collaboration.
In order for the defects to be understood and fixed, testers need to be able to present them in a way that developers will understand.
“The best tester isn’t the one who finds the most bugs or who embarrasses the most programmers. The best tester is the one who gets the most bugs fixed.”- Cem Kaner, J.D., Ph.D.
The above quote from Cem Kaner, co-author of “Testing Computer Software”, explains it all.
Establish Clear test objectives and communicate them effectively
Testing does not exist to make decisions but to provide information for business stakeholders to decide on whether the system is acceptable enough to be in live operation or not. Testing contributes to success in achieving the quality target.
When you cannot see a tangible product, it is hard to appreciate the value of it. Testing is one of those things that you cannot really see or touch as a product, although it does play a very important role in any successful software project.
So how can we make this clear to those who are new to testing? How can we show that testing adds value?
Setting clear testing objectives and listing tasks required to complete them are important to both project members and testers. By having clear objectives communicated early, people tend to understand what testers are supposed to do and can then behave accordingly.
All of these are documented in a test plan with additional information such as resources, risks and the level of testing required. A test plan presents a clear picture on the testing objectives and how to achieve the end goal.
Applying different mindsets achieves a higher level of quality in a software
Testers and developers usually have different mindsets when it comes to software. Developers strive to build a software that works, whilst testers focus on testing a software to see what could go wrong and how it can be broken.
Applying those different mindsets towards testing enables the project to achieve a higher level of quality as the software is looked at from different angles. It also ensures that the correct level of testing is executed by the right resources, therefore leading to the test coverage increasing. It is common to have a certain level of independence in testing so that new perspectives are applied to the software. Bringing all the different perspectives together in testing increases the quality and makes the end goal more achievable.
I hope this article gave you an opportunity to look at testing from a different point of view. As a person who studied psychology as a part of a university degree in pedagogy, I find this topic exciting. I wanted to share how human psychology affects software testing and investigate how we might overcome the emotional challenges often encountered in testing. In my next blog post, I will address testing after a software goes live. I will look at what happens after software is installed in live operation and ask whether or not we still need testing.