Category: testing

Not returnable by design

I was working in a factory on the returns line. I took an item out of its box and started running tests. Afterwards I tried putting it back in the box with no luck. People started laughing at me. One individual said I wasn’t doing it right.

It turns out that you need a special tool to get it back in the box. It compresses it just right so it will fit. I’m told it’s to maximise space and reduce packaging costs. I think it is to reduce returns.

Think about it. To return it you have to send it back in its original packaging. If you can’t get it back in the box how do you return it?

Not returnable by design. That’s my thinking anyway.

The art of exploratory testing

As a tester you learn various formal processes in your approach to testing. Component, System, Integration, Interface, and distributed testing techniques both positive and negative paths. You learn the V-model and agile, test strategies, and iterative testing. But all of it is structured with a well-defined path and focus. Usually there is very little fun in the actual testing. It’s all regimented and strict with little deviation from the frameworks and methodologies in play. Rarely do you get a chance to just play.

During one contract I was having a conversation with the programme manager and he said that testing had 100% coverage and there were hardly any bugs left.

“Oh” I said. “How about a challenge?”.
“Like what?” was his reply.
“How about I take the weekend to do nothing more than unscripted exploratory testing? I won’t follow any test scripts. I’ll just play with the software.”

He intimated that that won’t work and I wouldn’t find any bugs without proper structure and method to my testing. I’ll be using decades of experience I said.

So confident was he that I suggested that for every high severity bug I found I was paid one hundred pounds. For every medium, fifty pounds, and low only ten pounds. He thought about this and finally said no as my reputation proceeded me and he figured this bet may prove expensive.

What I had suggested actually exists today but mainly for the finding of security bugs and is known as Bug Bounty programmes.

The art of exploratory testing is becoming a lost art in the QA field. I highly recommend that every IT project under test introduces exploratory testing. Not only will it most likely uncover bugs that you didn’t know were there, it will do wonders for your test team’s morale as it will allow them to have some fun and to just play with the software unscripted, allowing them to use their skills and experience to find bugs quickly. It may also help identify paths that are not covered by existing tests. It’s also useful to do this at the start to identify test cases needed.

Give it a try. Allow your testers to explore!