Tester's Gene - DNA

shrinik — Fri, 31 Dec 2004 15:27:00 GMT

I have not written on this blog for a long time due project pressures and lots of weekend travel. In one of the interviews that I was taking for "contract" positions, I asked this question "how do you describe Gene of a tester"? This question when expanded - took me following thoughts

1. Are testers made by birth? how different are these people from those who learnt skill of testing after birth?

2. Can "testing" in pure sense be taught like - say music? how to teach testing?

3. How to distinguish born testers from other testers? This is required for spotting testing talents

4. Who can be better tester ? How to recognize and develop such skills from early age ?

Recollecting from what I read on net - Any good tester should be learning every day and increasing their knowledge of the what-if scenarios that lie outside the scope of the defined specifications. Testers who are NOT programmers, tend to loos this edge. Developers ensure the application meets spec and they are wonderful at it. Testers expertise and skills lie in the exploratory areas of "what happens if I ...

I welcome thoughts on this subject ....

As this happens to be the last post for this year - let me sign off with saying "Happy and prosperous new year 2005"

Shrini

Testers bag of tricks ...

shrinik — Fri, 30 Jul 2004 11:41:00 GMT

This is my Friday post and I am just finishing my Six sigma training. I am writing on one of favorite topic --

Have you heard a tester, boasting about his/her bugs, tester talking about his/her ability to find bugs given a specific time irrespective of whatever is the application? - How can one manage to do that consistently, every time? I consider myself as a “good” tester - Can I make such claim that I can always find bugs - every time? Not every time.

This prompted me study few testers that make such claims and come out as winners most of the times. Few findings are:

1. These people are have a great presence of mind, learn from others mistakes, bugs.

2. Keep developing their bag of tricks continuously. It can be great learning experience by sitting with them for few hours and watch them testing. I would love sit along with James Whitteker and watch him doing testing.

3. Pay attention to evey small, in-significant changes that happen around them while testing - screen title, Status bar messages, CPU usage, Disk acitvity and many others - other than their testing area. In other words, they work with one extra eye that keeps track of surroundings.

4. Tend to take “un-treaded“paths. Do something that is special in given circumstances - Think out of the box always.

5. High perseverance. Never give up.

I continue to watch great testers at work and keep learning. Next part of post is about documenting some of tricks of these great testers so that a knowledge base of tester’s tricks can be developed. I am collecting few trick likes here are few ---

From James Bach's – Tester’s micro behaviors

Variations in the order of apparently order independent actions, such as selecting several check boxes before clicking OK on a dialog box. (But maybe there is some kind of order dependence or timing relationship that isn't apparent to the user)
The exact path of the mouse, which triggers mouse over events.
The exact timing and sequence of keyboard input, which occurs in patterns that change relative to the typing skill and physical state of the user.
Entering then erasing data.
Doing something, then undoing it.
Navigating the UI without "doing" anything other than viewing windows and objects. Most users assume this does not at all affect the state of an application.
Clicking on the wrong link or button, then backing out.
Leaving an application sitting in any state for hours on end. (My son leaves his video games sitting for days, I hope they are tested that way.)
Experiencing error messages, dismissing them (or not dismissing them) and trying the same thing again (or something different).
Navigating with the keyboard instead of the mouse, or vice versa.
Losing track of the application, assuming it is closed, then opening another instance of it.
Selecting the help links or the customer service links before returning to complete an activity.
Changing browser or O/S configuration settings in the middle of an operation.
Dropping things on the keyboard by accident.
Inadvertently going into hibernation mode while using the product, because the batteries ran out on the laptop.
Losing network contact at the coffee shop. Regaining it. Losing it again...
Accidentally double-clicking instead of single-clicking.
Pressing enter too many times.
Running other applications at the same time, such as anti-virus scanners, that may pop up over the application under test and take focus.

=========================================================

I remember of seeing such tricks in few other Blogs posts. If anybody seen/has tricks like this which they can share, please contribute..

I will keep updating this post as I get more tricks..

Shrini

shrini Kulkarni's WebLog on Software Testing : Test Tricks

Tester's Gene - DNA

Testers bag of tricks ...