1. Have a plan Dorthy!
Yes, everybody does that, but not everybody involves the QA right from the beginning. Well, we come into the picture somewhere down the waterfall! Whereas task of the developer is to 'make', task of the QA has always been to be 'break'. In case if the QA shares part of his strategy and plan right during analysis and development planning, the patches are bound to decrease drastically. Call it fate or call it the “I warned you before” rule, sharing a plan with the QA and getting the strategy from the QA results into minimum damage to the timelines and chances of patches are eliminated.
2. Go Agile!
While it sounds to be more complex than the usual project management methodologies, Agile once successfully implemented, it quickly leads to greater simplicity, freeing up the creative potential and efficiency of software production teams in ways that sequential, linear, and more strictly procedural, by-the-book approaches to software development rarely do. Agile, as its name suggests, simply proposes to be a faster, more priority & risk focused, and more flexible, adaptable, and efficient way of conducting the complicated business of software production. Going Agile makes everybody on the team stay awake(literally) and more attentive towards changes. 3. A peer a day, keeps bugs away!
It is very human to find mistakes in the work that “competitors” do and peers can be one of your best critiques ever. They would know where you would be putting your obvious bugs and trust me, that hurts! Ouch! But from a project point of view, it kind of turns out to be best for ensuring that the same mistakes don’t happen again. Be warned that this might also lead to disasters sometime and yeah, blood fights cannot be ruled out too! So be a bit careful if your team is not matured to handle peer reviews but be certain that this approach leads to absolutely no room for patches.
Is there anything else that you would want to add to this list?
Couldn't agree anymore!
ReplyDelete- Satish
I must say, this is faced by almost all QA's and for every release its the same situation, very well written and explained.
ReplyDeleteAfter falling in the same situation almost a dozen of times I realized the root cause(patching a defect) is due to:
1. Not designing the feature appropriately
2. Not giving sufficient time to implement / fix
Believe me when patching a code / defect is required, 99% of times its because of not giving sufficient time and 1% may be due to other reasons.
Dev/Engineer when given sufficient time will definitely able to deliver the appropriate fix. You can deliver your feature with a known issue instead patching it temporary with 100 hidden issues.
May be you can buy some time and give appropriate fix for the defect in subsequent fix releases.
You said it Rahul! Kudos to the comment. Totally agree! Time is the only missing link everywhere.
DeleteI couldnt agree more Mr Rahul. I hav my share of 'Fake it till you make it' type of organizations where the development team was given one liner requirements and asked to built the next big product of the market. With no time or planning and focus only on the golden egg..products where bound to fail. Mgmt simply pushed all the blam to us developrs for patches. But patches were need of the hour. Nobody wants to spend extra hours on a thankless job. So patches was the solution. What is your opinion sir?
ReplyDelete