The other day I was talking to a few developers I was on an assignment with about getting testers added to their scrum team, and the response I got from them disturbed me. They told me that in their experience most testers do not work together in the team, they work against development, trying to get everything fully tested, despite them knowing this is not a feasible thing, and with that delay projects. On top of that they told me, most of the testers they have worked with, are part of the dumping grounds of the IT industry. And with that they meant that in their view most testers are not good enough to be a developer, so they decided to become testers instead (<sarcasm> cause, come on, testing is not that difficult anyone can do that! <\sarcasm>).
I was shocked to hear there are still a lot of developers out there who believe that testers are the dumping grounds of the IT industry, but I was even more shocked of their experiences with testers, working in an “us versus them” modus operandi instead of working in a team, part of a joing effort with a shared focus and goal.
What is it that still makes testers often work against developers instead of with them?
Most testers I have worked with over the past years agree that working side by side with development is the most effective and efficient way of working, this way you both keep track of your joint goal: get the software out on time, on budget and according to what your customer (or end-user for that matter) wants and needs. Together you try to add value to the software.
So is it indeed true that there are still a lot of testers out there in the field who are indeed not seeing the big picture and are trying to prove their worth by working against dev and looking for bugs that are not relevant, e.g. just looking for bugs for the sake of finding one, no matter what the value of that bug is to the end-user/customer, just so they can triumphantly point to a developer that indeed, “see! There are bugs in your code, you did it wrong!” Unfortunately I fear there are still too many testers out there that think and work this way, not to even mention all the developers out there that seem to not understand the added value of a good tester to the team and to the developers work!
Fortunately there is a wonderful contrast out there as well, in the form of this blog post by Nathan Lusher who shows that there indeed are good testers out there, who weigh in on a project and prove the value of testing and with that show that testers are not (or at least not everywhere) the dumping grounds of IT.
In my experience, there are a lot of very good, inspired and knowledgable testers out there, who see the added value of working together, in a team with a shared goal, a shared approach and shared respect. If testers want to get the respect of developers, I believe it is up to quite a lot of the testers to start by showing respect to the developers and where needed, increasing their technical knowledge in order to be able to counterbalance a developers viewpoint. You get what you give!
7 thoughts on “Is testing the dumping grounds of IT?”
Leave a Reply
This site uses Akismet to reduce spam. Learn how your comment data is processed.
Technical Software Testing 
Q: Is testing the dumping grounds of IT?
A: Not if you are doing it right.
I know that when doing it right testing is definitely not a dumping ground, but then how come so many (young) developers still have the feeling that it is? And more importantly, how come quite often it still is true? What is it that makes some people get away with being in testing and indeed being the dumping ground of IT?
Well… some part people getting away with it, is that managers do not look any further if you have a certification. The certificate itself most of the time doesn’t say anything other than “I attended a course and passed the theoretical exam”. We don’t let people drive with only a theoretical exam too, so why does it get accepted for testing. Sure, you need to start somewhere, but at some point you need to start proving yourself as a tester. In my opinion there is too little evaluation of how people are performing in organisations.
And since too many so called “testers” get away with their underperforming, the developers will have the idea that all testers are like that.
To be fair, a lot of the time it seems the testers driven by finding bugs, by raising the bug count regardless of the value of the bug, are doing so because it has been made clear to them by management that finding bugs is their job.
I worked with an external team of testers that fought each other daily to file bugs because they feared that a day without bugs filed was going to be viewed as a bad day, or non-productive day by management. We kept telling them that was not the case, at least from our side, but their own management on the team kept insisting that if they didn’t find at least 3 bugs a day, they were not doing their job. So, we would see bugs like ‘Shading box around item x is two pixels short of complete shade’ where they nitpick over two pixels while missing an obvious bug in the code on the page, since visual bugs were easier to find than actual code bugs.
The problem doesn’t always start with the testers.
Indeed, the problem quite often starts with management, either by mgt giving the wrong instructions or by mgt hiring the wrong people.
Problem is that in the end the testers still are perceived in the wrong way. Whether it is due to their own mistaken behavior or due to management giving wrong instructions I cannot say. Both are equally possible I’d say.