Monday, December 15, 2008

Post-mortem

What is the first thing that comes to your mind after reading the title?
A dead body being cut by scalapel,and a doctor trying to get into the blood and veins of the body. In the field of software testing also,post-mortem is nothing less than what it means literally. For those who are not aware of what post-mortem is in terms of software testing, here is the defination: In simple words, it is a detailed understanding of what went well with the project and what else can be done to make it better.

Post-mortem meetings are often conducted after the project is completed to identify what lessons have been learnt. Normally all parties,users,testers,developers have strong opinions about the things that have happened during the project,what the end product is. In Post-mortem meetings,the opinions are supposed to be honest so that they can contribute in running the future projects in the benefit of all the stakeholders. If one tends to get all the stakeholders in one place,what you think will the outcome be, a long,rarely conclusive, boring meeting.
So what can be done to make post-mortem meetings effective. Here are some of the ways:

1) It would be better to rely on the QE team to provide inputs on the postives and negatives of the product because they are experts in gathering such information (providing status reports for builds). These inputs can then be discussed with all stakeholders and can be reviewed.

2) The agenda of the meeting should be floated well in advance so that people have already put some of the brains and efforts in analysing the goods and bads.

3) Never turn a blind eye to the problem. A person who says the project went perfectly ok,needs to have either counselling or a strict performance appraisal.. :)

4) Moderator should take care that healthy arguments don't turn into finger pointing and blaming. this meeting is strictly not to make blame games.

5) Members participating should be made fully aware that even if they point problems in themselves or their team,it is in no way going to effect their or as a matter of fact,anybody's performance appraisal (that's the major worry that prevents people to be honest). They are here to make improvements.

6) Proper metrics should be used to analyse the results, for eg: rate of bugs found in different phases and also the type of bugs.

7) The points should be jotted down,issues should be prioritised.

8) Implementing the changes will make the team excited and more motivated to work for the betterment.

9) Proper communication should be done time to time about what has happened to the recommendations. Discussions should be kept live,changes made should be communicated along with the impactt they have brought.

These meetings are core to the success of any project. I have seen performances increase manifold as a result of these meetings and much more quality products being rolled out. The seriousness of these meetings entirely depends on the stakeholders involved and their level of commitment to make a difference.

3 comments:

Pranay Gupta said...

a great way to explain what software testing is. i have my relative working in microsoft as a software testing manager. he often came to the situation in team meetings were it is difficult to point out the situations for better versions of software if they are discussed within groups.

Unknown said...

Hey thanks for commenting on my blog...and btw are you in to software testing?

Jaanvi said...

@Pavan

Yes I am into software testing and professional writing.

Blog Widget by LinkWithin