Categories

A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

Trying to optimize on the number of test cases needed for a patch – Part 3

In the second part of this series of articles (Difference between Dot and Patch release), I had written about the differences between a dot and patch release, and started talking about the time involved. In this post, I will write more on this topic, especially about the time involved.
I mentioned in the previous post, right at the end, about the amount of time available to do patches or dot releases. Unless the development teams have specific and defined teams to bring out dot / patch releases, it can get real troublesome. When the work for the next version is ongoing, any amount of effort involved to do this dot or patch is never appreciated, and yet can be critical. If you take a desktop product, all of these have some form of installer, with its own complications. If you take the base product version to be 6.0, then the dot or patch would typically be 6.1 (or 6.0.1). When the user is installing such a dot or patch, the installation should bump up the product version to the 6.1 (or 6.0.1) version. This is necessary to differentiate between those users who have the version without the dot/patch and those users who have incorporated the dot/patch, and such differentiation is necessary for the following reasons:
1. Only a user with the version 6.0 should be able to install the 6.1 (or 6.0.1) version. Users who already have the dot/patch should not be able to install it again, and if there is a mechanism in the app that provides the user information about whether a new dot/patch is available, then this mechanism should not repeat the presence of the patch if the user has already installed the dot/patch.
2. If the dot or patch provides an uninstall, then there are cases related to uninstall.
3. Typically, part of such a testing is to check with a dummy installer (having the version as 7.0) about whether the functionality works about upgrading to the next version. This testing needs to be re-done for a user in the case when the dot/patch is installed.
4. If a dot release is being installed, then there needs to be testing done to see the impact on the currently installed version (the functionality could be that the new dot over-writes the older version, or co-exists, or asks the user to take some other step).
These are some of the testing steps that are typically present only when a dot/patch is being released, and it is necessary that the testing happens on the various operating systems that are supported for the product, especially since the installation of the patch/dot is the first sequence in front of the client, and if any problem happens in that area, the initial impression is not good. Secondly, on various Microsoft Operating Systems, there can be certain supporting files such as MVCRT, or other system dll’s that get modified from different OS’s, and there may be functionality in the patch to behave differently on different OS’s.
Further, if you consider OS’s such as Microsoft XP (still used by many users who did not trust Vista) or Vista and onwards, there were differences related to the User Access Control (the dialog that pops up which asks you to use administrator rights to install an application), and these need to be thoroughly verified.
The only compromise that can happen in the area of installation testing is about not doing it on the different languages supported by the application, with the optimization related to using one Operating System on one language, and another on a different language. This helps save some effort, but there needs to be an analysis that whatever be the changes in the dot/patch, there is no feature impact on the installer side.
In this post, I have been talking about some of the really required test cases that come up due to the needs of the installer. In the next post, will talk about the application side test cases.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>