This article tries to analyse various factors injecting defects and how to minimize the defect ratio and amount of rework we do during a software/application development.
When we estimate effort and hours for a project we dont estimate the number of bugs or the amount of rework we will be addressing during the development. Actually this is a hidden factor which eventually determines the delivery timeframe. More time we spend in rework+bug fixing, more deviation from the project plan.
From various analysis it is concluded that high severity defects are uncovered during UAT (User Acceptance Test) when actually the user do the testing. It is very likely that those issues are related to the business of the application i.e. it could be the business rule which is NOT being captured or it is implemented wrongly. The impact of such a defect could be very immense which might lead to a huge rework never captured during planning of the project. Eventually this result in slipping the delivery date.
So who has introduced those defects ? Who should be blamed for this? Hmmm probably every one will blame one another.
From the past experience most of the defects are induced during requirement analysis and designing and it is uncovered in QA or UAT. On the other hand the developers are the main victims and has to go ahead fixing those with all the blames on their shoulders.
I have tried to list down some of the key points that could lead to a smooth project delivery. Those are as follows:
When we estimate effort and hours for a project we dont estimate the number of bugs or the amount of rework we will be addressing during the development. Actually this is a hidden factor which eventually determines the delivery timeframe. More time we spend in rework+bug fixing, more deviation from the project plan.
From various analysis it is concluded that high severity defects are uncovered during UAT (User Acceptance Test) when actually the user do the testing. It is very likely that those issues are related to the business of the application i.e. it could be the business rule which is NOT being captured or it is implemented wrongly. The impact of such a defect could be very immense which might lead to a huge rework never captured during planning of the project. Eventually this result in slipping the delivery date.
So who has introduced those defects ? Who should be blamed for this? Hmmm probably every one will blame one another.
From the past experience most of the defects are induced during requirement analysis and designing and it is uncovered in QA or UAT. On the other hand the developers are the main victims and has to go ahead fixing those with all the blames on their shoulders.
I have tried to list down some of the key points that could lead to a smooth project delivery. Those are as follows:
- Project Estimation: During estimation project managers should keep enough allowable buffer to cope with any uncertain activities like rework and increased defect ratio from past experience. Update project plan whenever client aggrees on that.
- Requirement Analysis: These phase introduced most of the defects and unfortunately uncovered most of them during UAT. So give enough time/hours during estimation to baseline this. Do not wait till UAT comes back with issue which may be too late. Especially when writing use case give utmost attension.
- Review: Many times it is seen that clients are NOT very reluctant to review those documents. In that case if application fails to go to production both client and vendor is responsible. It is also seen that when everything got over including developement and testing client comes back seeking updation in the requirement document and so on and forth. So it is very important that client review any documents being sent for his approval should be correct and as per the expectation and on time.
- Avoid blame game: An individual can be blamed and responsible for NOT meeting the delivery date. Everyone is equally responsible for any thing good or bad happen during the development. It is the process which could be blamed. Keep this experience as historical data and can be used as input in future projects estimation.
Regards
Monu
No comments:
Post a Comment