Why not to create Test Documentation

Before you read further, I would like you to do a small exercise. For each product/release that you have tested, calculate an approximate number for,

1. Total no of Test documents you have written till date.
2. Total no of test cases you've written.
3. If it takes 5 minutes to write one test case along with the scripts, then total time consumed?
4. Last time the scripts were updated

Once you are over the excitement of the numbers that you see in front of yourself and for those who could imagine how large the number would be and didn’t bother to calculate, answer yourself, what usually happens when the product/feature is released?

Usually, important/happy cases are documented in the regression pack, which is usually automated in many cases. From then onwards, the feature test documentation is not used anymore. Then why do we spend so much time on it? Let me try to answer this.

• The most obvious reason is that the management has asked us to do so because the piece of documentation is getting the company money or “billing the client”. We all like to earn money but is that the end goal?
• We might be writing it because this is what testers have been doing for past so many years. The problem with this is that no one questions what they’re doing and gladly accept what they have been taught by their seniors.

What do we usually achieve when we try to follow the above process?

1. Missed Deadlines because we were so busy writing test scripts and getting them reviewed from the customer that we forgot to test the product
2. Heated discussion with the developers regarding why they did not mention it in the FSD in the first place?
3. A Buggy product
4. An unhappy end user and customer

If the above points doesn’t seem so convincing to you, then ask yourself, “Do I like to write test documentation?” If your answer is still Yes, then I hope god is with the product that you have tested. 

What could you do instead of wasting time in test documentation?

• Take time in understanding the requirements. Create a mind map.
• Have a question & answer round with the requirements analyst.
• Have a debate with the Developers
• Test to explore the product. Yes, I clearly meant to say, practice exploratory testing.

I don’t have a goal to change the world, but if you are passionate about testing and want to test the product instead of wasting your time in writing how to test the product, then do think about it.

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.

First WT Experience-WT 01

I had my first Weekend Testing Session today. For those of you who don't know what Weekend Testing is, go to http://weekendtesting.com.

I've always wanted to participate and when I did get an opportunity I didn't let go of it. When WT69 was announced, I mailed for the participation right away. There were still 2 days left for the session and I was so much excited that I even set a reminder on my mobile phone. Sounds crazy, but didn't want to miss out on it.


At 15:45, Skype informed me that Weekend Testing has added me as a contact. :) Ajay briefed all of the testers with the mission.

Mission

Today's session is about Time Zone Conversion

http://www.timezoneconverter.com/cgi-bin/tzc.tzc

http://wwp.greenwichmeantime.com/gmt-converter/index.htm

Compare and contrast these two time zone converters.

1. How useful is each link to the user, tester?

2. What are the advantages/disadvantages in each of the converters?

3. If you had to design only ten tests for each of the converters, what would they be?

Experience

This was first my weekend testing session and it was a great experience. Even though the constant pinging on Skype didn’t help, I managed to keep my focus on the testing and not get disturbed. When I first analysed the mission I thought that one hour will not enough for this mission, that’s why I wasn’t able to complete the mission, not because the time wasn’t enough but because I had made my brain convinced that time wasn't enough. 

After analysing the mission I thought of deciding on a approach which actually helped me in time management.  

Approach

• Divided the time for each converter
• 15 mins for Time Zone
• 15 mins for GMT
• 10 mins to compare & contrast
• 15 mins to design tests

Throughout the session, there was some sort of a 'rush' that was going through me, as if I had something to complete or to achieve. Not able to figure out what & why. 

Learning

• Wasted the initial 15 mins by getting excited and not focusing on the mission.
• Didn’t analyse the mission properly because once the session was about to complete I couldn’t answer the first question. Should have analysed and asked questions at the beginning of the session itself.
• Didn't have a proper format to write the report, so just wrote in any format , not tidy. 

The one thing which I believed that I did right was keep the mission in mind. I didn't go out and play with the testable.

I am definitely going to be looking forward for the upcoming sessions.