The best dev in my world is a SWE that was a Tester before.

Our QA Team Lead Erfana had shared this link with us. I have managed to watch & listen exactly 27 minutes of it. You need to have patience to complete the entire video. I am keeping this link here so that it does not get lost. I wish to see the entire thing of it.Up to this 27 minutes, the best comment/feeling of the speaker seems to me is "The best dev in my world is a SWE that was a Tester before."
This is so very true. Sometimes i also felt that what if we ask the developers to act in my role for some time. In each sprint we can follow a convention that developers will pick at least two Testing task. It will help to grow the testing mind set in them. That will help them to write bug free code later. While coding they will learn to think as a manual tester, or i can say user also.
GTAC 2010: Turning Quality on its Head

What are the cases to test a lift (Elevator)?

I have faced lots of interview questions in my life. Among them some are very interesting. Let me tell about one. How will you test a lift (Elevator)?
In the interview board I had answered the question with some cases. Later thought let’s summarize the cases. So following are the cases that a QA person will try to test the lift.
We can categorize the lift into two major parts:
A. GUI
B. Functionality


GUI cases:

1. Test the area of the lift is according to the requirement.
a. Floor length
b. Floor Width
c. Height
2. Material
a. Steel body & door
b. Glass body & door
c. Or a mix of both
3. Is the mirror there in all the four inside walls?
4. Is the set of buttons matches with the actual no. of floors in the building?
5. Is the air circulation window is at the right place?

Functionality:

1. Door opens or closes automatically
2. Up Arrow button moves the lift to upwards
3. Down arrow button moves the lift to downwards
4. Pressing the button of the specific number takes the lift to that specific correct floor.
5. Pressing two consecutive number, may be 4, 5….takes the lift first to 4th floor then to 5th floor.
6. Try random floors, 2nd, 4th and 7th floor, Should reach the correct floors sequentially.
7. Check if the air circulation is okay.
8. Verify the capacity to carry load
a. Try an empty lift
b. Try with load beyond the capacity
c. Generate load using some weights
9. Verify the speed.
10. Check the electric supply and consumption.
11. Verify the case what if the electricity is gone.
12. Verify the telephone is functioning well inside the lift
13. Verify the light is on
14. Verify the instructions for people are hang in there inside the lift.
15. Verify back up power supply is working fine.
16. Check the strength of the ropes.

****Never try with real people while testing ;), so here comes the preparation for dummy data, dummy weight in this case.

So looks like I am getting into it  . Actually testing of anything could be fun. A Tester needs to increase the capacity to think of different cases, multiple scenarios. I think this is one of the best qualities a tester should have.
I also need to work on it, I need to play with random things and think how to test it. Thanks to those two young girls who made me think.

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 :)

Simple & Pure testing

I love simple things and i believe in simple things. I like to think simply whenever i need to test anything. I hate theories, love things in action. So i name my blog as mysptesting, which means my simple & pure testing.
It also matches with the application that i test everyday. It is a SharePoint application ;)
Today i was googling for nothing and found this nice blog, it is the only blog that i have started loving -
http://tuppad.com/blog/

Will try my best to continue...........

Happy Monday to everyone.