Tuesday, November 22, 2011

How Not to Test


For the past 3-4 months I have been bombarded with new functionalities to test. I have been asked to create test cases, write test scripts and also execute them. My focus is on the test execution part. Writing Test cases and test scripts deserve independent space.

Test execution is the process of the following test scripts. Yikes, doesn’t sound interesting and also not cool. Following steps, seriously? Why on earth would I want to follow the scripts I wrote? I’m better off without them or in fact any tester is better off without scripts. That‘s why I didn’t do it. Testing is an intriguing process and should be left so.

I was very excited for the build to arrive and start off with the testing. Finally it arrived and the next thing that happened was a pure learning experience for me as a tester. 

I got over excited and started to test everything and I mean everything, in the first couple of days.

I was testing everything but it was all ad hoc. It was like starting from Z, going to E, back to Z, then to A and so on. There was no sequence. This did not mean that I was not finding bugs, I was. Then where was the problem? The problem came when I scrutinized the bugs that were raised. The bugs were found while executing complex scenarios. There was not a single use case or test case of low complexity that had been tested. This is not right. This is not how you should approach early testing.

A tester needs to first understand the system that he/she is going to test. Do a tour of the functionality, get to understand what the developers are trying to achieve and what the stakeholders actually desire. 

Keeping this in mind, I've started created mind maps. These mind mapping tools help you to organise your thought aka map the understanding that is going on in your brain.

Once you’ve created mind maps, the next thing would be analyse the mind maps and then design your tests. Not only this would help in better understanding of the functionality but will also help you in better analysis and consequently better tests. (Read Cem Kaner's slide on Function Testing in BBST Course.)

To conclude, don’t be over excited when testing. Use the excitement constructively and then test.


PS: Over-excitement is one of the ways of not approaching to testing. There are plenty of others which I will definitely post once I experience them.

No comments:

Post a Comment