shrini Kulkarni's WebLog on Software Testing

Logging Off ....

2005-03-25T10:08:00Z

With mixed feelings I must announce that I am leaving Microsoft – a great company where I worked for last 2 (23 months to be precise) eventful years. I thank all you nice people for making my stay here very memorable and knowledgeable. Looking back, each moment of these years had everything – fun, excitement, celebration, tense and stressful moments (around releases), anxiety (while waiting for drops from dev) etc.

I know it is tough – not to be associated with Microsoft, not having an email ID ending with microsoft.com, not blogging at msdn as these things have more or less had become part of my identity. But as somebody rightly said “Change is the only constant thing in the life” – I am looking forward for a new job. I am carrying with me lots of lessons in professional and personal life which I learnt by interacting with people like you.

Visitors for my blog -- thanks for yout comments.

Please update your links to this new home for my blog. Keep coming. I promise to write more and more on Testing.

So where I am going …. Let me tell you that will be in Hyderabad, India. Keep guessing about my new company.

Thank you microsoft.

A post on interview tips ....

2005-03-07T15:50:00Z

I was asked by one of my blog reader to write on interview tips. Here are my broad thoughts on the topic. In last six months time I had chance to interview close 30-40 candidates. Most of the people had issues on similar lines....

Be sure about what you have written in Resume
Be honest to admit things you don’t know.
During interview, display good listening skills.
Ask for clarifications – that gives you chance to think for the reply.
You are not expected to answer the moment question is over – Do ask the interviewer “Can I have 2-3 minutes to think” – This perfectly OK
Before starting the answer – spell out any assumptions you make. Interviewer might be interested in knowing whether you are good thinker or not.
Avoid discussing matters related to salary, location etc with technical interviewer
Don’t bad mouth your previous employer.
Talk slowly and confidently.

Here are few links that recommend for interview tips

http://www.jrothman.com/weblog/htpblogger.html

http://www.asktheheadhunter.com (About general job/employment related tips and case studies)

These are very common and most talked about interview tips but people fail to give importance to it. It is like everybody knows that doing physical exercises is good for health and a very few follow it.

Shrini

Tester's core function ...

2005-02-18T18:25:00Z

Lot has been written, discussed about topic. Time and again, when this question is raised, people typically answer in one or other variant of following ....

First - controversial or unreasonable (IMHO) ones -

1. To find bugs or to demonstrate that program does not work

2. To validate requirements, design and code

3. To stop the release if quality requirements are not met.

4. To ensure the quality

Rather acceptable ones ...

1. To help project team to access the risk and plan test to access the risk.

2. To check compliance to statutory and regulatory requirements ( like SOX)

3. . To help project manager to make GO-NOGO decisions.

