I often work with good developers and one thing I notice about all good developers is that they seem to love the idea of building robots.
Bad developers see problems and sit there waiting for someone to come up with a solution in enough detail for the developer to transcribe the solution into code, much like an old fashioned typist takes dictation and types it onto a page.
So if a bad developer noticed that their house needed cleaning, then he or she would simply complain that someone should clean it. Then if you point out that it is their house that needs cleaning then they will either claim management won’t let them clean or that the problem is more complex than it seems cannot be solved.
In fact even if you ask them to try and clean, they will just start to reveal that cleaning is “more than vacuuming” and could involve the removal of micro-particles that only quantum physicists could possible manipulate. Indeed, they will contend, it is unlikely that anyone really cleans their house and the only practical solution would be to upgrade to a new cleaner house.
But good developers are different. A good developer will notice that the house needs cleaning, work out that actually cleaning it less fun than designing a better way to clean houses and immediately begin working on the design for a new robot.
In fact, rather than cleaning the house for an hour, most good developers would prefer to spend a whole day building a robot that could clean the house for them.
Of course, the robot might occasionally turn evil and attack the developer as happens in every science fiction movie; but even this is seen as being preferable to cleaning the house manually.
So a similar thing happens when it comes to testing. Bad developers seem to think that testing is optional, or at best a good idea in a utopian world, but simply impossible with our existing systems.
Good developers suggest that we hire a cleaner to come in once a week (er – a tester I mean). But that means that our house gets dirtier during the week and is only ever clean for a short time. It also turns out to cost money to hire both testers and cleaners and it turns out that if they are not good at their job then they don’t help us to clean things up at all.
So it is no surprise that when I asked my developers to do some regression testing recently, they immediately recommended hiring a regression testing specialist. When my budget ran too low, they immediately started to build robots to do the testing for them.
But the robots turned out to need maintenance and development and sadly even testing – they were developing their own bugs. So now we face the challenge – should we build a new robot to test our existing testing robot?
Now it seems we face an infinite loop, with ever increasing armies of robots being built to test and protect us from the robots we have already built.
Or, maybe we can do some manual regression testing.
Manual regression testing involves somebody sitting down and testing that what we built yesterday still works, even though we added some new stuff today.
Because regression testing is boring, we would like to defer it to the end of the project, but because our system gets dirty one day at a time it seems better to test it every day.
But without robots and nanotechnology we cannot test everything every day and even with robots, they only test the same obvious stuff every day.
This is what you would call a problem that sucks:
So I decided to as a tester – What is it about testers that makes them enjoy doing long hours or boring, sucky work?
The answer might surprise you – the tester I spoke to actually hates doing long hours of sucky boring work. He even hired a cleaner to clean his house because he could not afford a robot with nontechnology. Also he noted, he would not trust a robot that was built by developers because he was sure it would eventually turn evil and try to exterminate humanity.
So I asked him a new question – how can manual regression testing be anything but sucky work?
“Build some robots,” he responded, “Automated testing is much better than manual testing for fun value, even though manual testing often reveals more important problems.”
“But how can a human out-test a robot?” I asked, “ and why do you do manual testing if it sucks.”
“Repetitive testing sucks and robots are better at stuff that sucks. But manual testing is really problem solving not just typing test scripts,” He responded.
My immediate thought was that if I could fool the developers into thinking that testing was fun then I might be onto something … but they are probably too smart for that.
So the bigger challenge is to try to find ways that testing is actually about problem solving while keeping the repetitive stuff to a minimum. Unfortunately that sounds like the opposite of regression testing doesn’t it?
So – how can regression testing be valuable work that people don’t hate doing – rather than low value work we defer indefinitely? (Besides through building robots).