In the previous post on this subject (part 1 of optimizing test cases needed for a patch), we had talked about the compromise between the need for reducing the amount of test cases needed for a patch while ensuring that the quality level of what was released was as good or better than the previous release. This can be a difficult compromise when one thinks about doing such a compromise, but most teams are able to do this fairly well (of course there are those cases where a patch fails or people report problems in using the patch, and those can lead to a varying set of problems, such as users getting into a stuck situation with the software that they have on their machines, or where another patch is needed in quick succession to ensure that the earlier problem was rectified, or even when another patch or quick fix was deployed, the company still suffered a Public Relations problem; we will talk about the problems that come about when a patch fail in another article, maybe the next post on this topic).
So back to the main subject. How do you optimize the number of test cases that you need for a patch or for a dot release ? Well, first of all, we need to clear these terms up. What is a Dot release vs. a patch ? Well, when we talk about desktop applications, let us use this logic. A patch is a small installer or set of files that can be downloaded and run, and which will update a few files. A patch is typically meant for the cases when there are some specific files that need to be updated on the application, typically meant to fix something that is broken or to provide a limited functionality in a way that it can be isolated to a few files.
A dot release is (and this differentiation and phrasing can be different in some cases, this is based on my experience) a case where the entire application is made to users, the difference being that there is a small set of functionality that is updated. So, consider that a number of files need to be updated on the application, or that there is a case which spans across the entire application (we once had to provide support for a new Windows OS that was released a few months after we released our application, and we released a new Dot that provided support for the new OS; this would just not be possible in a patch). A dot is as big as the original application, so if your application is say 200 MB in size, then the Dot would be of the same size, while a patch could be as small as 500 KB. However, doing a dot is still not expected to take as much development and testing time as that of the full release of the application, since there is a minor amount of functionality that has been updated.
More to come in the next version of this topic (part 3)