TESTERS CAN (!) STOP BAD SOFTWARE
Regrettably, this is not the case in real life. Yes, it is true that testers want to have the rejection power in our hands, but under tight deadlines and upper management pressures quite a lot of the deliveries happen with a bunch of deficiencies and unfixed defects.
Maybe you are asking, how can this even happen? Let me assure you, this is a very standard daily life scene in any software project. Everyone in the project knows that the software will crash, but no one can prevent it. That’s all because of the unrealistic delivery promises given to business by IT upper managers. If these people cannot stand against relentless business demands, how could a test manager or a tester do so? It is sad but true.
Unfortunately, the very first thing that I learned from my early software testing experiences is that finishing the task on time is always more important than doing it in a proper way. In other words, you are expected to finish testing on time rather than do it with high quality and coverage.
From another perspective, when developers realize that the “promised delivery” will happen whether or not the test department says OK, then how can we expect high quality and accuracy from them? Yes, developers will try to fix the high-priority bugs, but will their respect for testers remain the same? Will there be any accountability between the developers and testers?
Without doubt, if you want to have a bug-free application running in production, you should give authority to your testers and empower your test teams. If they can reject bad software or even stop a delivery, you will see that unit tests will be more popular among development teams, defect turnaround time will drastically reduce, and developers will become more agile and responsive.
Since better software requires not only better development but also better analysis, better design, and better testing, this rejection power smoothly increases the competition between project members (testers, developers, and business analysts), and you will even observe improvements in analysis documents and design artifacts.
The bottom line is that quality will definitely improve. Worth a try, isn’t it?
