How to prevent cheating by manual testers?
irl last edited by user
I'm the guy who is motivated to bring some quality assurance into our team. The problem is, that our developers very often hate testing and even if they have a test protocol, not all of them are really testing. Very often they are asking their colleagues instead of testing themselves where the bugs were and practices like this. They are very often not very interested to do a good job.
This is of course a general problem and they could got fired for such an attitude. But in reality things aren't as simple as this.
My question now is if there are clever tactics which prevent them from cheating. I would let some random errors occur for each tester to prevent it, but as they are the developers it's nearly impossible to prevent searching the source code for these errors. Another idea would be to offer a reward for the person who found the most bugs. Or don't let multiple people test the same things (but this reduces the quality of the tests).
What are your clever suggestions to "force" the developers to really test and give them no possibility to cheat? Funny tactics are of course welcome too...
In my situation the application is written in PHP and the developers are the testers too (same persons).
As user246 says, tricks to force developers to test can always be gamed: you're much better off finding out why they don't like testing and what the actual problem is then building a culture of testing and quality from that.
You're working in PHP - there are unit test frameworks available for PHP that your devs can use. If they have no idea how much trouble testing can save them, that's where you get to evangelize. I'd suggest for starters working up a smallish project with some unit tests, and then refactoring it - use it as a demonstration of how well-designed unit testing can help save work: if you know you'll find any change that breaks existing features the moment you compile, you also know you can safely refactor and extend your system.
Some other things that can help:
- When they gripe about something not working, or talk about games they play (there's almost for certain at least one gamer in the team), see if you can feel out the way they respond to bugs in software they use.
- Google "Maybe they should have tested more". I guarantee you, your developers do NOT want to find their application on that blog!
- Be tactful. If you're obnoxious about it, you'll get resistance and sabotage. That's just human nature - people don't like feeling that someone is railroading them somewhere they don't want to go.
- Make sure that you're creating unit tests and testing your work. If you're modeling the things you want the rest of your team to do, that's always a good start. From that, you can drop the occasional seed comment in, such as mentioning offhand how that last enhancement was so easy because you had all those tests to tell you as soon as you broke something (don't overdo it - mention it once then leave it for a while: let them come to you).
In general, you'll have a much better chance of building a culture of quality if your team wants to build it and thinks it's their idea. In the meantime, try not to get too frustrated: your team most likely sees "testing" as something any trained monkey can do and something that takes away from their main purpose.