How are the defects classified?

All defects are not the same type. Some defects may result in system crash. Some defects may be very minor. So, the defects need to be classified based on its impact on the functionality of the software. There are various ways in which we can classify.

Severity Wise

Major: A defect, which will cause an observable product failure or departure from requirements.
Minor: A defect that will not cause a failure in execution of the product.
Fatal: A defect that will cause the system to crash or close abruptly or effect other applications.

While recording the defects in a defect log sheet, the severity of the defects also needs to be noted. IF a critical defect is present in the code, then the software is not ready for delivery. Only a few major defects are allowed. Similarly, a threshold needs to be kept on the number of minor defects. As the threshold depends on the application, the project manager/test team member has to use the judgement in fixing the thresholds on major and minor defects. After analyzing the test report, the project manager needs to decide whether the software is ready for delivery or not.

Product Development - planning a minor / dot release - Challenges

In the last post, I had talked about why a minor (dot) release is needed, as well as some of the reasons as to why doing a dot release is an inconvenience. However, if the decision has been made to do a dot release, then it is necessary to understand the process of planning and executing a dot release, including some of the difficulties (challenges) that emerge in such a minor release.
What are some of the activities that need to be done ?
1. You need to finalize the changes that need to be a dot release. If this release is because of some known changes, then the changes need to be analysed, and the engineering response (and design) needs to be worked out.
2. If the changes are still unknown, for example, if your release is failing some security tests or some certification, then you need to figure out what can be done. If you take an example where the earlier release is failing some new certification norms (and for those who know how certification works, it can be a lot of effort to prepare the infrastructure and execute all the cases. As an example, you may need to take the help of tools for certification, and those tools may need an upgrade of memory. In other cases, the amount of testing required may be huge, and the actual calendar time needed may stretch the schedule of the dot release.
3. For companies where a lot of work is handled by support teams (configuration, build, release, internationalization, etc), the required overhead of handling all those teams and getting their support takes both budget allocation and time.
4. Too many minor releases causes cynicism in the market about the initial stability of the software release. For example, Microsoft releases many service packs for its software, and there are many people who do not migrate onto a newer version until they see 1 or 2 service packs because they would rather wait for some of the important bug fixes.
5. You run into issues where there are multiple releases for around the same version (with say versions 8.0, 8.1, 8.2, etc for a product). Once you have multiple versions, you get into support issues whereby issues are different for these versions, and support may be a nightmare.
6. Newer dot versions, in many cases need to be deployed to the retail channel (replacing the software already in the retail channel), and to the web store (including to many online software sellers who resell the software). All of these steps involve huge logistical nightmares and / or costs.
7. Branching strategies. Getting a dot (minor release) in process needs major configuration issues (getting branches in place, especially when work is also going for the next release), and takes a fair amount of explanation to both the Development and Quality teams.

Of course, if you folks can suggest more issues that make minor releases a challenge, please add comments.

Product Development - Doing a patcher or a minor release

When doing the planning for a new version of the product (not typically applicable when creating a new product), it sometimes becomes necessary to consider the case of doing a patcher or a minor release (also known as dot release).
Picture this scenario - your product development team has already started planning for the features that will be implemented in the new cycle. They are trying to get an initial SWAG (literally means a Wild Ass Guess, but is typically used to define when experienced development managers and engineers do a rough guess of the amount of resources it will take to develop a given feature), are working with Product Management and User Design to get some more details of the initial feature requirements such that a more accurate estimate (but still rough estimate) is available. In the middle of this, if they are suddenly confronted with the need to plan for doing a patch or a dot (minor) release, it can take away a fair number of resources and affect the schedule for the next version.
So why does a team end up doing a patch or a minor release (dot release) ? Let's talk about a patcher first.
Reasons for doing a patcher:
- Easiest reason. After releasing the product, you discover a bug (through internal testing or from customers) that is liable to affect a number of customers. So, suppose you are doing a printing application, and you find that printing of Excel documents does not happen properly in common cases, this is something that cause you to do a patch. There is a high priority that a number of customers will get affected by such a problem.
- Crashes. A slightly more difficult situation where a number of customers have reported problems where the application suddenly crashes. On diagnosis, you find the root cause of the problem and decide that the risk of customers getting the crash is not very low, or there is a high risk of important data loss when the crash does happen. This is very important for certain classes of applications such as financial and enterprise applications.
- Customer / Tech support issues. There are a variety of issues that are not important enough to warrant a patcher on their own, but together they are causing problems with a high frequency of customer support issues and tech forums posts. Because all of these have a cost (and a lowered reputation because of many customer posts on forums is not easy to recover from), it is sometimes important to admit that there were mistakes made and release a patch.
- Device dependencies. Support you are a maker of a photo software, and many new cameras are released (or you discover problems with some existing cameras), it is important to project an image that you are responsive to developments in your field and are providing updates to your customers.
- Adding some important new operational functionality. This is a slightly tricky area since the recommendation is not implement new functionality in a patch, but if you have some important new functionality that needs to be implemented in as many existing customer apps as possible, then this is something that seems permissible. For example, if you get a new component that allows you to provide customers with a new and easier update mechanism, it makes sense to provide such a functionality through a patch available for wide download and use
- Dependencies on other software. Nowadays most large software applications also internally use other software components. For example, video players will use external codecs, CD burning software will use device burning codecs from Nero or Sonic, and many other such examples. If you find that your dependency is going to cause problems unless you install a newer version of the external component, a simple way is to incorporate such changes in a patcher.
- Competition. Your competition is going to release a new version of their software that gives them a competitive advantage, and your development process means that you cannot release a new version quickly enough. A workaround is to make the changes in a patch and make that available to your customers.

This post is turning out to be longer than I thought, so the process for deploying patches as well as the development of minor releases will be covered in the next post ..