A Culture of Criticism in Software Companies
A Culture of Unnecessary Criticism in Software Development
Software testing is very important for software development, but programming is the core functionality in software development organizations. It is true that people who work on the core functionality are considered to be more important and get more visibility than others. In software applications, if anything goes wrong, no matter whether it's a tester’s fault or not, they face a lot of unnecessary criticism from software development managers and organizations.
Tester: The Scapegoat
Software testing needs to be performed in all software development organizations, and the worth of a tester cannot be ignored because of the value they can add to the software applications.
A few years ago, one of our clients faced an issue in the product, and our development manager sent a message to the QA group with the text “Who tested this?”. After this, another bombardment of messages was sent regarding the tester's performance. Testers were accused of the customer problem. Later on, it was determined that the problem occurred due to the database script not being executed completely at the customer site. This is a normal practice in many software companies, especially in South Asian countries. If you are a tester, you are familiar with this kind of attitude toward testers. When I faced this situation, I realized that the problem does not lie in the tester. The root cause is somewhere else, but the tester is the center of criticism. From my experience, I have seen this critical attitude toward testers from developers, development managers, and even the entire organization. The strange part is that testers take it as part and parcel of the job and do nothing about it.
If a software application behaves in an unexpected way, it does not mean that it's always due to a tester’s negligence. There could be several reasons behind this, such as code merging, deployment, a third party library expires in production and breaks certain functionality, or a database script execution issue. None of these problems relate to testers, but if any problem occurs, we all know where to point our fingers—it’s towards the tester, right?
Testers are treated like scapegoats in many software companies. The culture of criticism is so deeply ingrained, even upper management cannot escape this awful behavior. The criticism has taken many shapes, such as the blame game, calling a meeting and having testers explain why/how they missed a particular scenario, interrogation, judgmental comments about tester performance, group emails and messages, and always suggesting that only QA needs to improve. Most of the time it is the development process that needs to improve, because the tester has to align their test process with the development process. This intolerance and absurd behavior is not only disrespectful, it also makes testers less efficient and unmotivated. The intolerance level increases significantly when testers work as part of an offshore QA team.
Do managers have the same behavior toward developers, designers, or other stakeholders on the team? The answer is an obvious no, so why testers? What can we do to eradicate this culture of unnecessary criticism?
Tester: The Quality Gatekeeper
It is a practice in software development companies that only testers are responsible for software quality, and that's why they are held accountable for any sort of problem in software. This mindset needs to change. Everyone should be responsible for quality, including business analysts, architects, software designers, developers, development managers, testers, and the change management team. Product quality should not be measured from testing only. Each development phase should maintain its level of quality and make sure quality is in place from the very beginning of the software construction process. When everyone on the team plays their part in achieving a mutual quality goal, then the team's attitude toward testers will also change, and it will also help build a healthy relationship between all team members.
Tester: The 100 Percent Quality Achiever
An interviewer at the beginning of my career asked me how can someone achieve 100 percent quality. This really made me wonder—Can someone really achieve 100 percent quality? Tech giants like Google and Microsoft face quality issues, and even a layperson can find a bug in their products. Does it mean that their testers are not good enough?
This mindset that testers can ensure that the product quality is 100 percent needs to change. That’s why a small bug or a problem not caused by testers creates unnecessary criticism for the testers.
Over the years, I have worked for several companies in different industries. I have observed that nothing is perfect; everything has the opportunity for improvement. Constructive criticism should always be welcomed, which is good not only for the improvement of software but also for the people as well. Tech companies need to be more tolerant. Testers are also humans, and they can make mistakes just as developers or other team members can.
In order to achieve software quality, we always talk about improving the process and product, but I think development managers and tech companies need to improve their attitude as well.
Very well covered. Such issues were shadowed in the past but now things become more prominent
Wonderful topic with some great points deserving of expansion.
I'd like to highlight some things that come out of this article.
First is the conception of quality, as you point out. There is this idea, quality is relegated to the realm of testers. Quality is everyone's job. Fixing quality once they make it to QA is exponentially more expensive than resolving at the stage where it is created. Getting to the heart of this type of quality transformation requires QA to be at the front of the process, not the end. Agile makes provisions for this using XP practices such as TDD and paired programming.
Additionally, the talents of the QA team are best leveraged ahead of the time-disappearing period at the end f the process. Helping teams design tests, educate teams, and product owners on testing scenarios to generate consensus and focus, BEFORE money is spent on programming processes and functions that are of little value.
And as you point out, this is cultural, in many instances it's easier to blame QA than it is for the organization to deal with its shortcomings.