Here comes mine (may be most of other's)

TO HELP DEVELOPMENT TEAM TO SHIP A QUALITY PRODUCT

Whatever test does should be aligned towards this goal. Developers having a job in hand of constructing our of stated (and implicit requirements) - tend to loose sight on or get busy in development. Test will help dev to in those "overlooked" things - like all possible uses and abuses, Non functional requirements like - usability, security, Performance etc. This is collaborative work. Let us not fight - collaborate.

Shrini

Tester's Gene - DNA

2004-12-31T15:27:00Z

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

what is success?

2004-10-31T10:52:00Z

Just thought of writing on this. Here are some opinions and views ..

· Success is not a destination but a journey.

· Success is a state of mind.

· Success is relative. What success means to me is not to others.

· Can you measure success in some tangible units (other than money!!!?)

· Success != Money ( alone)

· Some time success becomes burden.

· Having success means - need more success.

· Are success and winning are synonyms?

Any thoughts?

Agile/XP development v/s PSP/TSP

2004-10-31T10:45:00Z

I have two groups in my team one working as per PSP/TSP (Pioneered by Watt's Humphrey) methodology and other using Agile/XP ( work by likes of Martin Flower, Kent Beck, Bret Pettichord and others And Agile alliance). I was prompted to see how these two compare and contrast. First I was concerned that am I making a "valid" comparison?

At the same time I happen to read articles from Bret Pettichord who is a respected person in agile/XP and in software testing in general. I was pleasantly surprised by Bret's reply where in he termed this comparison as very "interesting encounter" and asked to me blog on it. In coming days I will be working on this and more updates on this soon

Shrini

PSP/TSP - A bottom approach to Quality

2004-10-31T10:00:00Z

I am pullling this one from my archive mails. I attended this training almost a 10 moths ago. Here it goes ...

What is PSP?

In a nutshell: A “common sense” – a self disciplined approach to work at an individual level.

The important elements of PSP

Plan your work – Irrespective of size and complexity of unit of work, have a plan – documented plan is recommended.
Estimate the size of work – For developers – it is LOC ( could be function points or any other size measures) – Use Historical data.

Gaps I see in PSP: Nothing specific for testers. Complexity is not considered as a parameter

Estimate the effort - how much time it takes to do the work Gaps I see in PSP – Complexity is not considered as a parameter.
Schedule the work – Have an idea of finishing time/date.
Log your time – This is the most important aspect of PSP, without this all the rest becomes meaningless. PSP recommends Logging time in “Minutes”. This looks not feasible at least to start with.
Be watchful about Quality – Manage the defects create/injected by you. Be open and pragmatic about number, types of bug/defect. Track “Phase injected” and “Phase removed”. An ideal situation would be that these two events happen in same phase of SDLC if not “as close” to as possible.

Gaps I see: PSP is heavily dev oriented - there are no major/specific “mentions” about test in PSP core material. Terms like “defect injection” does not apply to test as test does not inject any defects per se. However, one could interpret that a defect missed by test is equivalent to “defect injected” – proper terminology needs to be in place. I am not sure of any tailored versions of PSP for test as of now. Need to take the initiative to bring this matter with SEI and suggest suitable amendments to include test related issues. Same may hold good for “support” related roles and teams.

Have/Devise formal review mechanism for Review – Every phase in SDLC ideally should end with Review and corrective action so that point No 6 is taken care of. Device efficient checklists to guide and bring consistency in review. Every review should aim at improving checklists. Use Defect data collected in Point No 6 as prime input for design of checklists – concentrate on “typical mistakes made”.

How about TSP:

It is about a team at work – A team that consists of PSP trained/practicing individuals with a shared common goal and an established communication protocol.

TSP strives to make every team a “successful” team.

Pre-requisite: All the team members should have undergone 10day “PSP” training.

Note: TSP is not suitable for teams consisting of 2-3 people and those projects of 1-1.5 month’s duration.

1. Clearly defined roles - agreed upon during TSP launches.

2. TSP launches and Re-launches – Key events that happen ( lasts for about 4 days) in a TSP. Team decides upon roles for individuals in the team – there are eight such roles that team should decide ( details are in training material). One person can play multiple roles.

3. TSP re-launches happen when there is significant change happens for the project changes – like major scope changes, few new members getting added to team and so on.

4. Rest of activities like time tracking, Defect tracking, and review – keep happening at individual level.

5. A coach or guide – guides the team throughout the project cycle.

PSP/TSP vis-à-vis Stadandard Quality models like – CMM or six sigma

Standard quality models are at Organization level – attempt to achieve higher levels of Customer satisfaction and improved productivity – A top down approach.

PSP/TSP attempt to inculcate these at individual level and team level respectively - A bottom up approach. Both of these can co-exist.

I am not interested if ....

2004-10-25T16:17:00Z

Sometime back I heard about this beautiful story about "Gossiping" - talking about third person. I am not sure which Philosopher said this but it is woth reading and considering in life.

When someone comes to you and has some "interesting" story to tell about some third person who is not present at that location, ask following questions ---

1. Is this true? Do you really think it is true?

2. Is this something good about that "third" person?

3. Is this something that is useful in someway to me?

4. What if that person about whom we are talking is present right here and listening to you - will you still talk the same way? (this is my addition to the story ....)

If the answer to any or at least one of above question is "false" or "No" ( it depends how strict you want the criteria to be) - Cut the discussion and change the topic if you can.

It makes always sense to talk "good" about people. If you want to discuss "bad" about anybody - do it with that person else keep it to your self. It is particularly important in team environment. Be somebody who breaths positive energy and carries a positive feeling about fellow mates. It is something like "Appreciate in public and criticize in private".

Every time I talk about or drawn into a discussion about a third person who is not physically present at the location, I consciously pull myself in this direction and resist being drawn into "Gossiping". I am trying to comply with 100%

Shrini

Software testing Nirvana ...

2004-10-03T17:53:00Z

Here is what I thought as ultimate goal of software tester.

"Predict bug, go and find it rather than stumbling on it".

I will add more this post as I go along. Just wanted to register this thought. Comments are welcome.

100 things about me [not complete yet]

2004-08-31T17:35:00Z

I happen to read KC's blog post where she is writing about 100 things about herself. I liked the idea and thought of - "why not me". Here I go (I intend to add about 4-5 things per week).

1. I started playing Tabala ( an indian music instrument) from the age of 8.

2. My father used to take me to Indian classical music concerts from that age. Since these concerts use to start around 10 in the night, I typically used to end up in sleeping in those concerts right from the begining.

3. I used to draw Maps of coutries on the doors of my house, on the walls of house compound.

4. I first saw something like computer (looked like small TV screeen) when I was in College (11th). Used computer when I was in my second year of Engineering.

5. From my childhood days I wanted to become a Doctor ( who does not want to be. I thought then) In retrospect I think it is good that I did not become one. As my wife puts it, my patients would have had tough time in dealing with me. I tend to be lot pessimistic about "health" - not very strong mentally when it comes to "fighting" a disease.

6. Few things I was afraid of in my childhood days are - visiting Doctor - scared of "injections" and going for a hair cut (barbers then used to scare me with those weird cutters that used to run on my head). But best thing at the end of visiting Doctor (after having an injection) is a visit to a nearby hotel and I could eat whatever I like. My father is used to oblige me without a word.

Testers Bag of tricks Continued ...

2004-08-14T18:22:00Z

Just happened to read this blog post from Micheal Hunter. He talks about tricks that will be useful.

Shrini

Happy birthday india ....

2004-08-14T17:53:00Z

India celebrates it's birthday on 15th August. Long live india ... Jai hind.

Catching up with MBT ...

2004-08-06T17:27:00Z

Last two days of this week, I kept my focus squarely on getting some quick case study to validate my knowledge on Model based testing. It has been nearly one year that I started reading about this wonderful technique and this time really wanted to put all that to into a powerful demo. I was like somebody who was interested in swimming and knew bit of do’s and don’ts. I was just walking around this big pool of MBT. I was not sure where to start from. Finally I made up my mind and got into the task on making a model myself. As I finished doing a model - it something that works and can generate test cases. I am pretty excited about this.

In next week, I shall fine tune this model and generate some interesting cases and scenarios out of this. Incidentally, this happens to a live piece of work - which we will be testing for our month end release. Therefore, lot of excitement, apprehension and curiosity building up to see what happens when model meets real application.

I have an email sent out user groups working on MBT asking for help on following issues. I hope I will get some clear direction on these.

Once, MBT is adopted as a part of standard test methodology (test design and execution), how does it change SDLC ( in things like test planning, Strategy etc).
MBT tools are known to generate endless test cases, how can one prioritize the test cases so that one can run the test passes in the stipulated time frame.
We use PS-TCM module to store test cases, is there way that I can feed the test cases generated by a MBT tool to PS-TCM? Has anybody did something similar to this?
Now coming to automation, can we use industry standard record and play back tools like WinRunner or Rational Robot in connection with Automation framework generated by MBT tools? Any instances of where people trying to marry these two things?
Traditional way of looking at automation is write test cases, convert them to “record and play back” scripts and execute to do automation regression testing. How MBT does helps in doing this?

Shrini

Writing a good email ...

2004-08-02T16:49:00Z

This is my first post of this week and I talking about some non-technical topic.

Over the last few months, I feel that my “email writing skills” have improved greatly. What does that mean? What are typically the problems when people communicate thru mails? What are problems with “email recall”. I thought of dedicating one of my post for this important aspect of day-today work and improve it further.

Typical mistakes that happen while emailing:

1. Sent to wrong person (not verifying that the person to whom you are sending mail is the right audience)

2. Doing “Reply” or “Reply all” out of context. While the first version may cause little damage (only few persons getting mail as against all in the mail thread), second version causes mail JAM. Sometimes not knowing that you are doing “Reply all” and talk about something thinking that you are doing only “Reply“(lets your manager know your frustration that you are sharing with your peer!!!) can cause havoc.

3. Forgetting attachments - This generally arises out of “urgent work”. In the mail, you refer to some document then talk about it in the whole mail - but forget to make the attachment

4. This is a corollary to point No: 3. It so happens that at Friday at 7:00 PM when (you are planning to go out station for a weekend party - rushing up) are asked to send a mail with all the documents related to that morning's meeting to somebody across the globe. You make the zip file out of all those imp documents and send the mail in hurry (with the zip file attachment off course) and you go home and enjoy thinking that everything went well. It would be really frustrating when you notice on Monday morning that the mail did not reach other side at all as the mail attachment size exceeded the limit set by server.

5. Doing or not doing spell check on the content. Having spelling and grammar check is good but blindly depending on the spell/Grammar check to do all “proof reading“ for you for that all important mail that you are sending to your manager or client is “not good”. I have had few instances where it just made blunders while checking for errors. At the same time, not having spell check is also not good. One has the option of setting spelling and grammar check as default or set it by case-to-case basis. I have set it to default and working fine for me.

6. Writing big mails having paragraphs running into 50-75 sentences each.

7. Sending half-backed mails - when you are not completely done with the mail but accidentally hitting Alt S or send.

8. Recalling mails - I don’t know how many people really feel that it works and minimizes the damage done by wrong mail.

9. Referring to some links in the mail - to network shares or web sites that are broken. This type of mistake can be life threatening e.g. sending a mail to your manager or to a large group of influential people pointing them to a file share (detailing your work on “How to be effective at work“ ) on the hard disk of your laptop or to a share that does not have required permissions.

10. A bit lighter one - Expanding on (+) “group alias or distribution list“- this breaks rules that people might have based on alias name. I did that once to know who all are there in the list and got this friendly suggestion from one of my peer.

In part 2 of this topic, I am planning to touch upon few do's that I am following with good degree of success to have “Good track record” of mails.

I request all of you, reading this post to register the problems you faced with wrong mails and say few words about how did you come out of them. Also do share the best practices that you follow.

Thanks in advance

Shrini

Testers bag of tricks ...

2004-07-30T11:41:00Z

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