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.

Tester Vs Developer – Is this the worst it could get?

We all know the kind of relationship the tester and the developer share. It’s not good, there is bitterness involved from both sides.

Take a look at the below conversation which happened between the developer and a tester after the tester raised an invalid defect in the developer's module.

<Start>

Developer: You raised a defect?

Tester: Which one are you talking about?

Dev: The one you found in my module. Defect ID: xxxxxxx

Tester: Oh yeahh...What about it??

Dev: Can you repro this on your kit once again and show me where the error is coming??

The tester, with a big smile on his face, shows the developer the error.

Dev: This is an invalid defect. You are missing out on some pre-requisites.

Tester: Well, there is no Help Me or Readme file here, which suggests any kind of pre-requisites or is there?

Dev:  No , there isn't but the users are aware. Go and read the release notes.

Tester: The release notes are not for me to read, it's for the customer, isn't it?? If you have any problems with this defect, then please mention it in the defect management tool.

Dev: Why would I, it's not assigned to me !!!

Tester: OK, no probs.

Dev: And please get a understanding of this functionality and processes. You don't know how to test !!

The last statement really got me boiled. I really wanted to kick him !!!!

Tester: If you have so much problems with my understanding, then give me a KT regarding this, I'll ask your manager to arrange it.

Dev: Who am I to give you a KT !!!

<End>

Now, when this conversation was happening , the Dev Manager was there and listening to each and every thing but he didn't bother to stop the developer and instead told me that he is kinda moody. Apart from the Developer questioning my integrity, this was another sad moment of that day. I don't know if this is the worst that I have faced head on with the developer or is there more to come but I really hope no other tester faces such kind of situations.

There is a very thin line between the tester and the developer which should never be crossed.  A good tester should never think that a bug is a developer’s lack of skill or lack of “anything”.  A good developer should never think that the tester is raising defects on purpose(well, that’s only an assumption :P).

It only means that the tester and developer have different understanding. A valid defect means the developer had a different understanding while coding it and an invalid defect means the same for the tester while testing.

The “fight” starts when people start taking these things personally. Why do they take it personally??? It's not your pet project, you're just working for a company which pays you a 0.'x' % of their revenue. 

Now let me ask you one question. If you are married and have a kid, if somebody points out a mistake in your kid, that his forehead is too big, then you'd obviously want to rip that person's head off. The same is the case with the developers. Developers think of their written code as their baby, well some of them do.

Lessons Learnt that day:

1. Test twice and discuss with the peer tester before raising defects i.e if you are not sure about it.
2. Don't get too much involved with the developer. 

Gmail Filters are buggy !!!

I have a habit of testing open source software's in my free time because there's a saying 'Practice makes a man perfect'. So, I download software's from the internet and simply test them whenever I am free. I do this to improve my testing skills, get new test ideas and simply because I enjoy breaking software's much more than I love to create them !!!

So, this weekend, I downloaded a couple of software's to test but ended up not testing them. Instead, I gave myself a challenge to test the most popular free email service provider, Gmail. Gmail is too big to explore in a couple of hours, so I narrowed down to a feature of Gmail which I hardly use, 'Filters'. I didn't expect myself to find many bugs but I did found one lurking around which should have been identified by "Test Cases"...hehehe.....


So Here's the bug report and for the developer's, the Story Writing:

One day, a user subscribes to very popular testing magazines, testing forums and clubs. Subscribing meant that he'll receive loads of mails from them. So he wanted all of those mails to be placed under one location and not be mixed with rest of the mail in his inbox.
So he logged into the Gmail Account and on the top of the page, he saw a link named 'Create a Filter'. This made sense to the user that he should create filters for his testing mails.

He clicks on the link to create the filter, and is redirected to the following page.

The user populates the 'From' field with 'Testing', so that any mail that contains the word 'Testing' will be included in this filter. He didn't require any other fields, so he clicked on the 'Next Step' button, and the following page appears.

Out of all the options available, he decides to apply a label to all of these mails by checking the checkbox 'Apply the Label'. However, he has to create a new label and therefore chooses the option New Label.

He enters the name of the new label as 'Testing' and clicks on the 'Create' button.
















A small blue text appears and states that the new label has been created. :D
















