Outside box

Raising Outside the Box Approach in Your Manual Testing Sessions

I met my friend yesterday, a lovely youngster with a sparkle in his eyes about software testing. We don’t know each other for quite a long time but we got several niece chances of working together and got to know each other. So there was this one day when Simon, that’s right, his name was Simon, came to me with a question.

 How do you always think outside your box? This is a real challenge to me hence my incapability of thinking in that manner makes me a terrible tester (which was false, hence Simon was a good tester with a lot of potential).

I have to tell you the truth. I just had no clear answer at that point. I’m no wise wizard with ages of experience and deep knowledge of every aspect of the universe. But the question made me thinking: may a mindset be taught? Can somebody learn outside box thinking?

After a while I figured out that the correct answers to the above questions are yes and yes. Here is how I helped Simon and hopefully will help some of you guys.

The course of action

The answer hit me when I accidentally did not choose the proper amount of sugar that was supposed to sink down my coffee (three lumps) when heaving breakfast on the go near a coffee machine. The drink I had was hot, black and all seemed fine. But the taste was awkward. Then I thought: if you are repeating something often enough it becomes a habit. So repeating the following might just do the trick for you and the outside box concept will root deep into your subconscious.

  • Find out what the software under test should not be doing. Try those things out.
  • The ‘what if’ should become the leading question of your research. So you are finding yourself in the middle of web application testing. How will it act if internet shuts down while some operation is in progress, etc.?
  • Go through user stories, requirements and specifications and look out everything that has a word ‘must’, ‘has’ or ‘should’. Concentrate on those parts and try to make the app fail in these spots. Test such requirements to the limit.
  • Try out SQL injections because: why not?
  • If you can do anything in the system (meaning it allows you to) do so without question and despite everything telling you shan’t do just that. Especially if large pieces of data are involved.
  • Destroy as much as possible. Don’t play nice with a new feature. Users won’t! What happens if the system is killed in the middle of the transaction? You would never guess nor know if you won’t try.
  • Personas are doing magic.
  • Try out all possible combinations of pre-determined rules (this one goes to EIS mostly). Start with the most insane ones.
  • Start being creative at everything you do. When you are getting out of bed do it in an interesting and unordinary manner. Try achieving your ordinary goals with untraditional methods. And so on and so forth through out entire weeks until you get a hang of it.

Tagged:


TestFort Blog

About TestFort Blog

TestFort blog is an official blog of TestFort QA Lab company and is dedicated to various QA and software testing issues.


no comments yet

Be the first to comment this post!

Would you like to share your thoughts?

Software testing & QA blog by TestFort © 2017

×