Psychology is “The science of human experience and behavior”. This is a very broad definition. It begins with what a person thinks, feels, or how they express themselves through their actions. And finally, how groups behave and what effects occur in the interaction between people.
Testing of software contains some stumbling blocks and peculiarities that are very predestined to trigger conflicts, because of social structures. Testers have the goal of ensuring the quality of the product so that the end user can both trust that it’s doing its job, as well as having a pleasant user experience. A means to this is for example, errors. However, during the testing there is a lot of room for discussions, conflicts, and criticism – ideal conditions for confirmation and ingroup bias!
This is precisely where many theories and effects come in, which also accompany us in our daily work. Due to the large number of groups that meet and the communication of errors, the test is almost an ideal example of such theories and the resulting problems that we are about to explore. Whether developers react with conflict to an undesired formulated error, or you come out of a meeting and ask yourself how you came to this conclusion, this is all based on social phenomena.
But what exactly does this look like in practice? How can such effects be detected? What does all this have to do with the test? What problems might arise from this? And most importantly, what can we do about it and how can we prepare for it?
In the following, only a few, but frequently occurring effects are presented, in which many will say: “I know that!”. For most of you, you’ll probably say, “It can’t be that dramatic. At some point, someone will speak up or reflect in such situations?” Unfortunately, it is usually not that simple. A lot happens subconsciously, and attention and knowledge are necessary to recognize such situations.
Groupthink is a tendency of groups to adapt to the group opinion in decision-making situations, as their own critical and reflective thinking is suppressed, and new information is ignored. This manifests itself, for example, in a way that group members have an opinion contrary to the group or form one during the decision-making process. Still, nevertheless do not contradict or even persistently adhere to their original opinion. One reason for this may be a strong authority in the group.
Another might be that there is an initially uniform opinion in the group, which is conditioned by little information. Even if more information is added over time and opinions change, no one wants to contradict the overall group opinion. Now you may think to yourself, “If there is a big decision to be made, someone will speak up about their doubts. That can only happen with unimportant topics.” Unfortunately, this is often not the case. This phenomenon was researched in the 70s, due to some wrong decisions in US history (Watzka, 2014).
Confirmation bias, or confirmation error, denotes the tendency to prefer information that corresponds to one’s own settings. Conversely, this means that it can sometimes be very difficult to accept information that contradicts these attitudes (Boerdlein, 2000). What does this mean in concrete terms in the work context? Imagine experts from a specialist area or even a professional athlete. These people will find it much more difficult to accept if they are told that their skills or knowledge are slowly getting old or that they are not good at certain topics in their field. Much more likely, they will stick to their opinion and try to convince you otherwise or attribute a mistake to other factors.
The ingroup bias describes the phenomenon that one’s own group is valued higher than others. This is due, among other things, to the feeling of togetherness or the group identity. As a result, the group is rather critical to disapproving towards outsiders (Mullen, Brown & Smith, 1992). This can go so far that a group increases its self-esteem by overemphasing its own group and negatively downplaying others. In extreme forms, this distortion of perception can often be found in large corporations with strong silo thinking. There it happens that departments that, for example, bring in sales, see themselves as elite and clearly distinguish themselves from other departments such as processing. But even to a lesser extent, there are often clear boundaries between departments or groups that like to harden in conflict situations (Weinkauf et al., 2005).
Why is the test such a special situation when it comes to these effects? Because they can occur in any company, regardless of the industry or the structure.
However, the testing of software contains some stumbling blocks and peculiarities that are very predestined to trigger conflicts, in terms of social structures.
On the one hand, different people or groups with different goals meet during the testing. Testers have the goal of ensuring the quality and trustworthiness of the product. Developers want to implement a good product and are often creative and perfectionist in their work. Ideally, a department head would also like to participate and get first insights into the product. It is not uncommon for them to notice things that may have been described insufficiently or differently in advance, but which could be very important for production. In addition to all this, there is usually stakeholders such as project managers precent. They have to keep an eye on the budget and time in this discussion, and in the end, they have the authority to make final decisions. It quickly becomes noticeable that many people come together during the testing phase, which offers a lot of room for discussions, conflicts, and criticism – ideal conditions for confirmation and ingroup bias!
The later the test is integrated into the development, the higher the pressure gets on developers and testers. High quality requires time and resources, but these are precisely the factors that often become scarce. Especially, if in retrospect requirements must be changed again, or that they have been misunderstood or misinterpreted. This pressure can cause stress among the participants, which is an influencing factor in the development of conflicts (Rosenstiel, Domsch & Regnet, 2003). It is precisely these conflicts that create situations that can be responsible for the different groups.
Finally, the test is a continuous process in which questions arise again and again and decisions must be made. Especially for questions that do not directly affect the function, such as the user experience where there is a lot of room for interpretation and individual views. However, a correct initial feedback on the functional product is often only available during the testing, at the latest in the user acceptance test. Wishes for fundamental changes in the structure and design can arise, which, however, mean high expenses.
The decisions should be well considered at this point. Just at the point of the User Acceptance Testing (UAT), in addition to budget and time, there are also the prioritization of open errors. On the other hand, the decisive factor for the quality in the end is largely the satisfaction of the users. Decisions for or against fundamental changes must therefore be well considered. If you notice that someone else or yourself has concerns, you should ask again. This is where group thinking can quickly strike.
Basically, one should not overinterpret every situation. Conflicts or disagreements do not have exclusively negative sides. Through them, various perspectives and aspects come to light and employees are obliged to think about it. However, it is important to prevent strong conflicts, which can lead to wrong decisions or hardened fronts.
A core aspect of testing, which is also highlighted by various training courses, is that testing is value-free. Mistakes should therefore not be understood as criticism, but rather as cooperation for optimization. The goal of testing is high quality and thus a success factor for software projects that is in the interest of all parties involved! To ensure this, not only the testers should have understood the test, but all participants, including developers and departments, should be trained accordingly. Of course, in different depths.
Another fundamental aspect, which you notice almost like a mantra in the basics of testing in training courses and seminars, is that testing and quality does not start with the first developed module, but far before. The test should therefore be integrated into the project as early as possible and starts with the first documents. According to our principles, quality even begins with the first thought of a new project. As a result, comprehension problems can be clarified even before development and differences of opinion can be avoided. Thus, not only conflicts or wrong decisions can be avoided, but also the effort of all parties involved can be minimized. With these points, it is a good idea for all participants to train or coach accordingly, so that the basics of testing and the idea of quality is implemented throughout the entire development process, from management to departments, to testers and developers.
Ultimately, many of these effects are based on communication that is not clear or open to everyone. On the one hand, it is therefore important to sharpen the sensitivity for such situations. For this, basic knowledge is usually sufficient to notice that it may be necessary to follow it up again. In addition, honest and open communication between the various groups should be encouraged. Agility sets a good example here. By promoting interdisciplinarity, feedback and cooperation, many ambiguities are clarified before they can even lead to problems.
As in any efficient and creative environment, all members of a development project should also be able to talk to each other at eye level and clearly address their motives! Depending on the project organization, the task lies on the one hand, of course, with the management, but also with each individual. Everyone should speak up in case of doubts or problems, this helps everyone involved and also significantly increases the fun of the work in the long term! In hardened problem situations, it is also advisable to always bring neutral people to it for controlled communication in order to advance the clarification.
Data Responses subsidiary, Frobese GmbH accompanies you and your employees: inside, with trainings or as a partner, preferably in your development projects.
This article was originally published on Frobese’s blog.
Sources:
Boerdlein, Christoph (2000) Die Bestätigungstendenz. Warum wir (subjektiv) immer Recht behalten, https://www.researchgate.net/publication/283304451_Die_Bestatigungstendenz_Warum_wir_subjektiv_immer_Recht_behalten, Abgerufen am 01.03.2021
Mullen, Brian; Brown, Rupert; Smith, Colleen (1992) Ingroup bias as a function of salience, relevance, and status: An integration, European Journal of Social Psychology, Seiten 103-122
Von Rosenstiel, Lutz; Regnet, Erika; Domsch, Michel (2003) Führung von Mitarbeitern 5. Auflage, Schäffer Poeschel, Berlin
Watzka, Klaus (2014) Personalmanagement für Führungskräfte, Gabler Verlag, Wiesbaden
Weinkauf, Katharina; Högl, Martin; Gemünden, Hans Georg; Hölzle, Katharina (2005) Zusammenarbeit zwischen organisatorischen Gruppen, Journal für Betriebswirtschaft 55, Seiten 85-111