Psychology of Testing

Before starting with the topic – Psychology of Testing. Let’s first understand the software development life cycle and testing phase.

A typical software development life cycle consists of the following steps-

• Requirements Analysis
• Design
• Development
• Testing
• Maintenance

Each phase is critical for the success of the project. In this tutorial, we will focus on the ‘Testing’ phase. This phase is crucial for project success as it directly affects software quality and customer/user satisfaction.

The efficient and smooth flow of the testing phase helps in finding the bugs or defects in the system. In traditional methodologies, the testing phase starts only after the completion of the development phase.

However, nowadays, agile methodology is popular where the focus is on rapid releases due to which the testing and development process cannot happen in silos, they have to be carried out simultaneously. In either methodology, testing is an important step.

In the testing phase, the testers test the system thoroughly and try to find any bugs or defects in the system. With manual and automation testing we can achieve this.

As this process involves human intervention, the psychology of the whole process becomes crucial. Every person involved in the SDLC has a different view of the testing phase. For example, for a developer, the result of the testing phase is that the system works as per the requirements. For a tester, the focus is always on finding the defects.

A psychology of testing depends or involves three factors. Let’s discuss each of them in detail.

The Mindset of Developers and Testers

Before we start the discussion on this topic, it is important to note that developers also do the testing of the system. They mainly participate in the testing process during the unit testing level. Developers test the individual units developed by them. On the other hand, testers take part in integration testing, system testing, and sometimes acceptance testing levels.

Developers are responsible for creating or developing the system. Based on the requirements communicated by the business analyst, they code the features of the system i.e. they build the system. While developing the system, developers have a mindset of creating something new, something useful for the end user.

Testers, on the contrary, try to break the system using various means to identify any errors or bugs in the system that will stop the end user from using the system in the desired manner.

Testers have a different mindset than developers, they analyze the developed system and look for any defects that deviate the system from the actual requirements communicated by the business analyst.  

Before we move to the next factor, it is important to understand that both the resources, developers, and testers have a different mentality and they work accordingly. 

Polite and Clear Communication

As discussed earlier, testers find mistakes or errors in the system and communicate these findings with the developers. It is an obvious human tendency not to welcome your mistakes, especially identified by other persons. For a tester, finding the bugs is an accomplishment. But at the same time, for a developer, it is a mistake in his/her work and extra time will have to be spent on correcting the mistakes. For others e.g. project managers or clients, this is a halt that will stop the successful deployment of the code. 

Due to these reasons, we sometimes consider testing as a destructive activity and not a constructive activity. Thus, it becomes necessary that the testers communicate the findings of the testing process in a polite and clear manner.

Points to remember for effective communication

The following are some important points that we should keep in mind while communicating with the developers and any other members-

• Testers should communicate in a way that the focus is on explaining the mistakes in the system and the criticism is not towards any individual’s work.  
  
  
• While explaining the bugs, the testers should describe how it is varying from the actual requirements and how they will impact the end-user. Also, with the help of a project manager or any related parties, the priority of the bug should be included as well. It will help the developer in managing his work.
  
  
• The bug report should be clear, it should include a description of the bug, all the necessary steps to reproduce the bug along with the actual and expected results. In addition, if possible, testers should try to include any screenshots or videos of the bugs.
  
  
• The communication should always be in a professional, friendly, and collaborative manner. Testers should try to understand developers’ points of view as they might take the findings in a negative way.
  
  
• Testers should make sure that the bugs have been explained clearly to the developers and developers have understood them. It will eventually save time as an unclear explanation might result in another bug and, developers and testers will again have to spend time on it.
  
  
  

Test Independence

The third and last factor is test independence. Finding mistakes in your own work is possible but not an effective idea. Developers, after building the product, test their code at the unit testing level. Developers can also perform integration testing and system testing.

But again, looking for bugs in your own features of the system may not be helpful and fruitful. Thus, we need the help of an outsider who doesn’t work on the coding part.

Such people can be other developers, testers, clients, and end-users. Mostly, in an organization, a dedicated testing team is responsible for the testing process.

Sometimes, people outsource the testing part. If we look at the different testing levels, we can understand it more clearly.

• Unit Testing – In this level, developers test their own code. For the unit or module on which they have worked.
• Integration Testing – In this level, the testing team tests the different integrated modules. 
• System Testing – In this level, the testing team tests the whole system.
• Acceptance Testing – In this level, clients or their representatives and end-users test the system.
  
  

Test Independence Levels

Now, let’s talk about the test independence levels.

• The first level of independence, where independence is very low. In level, test cases are designed by the developer who has worked on the feature(s) for which testing is to be done.
  
  
• In the second level, independence is low. Here, test cases are designed by another developer who has not worked on the feature(s) for which testing is to be done.
  
  
• In the third level, independence is medium. Here, test cases are designed by a dedicated testing team of the same organization.
  
  
• In the fourth level, independence is high. Here, test cases are designed by a dedicated testing team of other organizations i.e. the testing process is outsourced.
  
  

Instead of developers, when a separate team is used to test the system, results will be superior. This is due to many reasons such as end-to-end understanding of the system, analytical abilities to find any errors, experience in the testing process, etc.

Conclusion

For a successful testing process, not only thorough testing is required but also the understanding of the psychology of testing is also very important. Finding bugs is not enough, properly communicating them with the developers, understanding their perspective is important, too.

At the same time, developers should also understand the tester’s outlooks. The tester is a resource dedicated to finding system bugs and their goal is to achieve the highest possible quality, eventually affecting end-user experience. The success of the testing process demands contribution from both sides.