Excitedly, he goes to the 'Create Filters' grid at the top of the screen and clicks on the Drop Down List but to his shock, the 'testing' label is not there !! :(

What ??? How can this happen....Where's it gone, I just created it !! Gmail just prompted that the new label has been created, then why the hell it doesn't show it !!!!
The user thinks that maybe it has been created and has been selected by default. Gmail wouldn't mislead their users or would it, hmm??


Anyhow, the user decides to go forward with creating the filter and clicks on the 'Create a Filter' button.
















Ahhhhhhhhhhhhhhhh !!!!!!!!!!!!! WTF !!!!

It's asking me to choose a label, but it wouldn't let me choose the label which I just created. God, Gmail should do keep their tester's tight !!!!

Through this example, there are two points on which I want to lay emphasis on:

1. Bug Reports: A tester is or rather should not be judged by the number of defects that he has raised but the manner in which he has reported them to the developers. How much does the bug report helps the developer understand the problem not just from the logic point of view but from the user point of view.
2. No Software is defect Free. Whether it's the Microsoft Vista or Gmail or any other popular software, each one of them has defects. They might not be of high severity but a bug is a bug. So do not hesitate in testing software's because they are popular and assuming that they'll not contain any defects.

Happy Testing !!!


PS: If you actually do come across this bug, the workaround for this to click on the 'Back' button and then on 'Create a Filter', the label created will appear.

Tester should have access to the code

Many developers and even testers believe that testers should not be able to look at the code. They have a belief that the tester might identify defects just by looking at the code. I very much agree with this. If I am not able to find defects during the system testing then people might get a perception that I am not a "good" tester or I am not dedicated to my job and I would certainly not want this perception about me. But this is not my point when I say that tester should have access to the code.

Both the tester and developer have one thing in common i.e. the functional specifications. However the developers also have the technical specification. Usually their main focus is on the technical part. This leads the developers to miss out on the whole purpose of what the code is actually supposed to do. This is one of the reasons why lots of defects are clustered over one area. It doesn't matter if the code is very much efficient if it was not processing what it should be.

There will be times when defects are found in one common area. This is because the dev has not understood the functionality correctly and has a different understanding.
At this stage, the tester should have a look into the code and tell the dev that this where you're going wrong and the logic should be this instead of increasing the bug count to his name.
But beware this will not at all go down well the developers !!!! Only tell them that the logic behind the code is incorrect.

Now one might say that how would the tester understand the written code??? My suggestion (and Cem Kaner's-Lessons Learnt in Software Testing) for such testers would be to first go and learn a programming language. I am not saying that become a master of that language, but just get used to the whole feel of coding. Writing code is not tough, it's the logic behind the code which is challenging. The logic is all what the tester needs to care about and not how efficiently the code has been written.

How much does a certificate matter?

Have a look at this conversation:

Friend A: Hey Man, I am now a certified Java Programmer
Friend B: That’s Gr8 dude !!!
A: Yeah I know. Today was the last day to get certified so I am really relaxed now.
B: Huh, What do you mean by last day?
A: Well, today was the deadline for our batch in our company to get certified.
B: Ohh I see…so you must be aware of multiprogramming feature of Java. Please explain it to me. I am not able to implement it.
A: Sure. Multiprogramming is ’Yada Yada Yada…blah blah blah….’
B: Dude, even I know the definition of it but how do you use it??
A: Sorry man I won’t be able to help you on that. I haven’t used it myself either.
B: But you just got certified right? Wasn’t this topic in your syllabus???
A: It was but I didn’t really go deep into it because in the exam you don’t get very hard questions related to this.

First of all, I would like to say that I am not against any certification !!! I am against those who force people to get certified.
Generally people get certified because they have been asked to do so or they are looking for a job which demands a certification.
But I’ve also seen people who challenge themselves for a certification & I am proud to say that I belong to this category. I recently became a certified tester but I wasn’t told to do so. No one told me to get certified in x months.
I have only 9 months experience in testing so when I was preparing for the exam, I could relate most of the topics with the experiences that I had. This has helped me in learning new stuff in testing that I could now use in the future. Above everything else it made me realize how many technical mistakes I had made. The benefit is obviously yours if you do it with a good heart and not just for pasting a logo on your resume.

Suppose you have a good experience in one technology or testing or whatever and still no one has asked you to get certified. The obvious benefit of this that you don’t have a hammer on your head to get certified.
However the loss is yours !!! You won’t be able to judge where you stand. You Don’t know what to expect from yourself.

Don’t just get certified just for the sake of it. Do it to improve your skills.
I don’t need a certification to prove that I am a tester. My work will show that. However I need it to show people that I am very capable of being a good tester and ready to learn new things.

Let the Testing begin

Hello and Welcome to my blog.

My name is Anuj Sharma and reside in Faridabad near New Delhi.
I am currently working as a Assistant Software Engineer at Steria India Ltd for the last nine months.In fact this is the first job of my life and also my first attempt at blogging. Through this blog I would like to share my experiences and my views on testing.

Being a fresher, one thing that I am aware of is that every BTech fresher wants a job that would let him code and not test that code. No one even thinks about testing in the college and neither do the college professor give any emphasis on testing.
I wasn't any different, but fate had something else decided for me.

After passing out college, I got a job after two months sitting at home, so I had no option but to take the job of testing. I had made up mind that I would gradually move into development somehow.
However, when my seniors asked me or rather told me to test the application being developed, I somehow started enjoying it. I loved it when I raised the defects !!!!
There was no stopping me and till date I have not stopped and have no plans to stop.

In these nine months, one thing that I have realised is that testing is being undermined in colleges across India.( I don't have the stats to prove it but I think that you will agree with me).
You're reading this post because you have a liking for testing (or I have asked you to )but ask your friends who are still in college or who are not in testing, what they think about testing. The answer would be unanimous, yr testing mein kya rakha hai..paisa kam aur growth bi nai hai yr (What's there in testing...The money is less and there is no growth).This is the answer you would get from almost all the Btech guys out there.(especially in India).

Students should be made aware that testing can be opted a good career option, right in there with development or support. Testing should not just be given to them rather they should be happy to take it.I also code but one thing I have experienced is that breaking the code is much more fun than writing the code.