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
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; this can be achieved by either manual or automation testing. Usually, both manual and automation ways of testing are used.
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, and 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 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 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 analyse 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 of not welcoming 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, testing is sometimes considered 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. The following are some important points that should be kept 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 it 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.
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 coded features of the system may not be helpful and fruitful.
Thus, the help of an outsider who has not worked on the coding part is required. 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, the testing part is outsourced. 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.
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 due to many reasons such as end-to-end understanding of the system, analytical abilities to find any errors, experience in the testing process.
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 testers’ outlook; 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.
Kuldeep is the founder and lead author of ArtOfTesting. He is skilled in test automation, performance testing, big data, and CI-CD. He brings his decade of experience to his current role where he is dedicated to educating the QA professionals. You can find him on LinkedIn and also follow ArtOfTesting’s LinkedIn page.