Dot / Patch release: Estimating the features where there is a change required

One of the previous posts I wrote about was that of a Dot / Patch release (Estimation of dot / patch release) where there was an effort to show what are some of the reasons for a dot release or a patch release and the broad level points about how to estimate the amount of overall effort needed as well as the generation of schedule needed for the release. This needs to be done even if you already have a hard date for the release of the patch / dot release, since if the generated schedule is going far beyond the required date, then there is something wrong which would need to be solved (possibly by adding more resources, although that cannot be done in every case).
This post talks about actually doing an estimation of the changes required by working on the different features to see the overall impact of the change. Consider a case where a dot release has to be made for the application, with a change made in one of the features for a major defect. Now, the dot release has to be made in a couple of months, with the exact release date being decided based on the estimates for the different areas of the release (development effort, testing, localization, etc). One of the starting points for this estimation effort is figuring the effort needed for development, and for that, there needs to more detailed investigation of what areas need development effort.
How do you do this ? The first and most important starting point is to ensure that you have an experienced developer to do the investigation and estimate. The actual effort can be done by somebody in the development team, but the investigation should be done by a senior and experienced developer. How do you start:
- First, make sure that the developer has been given details of the change needed in terms of requirements
- Give the developer some time to discuss with other team members about the areas which are impacted.
If this is a core area, then the developer would need to go across the application to determine the impact. For example, there may be a need in the user security framework, and that would spin across all the application. If the change is localized to a specific area, then it is easier to make the effort estimate of the change. There is no great complexity in this area, as long as the developer does a thorough job.
- The senior developer should spend time with the actual developer who is going to work on the release and make sure that he has enough understanding of the changes required, and depending on the skill of the developer assigned, make sure that the correct estimate is given (which may included a required buffer).
- The developer also needs to ensure that he has spent time with people from the localization development team and the installer / release teams so that he has an idea of the amount of time needed from their side and can also include these in the effort estimate.
- The developer needs to spend a fair amount of time with the testing team so that they have a good understanding of all the changes that are going to happen in the release as well as the actual impact of the change including all the areas of the application that are impacted. 

Being able to estimate effort needed for smaller releases (patch / dot release)

One of the most difficult tasks to estimate are the smaller projects that a team needs to do. Consider a long project, the typical new version release of a software (for a typical long example, consider the schedule for the release of a new version of Microsoft Office - is it always typically more than 1 year); now even when the team is busy doing this release, there will be always be the need for doing a dot release or a patch at the same time (or even multiple such releases). Why would this happen ?
- There could be a security issue for which an urgent patch needs to be released,
- There could be some new feature that is meant to be pushed through before the next release
- Because the release schedule is long, defects that are found during the next few months are collected and released in an interim release that is then released
- And this is one of the most interesting reasons for a release - I know several people who will not take a new version of a Microsoft until a service pack has been released, since that is when it would have stabilized - so this puts pressure on a company to do a release within a few months

With all this, who does these interim releases ? For products where there is already a definite schedule of interim releases, a small sub-team can be setup to take care of these releases. Such a team will soon gain expertise in doing these smaller releases, and can work on the main release if there are no interim releases ongoing. However, for teams where there is no definite schedule of release of these interim releases, it does not make sense for a team to put dedicated folks to work on the product. Even more, in my experience, when people are assigned to such interim releases, there is a need to rotate the people working on such releases, since these are seen as essential but maintenance, not with the excitement of working for something new.
Now, once people are assigned to do the project, there is a need to figure out the schedule for such a release. However, in most of these cases, the end date is already fixed - the Product Manager already has a date in mind about when these releases need to be released. But, the team still need to define the estimate and a probable schedule in mind:
- Whether this be a dot release or a patch (a patch is a small set of files that is downloaded and can be installed, a dot release is typically the full installer with a few changes in the files). The advantage of having a dot release is that it can replace the original installer
- Define the change that is happening (this typically means the files and features that are being changed, and the estimated impact of this change)
- The amount of time needed for the development team to make the required changes
- The amount of time needed for the testing team to test the area and surrounding areas (this would also include the installer created for the release)
- Typically most products have language versions, and those need to be created and tested when a dot release or a patch is made. So, the estimate for the amount of time needed for these activities also need to be incorporated into the schedule.

Together, all of these can be woven into a schedule for the interim release. If it turns out that the deadline given is less than the projected schedule end, then you need to push back. For a small release, it is next to impossible to meet the project with the required quality principles, unless sufficient time is given. We once had a situation where a particular variation in the installer made a small error in the registry, which then prevented those who installed from being able to install another update, and there was a lot of backlash over that - we had to release another patch for that one.

Read more about the estimation done by a senior member of the development team.

Preparing test cases so that a subset can be extracted for use as well ..

Do a good job while doing the initial design and preparation, and it can be of big help later. How many times would you have heard this, but it is true, and we recently had an example of how relevant this actually is. Consider that you have a test plan and test cases to deal with the testing of a feature. It is a large feature with many workflows, and a number of combinations of inputs and outputs. These different input and output variables are what make testing of the feature difficult and lengthy, since each of these variables has to be tested along with the possible combinations. Overall, in any big software product, there can be many such features that need to be tested thoroughly, and possibly tested many times during the development of the product. So, if there is a big set of test cases dealing with the feature, then it makes it easier to test on a regular basis.

Now, let us consider the cases where the feature does not need a complete testing. If you consider that the complete testing of the feature may take more than 2 days, there will be times when you will be able to spend not more than a couple of hours on this feature. And if you do not have an automation run for the test cases, then let's continue with this post (if you have built automation for testing these cases, then it would not take 2 days, much less, more like the 2 hours that is part of the requirement, but building automation cases also takes time and effort, and most teams cannot build automation for all of their test cases).

However, as you get closer to your release times, you cannot afford to spend the full testing cycle. You diminish the risk by controlling the changes that are made, and then do a reduced testing of the features given the constraints on time available. And then there is the concept of dot releases or patches. These typically have far less time available for the entire project from start to end, and yet, there needs to be a quick checkup of the application including the features before there can be a release. Another example is when the team is releasing the same application in multiple languages and operating systems. If the same application is released across Windows XP, Windows 7 and Windows 8, Mac OS, and in a number of languages (and the large software products are released in more than 25 languages each), then it is not a realistic assumption that each feature needs to be tested on these various languages and operating systems in full detail. In fact, most testing teams do a lot of optimization of these testing strategies, and try to do a minimum of testing for some of these platforms. 

But how do you get there ? When the testing team is preparing their test cases, they need to think of these situations. The tendency is to create test cases that flow from one to the next one, and are meant to be followed in a sequence. But to handle the kinds of situation above, the test cases need to be structured in such a way that they can be broken up into pieces for situations where the testing needs to done in shorter periods of time, and yet make the team still feel fairly confident that the testing has been done to the extent required. It also requires this kind of breakup information to be listed in a way that another tester later on who was not informed during the preparation of the test cases needs to use a subset of the cases for one of the special needs mentioned above (which can happen all the time, the original tester may not be a part of the team any longer, and may not even be a part of the organization).