In the world of software, quality assurance testing is often regarded as an addendum to the entire development process. As testers, we’re frequently viewed as the busboys who come through and clear the left-over scraps of whatever delicious meals came from the gourmet chefs in the kitchen.
This is not a knock on busboys. No restaurant could survive for long without their help. In many ways, cleanliness and service quality are as important to repeat business as the actual food itself.
But software testers differ from busboys in two important ways:
- First, software quality testing is a career in and of itself. It isn’t a pit stop on the way to becoming professional software developer. One trains and studies with the express purpose of becoming a software tester.
- Second, busboys represent a tiny fraction of a restaurant’s budget. Contrast this with software development in which nearly 80% of the total cost goes into detecting and fixing bugs.
As a result of this misguided inequality, programmers usually receive the latest tools and equipment, and we’re stuck trying to buy the best tools for software testing with whatever money is left over.
It’s a situation that actually leaves everyone worse off – including the developers who invest more time and resources than they have to by creating easily preventable defects.
How to Elevate Software Testers and the Tools They Use?
So how do we fix this misconception? How do we elevate software testing to its rightful place in the development hierarchy – a place of equal footing with the programmers who design the original code?
Well, part of it will eventually sort itself out.
Budgets are becoming tighter all over, and software companies are paying increasingly close attention to where their money is going. As the cost of defective software becomes harder to ignore, companies will naturally place greater emphasis on recruiting and training professional software testers.
I also imagine that software QA testing tools will receive greater attention as well. Right now, most budgets are geared towards development tools and advanced coding environments. But because mistakes are costly, both in terms of man-hours and loss of public trust, I’ve already noticed many companies investing more heavily in quality tools for software testing – a trend I described as a “business decision” in an earlier post.
Change from Within – We Must Also Elevate Software Testing Ourselves
While outside influences (like the market) will naturally help turn the tide, part of the transition also depends on us as software testers.
As already mentioned, testing is not a stepping stone to greater things. It is a profession that demands to be treated as such – not just by the outside world but also by us as well.
This requires our staying abreast of recent coding practices, testing techniques, and new methodologies. Our industry never stops evolving, and our training and attitudes should reflect this (see my earlier post on this very topic).
But personal growth is not sufficient – at least not by itself.
As testers, we should become more proactive in team environments and deliberately reach out to our fellow developers. Effective software development is a process – a conversation in which needs, requirements, ideas, and even criticisms must flow back and forth, unimpeded.
At Testuff, we don’t believe it’s enough to say, “I caught a bug” or “this doesn’t work.”
For optimal effectiveness, we need to understand the nature of the bugs we discover and how best to resolve them. Equally important, we should insert ourselves into each project at its inception. Just imagine how much faster (and less costly) the average project becomes when testers are involved at the actual design phase instead of much later in the process.
Software Testing as a Cooperative Effort Requiring Team-based Tools
Not to beat a dead horse, but I would like to revisit the restaurant analogy once again.
Many top establishments around the world have policies that require chefs spend at least a few days working as busboys and then waiters before assuming their permanent positions in the kitchen. As a result, they have a much deeper appreciation of everything that is involved. The benefit of this is that the “chain of command” becomes a “chain of cooperation”. There are no bosses – just fellow team members.
Imagine if testers and developers switched roles every now and then. I recommend this more as an exercise than an actual approach to software development, but the results would be extraordinary. Both sides would cultivate a greater appreciation of everything that goes into the software development process.
Lastly, I’d like to see a shift away from traditional corporate structures in which you have distinct testing departments and distinct development departments who coordinate at a very surface level. Regardless of which coding technologies and software QA testing tools you use, close-knit teams consistently produce better software than silos do.
And so for every project, you would have a tester and developer working together – preferably in the same room at the same time.
If we, as a community, could help implement some of these improvements, I’m confident that perspectives would change dramatically. We’d have better access to software QA testing tools to help us get the job done. And we’d enjoy our rightful place in the broader software development cycle.
Agree? Disagree? Share your thoughts down below.