So - how to describe software testing... I don't mean the blind execution of pre-existing testcases, I mean the testing most of us do... Here's a piece of software, go figure out what "works" and what doesn't...
Sometimes you have requirements (probably a discussion for a different post), but more often than not you don't, so how do you test something, when you don't know what it's supposed to do?
To me, testing without requirements can be described like finding a lost puppy.
You are out for a walk and you find a puppy (you are using the software and stumble across an undocumented feature - sound familiar?).
You check the puppy for a collar, dog tags, tattoo (requirements, User stories, Use cases) and find nothing.
You look for lost pet signs, go online for lost pets in your area, call the humane society (check your issue tracking system).
All you have is a lost pet and no easy way to uncover it's owner.
Time to go on the offensive! You ask your neighbors if they know who owns the puppy (check with developers to find information about why it was developed). You post found pet signs in the neighborhood and online - you describe the colour and size of the puppy and hope!
You get a phone call - asking you the puppy's breed, gender, age, name - all things you cannot answer. This puppy didn't come with a spec sheet.
And people come and call "Here spot!" to see if the puppy will answer.
And someone comes and says - yes, this IS their puppy. How do you know? It's like asking your product owner if the feature is exactly what they wanted. It might not be exactly what they were expecting when they started out, but they are willing to take it home and nurture it into a full size dog :)
