Some years ago, there was a popular notion that testers should be put into “black teams”. Black teams were a popular idea in the late 1960s and early 1970s. If a successful test is one that locates a fault, the thinking went, then the testers should celebrate finding faults, cheering even. Would you think this was a good idea if you were surrounded by developers? Of course not.
There was an experiment some years ago in IBM. They set up a test team, who they called the ‘black team’ because these guys were just fiends. Their sole aim was to break software. Whatever was given to them to test, they were going to find faults in it. They developed a whole mentality where they were the ‘bad guys’.
They dressed in black, with black, Stetson hats and long false moustaches all for fun. They really were the bad guys, just like the movies. They were very effective at finding faults in everyone’s work products, and had great fun, but they upset everyone whose project they were involved in. They were most effective, but eventually were disbanded.
Technically, it worked fine, but from the point of view of the organisation, it was counterproductive. The idea of a “black team” is cute, but keep it to yourself: it doesn’t help anyone if you crow when you find a fault in a programmer’s code. You wouldn’t be happy if one of your colleagues tells you, your product is poor and laughs about it. It’s just not funny. The point to be made about all this is that the tester’s mindset is critical.
Testers must have a split personality
Testers need a split personality in a way. Perhaps you need to be more ‘mature’ than the developers. You have to be able to see a fault from both points of view.
Pedantic, sceptical, nit-picking to software
Some years ago, we were asked to put a slide together, saying who makes the best testers, and we thought and thought, but eventually, all we could think of was, they’ve got to be pedantic and sceptical and a nitpicker. Now, if you called someone a pedant, a sceptic, and a nitpicker, they’d probably take an instant dislike to you. Most folk would regard such a description as abusive because these are personal attributes that we don’t particularly like in other people, do we? These are the attributes that we should wear, as a tester, when testing the product. When discussing failures with developers however, we must be much more diplomatic. We must trust the developers, but we doubt the product.
Most developers are great people and do their best, and we have to get on with them – we’re part of the same team, but when it comes to the product, we distrust and doubt it. But we don’t say this to their faces. We doubt the quality of everything until we’ve tested it. Nothing works, whatever “works” means, until we’ve tested it.
Impartial, advisory, constructive to developers:
But we are impartial, advisory and constructive to developers. We are not against them, we are on the same team. We have to work with them, not against them. Because it is human nature to take a pride in their work and take criticism of their work personally, bear in mind this quote: ‘tread lightly, because you tread on their dreams’.
If development slips and they are late, you can be assured that they’ve been put under a lot of pressure to deliver on time and that they’re working very long hours, and working very hard. Whether they’re being effective is another question, but they’ve been working hard to deliver something to you on time to test. So, when you find the bug, you don’t go up to them and say, this is a lot of rubbish – they are not going to be pleased. They are very emotionally attached to their own work, as we all are with our own work, our own creation. You have to be very careful about how you communicate problems with them. Be impartial; it is the product that is poor, not the person. You want to advise them – here are the holes in the road, we don’t want you guys to fall into. And be constructive – this is how we can get out of this hole. Diplomatic but firm. No, it’s not a feature, it’s a bug.
The other thing is, if the developer blames you for the bug being there – you know, you didn’t put the bug in there, did you? Sometimes developers think that the bug wouldn’t be there if you didn’t test it. You know that psychology, ‘it wasn’t there until you tested it’. You have to strike quite a delicate balance: you’ve got to be able to play both sides of the game. In some ways, it’s like having to deal with a child. I don’t mean that developers are children, but you may be dealing blows to their emotions, so you have to be careful.
best author name for manual testing.