“WHAT?!?!? How can you test something if you don’t know what it is you’re testing?” is probably what’s running through your mind right now. Now, I’m not saying completely ignore the specs. I can’t argue for never reading the specs. That would be irresponsible and result in very poor quality assurance.
What I’m suggesting is when you are handed a new feature or software component, start by hacking around semi-blindly (“semi-” because you have at least an idea of what you’re looking at). I affectionately call this “idiot testing”. By acting like a first-time or uneducated user of a system, I’m more likely to come across errors not found on the system’s “happy path”, often turning up more “page not found” or “an error has occurred” messages.
Hacking around outside of the spec is an effective use of time. By not reading the specs beforehand, I’m attacking the system with a view that isn’t biased by the specs. The specs may call for a screen to be laid out a certain way, but it might make more sense from the user’s perspective to lay it out a different way. If I read the spec first, I’d be expecting the screen to behave in a pre-determined manner and could have missed an opportunity to change the screen so it would work better for the end user.
At my former company (an accounting and inventory system developer), when new QA resources (and even developers) were brought on, rather than giving them any specs or documentation, they were told to hack around the system and ask questions as they went through it. This had two main advantages. One, it was an effective way to get the new hire trained on the system and become familiar with the business areas it covered; and two, we had a fresh, unbiased set of eyes looking at the system, mimicking what a novice user on the system would do. This approach would cue us to where we could improve the system’s usability. It also turned up bugs seasoned QA people might miss because they are biased; they know how the system is supposed to work and test accordingly, thus failing to test how the system reacts to steps taken outside of the prescribed spec.
My general approach to testing is as follows:
- Get a high level understanding of what I’ll be testing, not worrying about implementation details.
- Hack around the system/system feature/component I’ll be testing. Ask questions to the powers-that-be about what I see regarding design, system flow, or anything else.
- Read the spec.
- Test to the spec.