Test Case Showcase

This is the term now i am afraid of because next term is mine :(
Let's hope for the best.

In our place we have five QA people and we maintain a small forum, which we call QA forum. As different QA persons are working with different teams and projects, so QA forum is a platform where we basically share our sprint status, thoughts, learning, interesting testing topics etc.. etc.

Sometimes we arrange presentation on testcases, we call it "Test Case Showcase". As we all know everyone has different style of writing test cases, so we thought, better to share test cases with others. Everyone remains busy with his/her own project, so we never get the chance to look into others test cases. So it will be a nice opportunity to know different approach of writing test cases.

The next term is mine. I need to show my test cases. So i was thinking which one and how to present my test cases. Do i really follow any specific style? Am i following traditional style or anything new?

And now i am afraid, what i have found is, i never follow any explicit style. You can see the image, i use any thing in my test case.

> Sometimes it is simply a checklist with few points.
> Sometimes it has lots of tables.
> Sometimes traditional casees and Expected behaviour.
> Sometimes the entire screen shot of the requirement ppt is there.

What i believe is my requirement and context is changing in each sprint, so i should have the freedom to change my test case writing style also.

First i concentrate on the context, then i decide my test case structure.

While writing test case i keep few points in my mind:

1. Be careful not to skip any possible case.
2. I must make it simple and easy to read.
3. First part should contain the environment or data setup process.
4. Try to maintain an execution flow with the cases.
5. Where necessary do not hesitate to insert a screen shot.

and ..................can't remember right now :)

But i am happy with my test cases. I feel very comfortable while executing my test cases, and i think this is very important.

We call a test case successful when it can find lots of bugs. But i also want to add something with it.

Besides finding bugs a test case also needs to be comfortable to execute.

Happy Wednesday to all

Adding some more tips

I just have read the post titled “Hard to reproduce Bugs – Few tips” from http://tuppad.com/blog/, which is a favorite blog of mine. At the end of the post he has requested to add comments if anyone have more ideas that were not covered.

So I was thinking if I have faced some situations where I struggled to reproduce any bug. And the truth is there were lots of cases. So I am trying to summaries the things that I have learned while reproducing those bugs.

It is not always the case that I was doing exploratory testing, and got a bug, but later failing to reproduce it. Sometimes after the release is gone, real users report bug. This usually makes us (the QA people) very upset. We then start to curse us, that how come I have missed this bug.

And here comes the challenge to reproduce the bug. The number of errors may be increasing in the production site; team is having mails after mails to fix the bug as early as possible. But what to fix? To fix the bug first you need to reproduce the bug. Bug priority is high, so the QA person is in great danger.

As I work in a project, which is mainly a User Management MOSS site, sometimes we get errors directly claimed from real user.
And when it deals with lots of lots of users, the number of possible cases could be unlimited.

Following are some points that I try to follow while reproducing any bug that is claimed from user:
1. Try to collect (sometimes guess) as much information as possible from the user that exactly at what situation he/she has got the error.
2. Try to think of all the possible cases that the user may have interacted with the site.
3. If possible, try to know the Browser version, or else try with different browsers with different versions.
4. Concurrency test, which works lots of time. May be multiple users were working on the same thing at the same time.
5. Try multiple actions on that same module with multiple tabs/windows open.
6. Try with JavaScript enabled/disabled in your browser.
7. Load is an important issue, perhaps we had a list. I tested with 30 or 35 records in that list. But in production site that same list page shows error. Notice the load, the number of records was more than 120, so it was crashing.
8. For example in a web page the user is asked to enter his email address, and then to reconfirm that email address again. And there is a validation ‘Email addresses do not match’. User was typing same email address, but still he was getting the message ‘Email addresses do not match’. Finally we were able to reproduce the bug. User was giving an extra space after the email address, so system was finding mismatch.
9. Check the names that you are using while testing. We had a user with the name “Tindbaek”. But he was typing “Tindbæk” - so again error.
I just want to say while reproducing a bug that is claimed by the client, try to generate the exact scenario, the chance to reproduce the bug will increase.

Happy Thursday to all :)