Estimating QA time when code is rolled back
How do you estimate how long it will take to QA when a major feature is rolled out of the release? Here is my scenario...
About three months ago we started preparing for a major release which was scheduled to be delivered this evening to our QA team. This release was to include 2 major functional changes and a few minor changes to our web application (forecasted 800 hours of QA time for the entire release). All of our test plans, test cases, scripts, etc have been writted, reviewed and approved.
Unfortunately, it was announced this morning that the client has changed their mind and no longer needs one of the new features. After much deliberation from our development team, they have determined that it would be best to rollback the code as this would give us the cleanest code to deploy. While I agree with this decision I now need to re-estimate my original forecast.
So, how do you go about estimating this change? I feel that we still need to thoroughly regression test the areas that would have been impacted but should we focus 25%? 50%? 100% of the amount of time we thought it would take originally to test the feature? Or do I forecast my time based on something else?
As well, I currently know that the release will not be delivered to QA this evening but it has not been decided yet if the release will be delivered to the client a week later - meaning that QA (no surprise) would have one week less to test.
Re: Estimating QA time when code is rolled back
You will probably still execute all of the tests designed for the feature that is still going in. You will probably remove the tests designed for the feature which was removed. You may include regression tests to ensure that all of the code for the removed change are really removed. You may execute the same regression suite as originally planned, or you may remove some parts that were specific to the removed change, if you feel those areas are no longer a large risk.
I have seen projects where the development time is dropped, but the test time is not. This is because when a feature is removed, you often want to ensure it was removed thoroughly.
With only one week to test, though, you may simply use these ideas as a way to proportion your allowed time.
Tim Van Tongeren