, ,

Metaphor: I have found testing to often resemble the invasion of a city. Imagine the product to be a walled city. There’s tons of walls. Outer walls, inner walls, walls surrounding certain parts of the city and so on. Now imagine the test team to be an army of angry Vikings. In order to plunder the city properly you need to break through these walls before you send in the troops. Otherwise they’ll get run over and troops will fall by the hundreds.

Thank god we have sappers. This one person is specialized in breaking down these walls efficiently.

You send her in far earlier than the common brutes who’ll then have a better chance to find a  treasure to plunder and wenches to take back home.

What it tries to explain: This one sapper is the true tester. She’s able to discover the blocking issues , which are portrayed by walls, fast and efficiently. She’ll do this without spending too much time and money. She might encounter tons of other bugs that aren’t as important, but will ignore them.

The goal for this tester is to make the product testable. Clear out all blocking issues in order to make all functionality available.

Only then is it a good moment to send in either the less experienced testers or User Acceptance Testers.

Lesson: Don’t burn your resources to early on a product that hasn’t been properly looked at first. Have one experienced tester feel out the water before testing further. Especially with non-tester testers, who are easily demotivated by a product that doesn’t meet (high) expectations (yet).