How can a Software Tester use "Out of the Box" thinking approach to find more bugs?
Well, I am a black-box tester and I don't think out of the box. I just think about happy paths, thus I want to improve. I always read that testers should have great critical, analytical skills and should think out of the box. Well, what could be some real-life examples/scenario's where one could use this way of thinking? For instance I am testing a web based EIS application.
Thanks In Advance!!
Some suggestions in addition to the good ones already listed:
- Look for things the software shouldn't do. Make it do them.
- It's web-based, so what happens if it loses the network/internet partway through a multiple-screen operation?
- Look for words in the specifications/user stories like "should", "always", "never", and so forth. These indicate conditions involving rules. Now look at what happens at the edges of those rules. What happens just inside a limit? Exactly on the limit? Just outside it?
- With something like an EIS, you're dealing with a lot of complex variants that combine in rules. Set up the most absurd combinations of the rules you can think of, the things you doubt anyone would actually do. What happens?
- Play with personas. Pretend you're the CEO of Santa Claus, Inc. and you want to know whether to get extra chimney breakage insurance this year. Or pretend to be a disgruntled accountant wanting to sabotage the CFO's financial forecasting for some reason. Or pretend to be the CEO's 5 year old daughter who wants to see the pretty flashy things show up on the screen because Daddy forgot to log off. And so on...
- Be destructive. Kill the system mid-transaction. What happens? (I'm actually serious here. At one place I worked, we had to reconstruct data and clean out corrupted data because the client's users would simply kill a process intended to run permanently when they wanted to use that machine for something else.
- Learn Murphy's Laws of software. Then use them for good.
- Paste the entire text of Hamlet into memo fields and save. (Hat tip to QA Hates You for this one)
- Actually, read all of QA Hates You's dirty tricks, clean tricks and other posts. He has some lovely suggestions for devious testers to work with.
- If the system lets you do something, do it, whether you should do it or not.
- That includes running really massive data crawls.
- And SQL injection.
You should find with a bit of practice looking for the gaps in assumptions (including yours) becomes easier.