Learn Software Development » Defect

Bug ageing – why it is important to follow in a software project – Part 3

ashish — Sun, 08 Jan 2012 19:20:32 +0000

In the previous 2 instances of this post (Bug ageing and software processes), I have been talking about the need to measure how much time it takes for the bugs generated by the QE team to get fixed, and to see whether taking more time for fixing such bugs is seen as a problem. In almost every case, you need to ensure that these bugs get fixed within a definite period of time and not keep on lingering on.
One of the important questions is about how soon bugs should be fixed and not kept hanging. It is not easy for a group to define the time period within which bugs should be fixed, and not kept pending. I have tried that, asking a group of development and quality mangers to agree to a time period in which bugs should be fixed (or a bug that is not fixed after say 120 days should be escalated to a bug review team); and there was no agreement even after several rounds of discussion. In the end, there was a proposal that just took an average of the different proposals and we agreed to monitor statistics related to bugs.
What came out very critically from this entire discussion was several points that I will layout in this ongoing discussion:
- It is important to differentiate between bugs depending on their severity. So, a bug that is of higher severity or priority (say an application crash or some problem that related to data loss / corruption) needed to be fixed much earlier than a bug that had a small problem which a user may or may not ever face. Set different standards for these different types of bugs; and trust me, the team will totally agree to the logic (if you don’t do it this way, they will get totally confused about how different bugs whose critically are so different are treated the same).
- Do an analysis of bugs where the age of the bug is higher, and whether those bugs were actually fixed or had to be withdrawn. Our statistic showed us that when a bug is not fixed within a short number of days after being created, then the chances of the bug never being fixed are also higher. This also goes back to the previous post where I outlined some problems in terms of reproducing bugs when the bug has been open for a longer period of time. Do this analysis on your own project, and you might be able to see this pattern (and should worry you, since that means that there are critical bugs that you could have got fixed, but were never fixed).

Contd.. in the next post …

Bug ageing – why it is important to follow in a software project – Part 2

ashish — Wed, 04 Jan 2012 14:56:58 +0000

In the previous post (Bug ageing and software projects), I talked about the concept of bug ageing and why it is important. In this post, I will continue on that topic and write more about this area.
One of the biggest problems with bug ageing is that the more time there is between when a bug gets filed and when it finally gets seen, the sequence of steps gets lost. I have seen people insisting that if you document all the steps that you take while filing a bug, you will be able to reproduce the bug. Hogwash. This may not work in every scenario. For example, when somebody is writing the steps for a complicated crasher bug that happens once in a while, there are a number of factors at work that could have caused the crash in the application. It is only the perfect person who is able to reproduce all the twists and turns that they took which caused the crash. Suppose you have an application that allows you to add text, images and sounds while creating a greeting card, a crash that I have seen came during a specific situation when a sound was added, then a video, then text, then the sound was changed, and the text was modified. Now, when you increase the number of steps, it is going to be harder to reproduce such a crash, especially when you are called upon to do so many weeks later. As a result, we set the condition that all crashes need to be looked at within 48 hours of the crash being reported, so that we don’t lose it. The tendency is simple to let the crash go out, since it came in a complicated scenario; but guess what, with so many people coming online to express their opinions, things get very complicated. For a crash, which seemed a low scenario, we had a user lose around 1 hour of effort, and the amount of feedback in user forums was incredible to see; and we use that scenario as an education to people about how not to let such significant items such as crashes go by.
The other major problem with taking time to resolve a bug is due to environmental factors. Suppose a crash is reported, and part of the problem is the interaction of some components on the machine of the tester with some components inside the application. Over a period of time, with system updates, other applications getting modified, or other environmental conditions, this crash or bug is not longer visible. The developer does not have a reproducible scenario, but has to fix and resolve issues. In this case, most of the time, eventually the bug is let go as not reproducible, and we end up with a possible user crash scenario that we could have fixed, but were not able to find because the base environmental factors changed in the meantime. All of these end up with some costs that we have to pay later.

Bug ageing – why it is important to follow in a software project

ashish — Mon, 19 Dec 2011 11:58:24 +0000

First of all, what is bug ageing ? Well, in a very broad sense, bug ageing is the amount of time that a bug is with a certain person. A bug can follow many different paths during its history – the bug can be with a developer, pending for the bug to be fixed. The bug can be with the tester, pending some information to be provided to the developer or when the bug is marked fixed, or the bug can be with management, where they weigh the cost vs. benefits of the bug and decide on a future course of action. In a typical scenario, all these bug actions happen within a short period of time and the bug is resolved (fixed, deferred, or withdrawn) with a short period of time.
However, there are numerous cases where the bug is not fixed quickly. There can be multiple reasons for the same:
- The bug is with the developer, but the developer has a large number of bugs on their plate and hence is not able to give this specific bug the priority that it deserves
- The developer has been told to focus on a specific product area and hence is not able to focus on bugs from other areas, and hence these bugs remain unattended for some time
- The bug is marked in an area which is going to be handled at a future part of the schedule and hence the bug is marked to be fixed when attention is provided to the area further on in the schedule
- The developer wants to get the number of bugs on their plate down, and hence focuses on the bugs that are easier to fix, and tougher bugs have to wait for more time before they are given attention
- It is not easy to recreate the conditions in which the QE found the bug, and hence the developer, showing signs of inertia, is waiting and will push the bug fix when he / she had more time

Similarly, the QE could be having a number of reasons for delaying the bug fix. Some of these are:
- The QE is very busy in testing a specific area of the product, and is not able to spend time on the specific bug
- The bug may have been filed by somebody else, but is assigned to a specific QE because that is their area. As a result, the QE is not very enthused about the bug (no ownership feeling over the bug)
- The QE has a large number of bugs, and the scenario to resolve this bug means using a much older build (and installing the latest build and removing a later build takes time (with larger applications, this could mean as much as 1-2 hours just to install a build)); hence there is inertia in going ahead in recreating the bug

In all such cases, when bugs wait a large amount of time to get resolved, there is a pending time bug. One of the biggest problems in older bugs is that, when a bug would have been filed many months ago, the dev or QE lose track of the scenario in which the bug was filed (even though the steps would have been written down) and find it harder to replicate the bug as time increases.
I will write more about this case in the next post ..

Designing of Multimedia Databases

ashish — Fri, 14 Aug 2009 17:30:07 +0000

Many inherent characteristics of multimedia data have direct and indirect impacts on the design of multimedia databases. These include : the huge size of MMDBs, temporal nature, richness of content, complexity of representation and subjective interpretation. The major challenges in designing multimedia databases arise from several requirements they need to satisfy such as the following:
- Manage different types of input, output, and storage devices.
- Handle a variety of data compression and storage formats.
- Support different computing platforms and operating systems.
- Integrate different data models.
- Offer a variety of user-friendly query systems suited to different kinds of media.
- Handle different kinds of indices.
- Develop measures of data similarity that correspond well with perceptual similarity.
- Provide transparent view of geographically distributed data.
- Adhere to real-time constraints for the transmission of media data.
- Synchronize different media types while presenting to user.

DIFFICULTIES INVOLVED WITH MULTIMEDIA DATABASES :
The difficulty of making these different types of multimedia databases readily accessible to humans is:
- The tremendous amount of bandwidth they consume.
- Creating Globally-accepted data-handling platforms, such as Joomla, and the special considerations that these new multimedia database structures require.
- Creating a Globally-accepted operating system, including applicable storage and resource management programs need to accommodate the vast Global multimedia information hunger.
- Multimedia databases need to take into accommodate various human interfaces to handle 3D-interactive objects, in an logically-perceived manner.
- Accommodating the vast resources required to utilize artificial intelligence to it’s fullest potential- including computer sight and sound analysis methods.
- The historic relational databases do not conveniently support content-based searches for multimedia content.

Multimedia databases are essential for efficient management and effective use of huge amounts of data. The diversity of applications using multimedia data, the rapidly changing technology, and the inherent complexities in the semantic representation, interpretation and comparison for similarity pose many challenges. MMDBs are still in their infancy.

What to do when there is not enough time for thorough testing ?

ashish — Fri, 09 Jan 2009 12:11:58 +0000

What if there isn’t enough time for thorough testing? The first answer (and applicable in a world that is more ideal) is to not be in such a situation. If you are releasing a software that is not thoroughly tested, then you are potentially sitting on dangerous ground, not knowing when and where the software could fail. However, there are cases when you are not able to spend as much time as you would like in testing the application. The rest of the article is about getting the right questions to answer if you need to determine what you should do when there is not enough time for thorough testing.
Use risk analysis to determine where testing should be focused. If the failure in a specific area could lead to a higher impact, then testing that area becomes more important.
In an ideal world, you have the time and ability to test every possible aspect of an application, every possible combination of events, every dependency, or everything that could go wrong, but in a ream world, there are constraints. Given this, risk analysis is appropriate to most software development projects. Risk analysis however is not so simple, and is a specialist field by itself requiring judgement skills, common sense, and experience. (There are training courses and other formal mechanisms that can train people to become more knowledgable in the area of risk analysis). Some of the factors or considerations that are useful when trying to estimate the procedure when you do not have enough time for thorough testing:
• Figuring out which functionality is most important to the project’s intended purpose? This is a business decision and would need consulting from business analysts.
• Which functionality is most visible to the user? Users tend to be more concerned about things they can see, and those should seem to work perfectly.
• Which functionality has the largest safety impact? In this world, with legal worries about impact of software, it is helpful to make sure that areas of the application that can impact safety (human, structure, financial information) need to be tested in more detail.
• Which functionality has the largest financial impact on users? Users get real worried if their is a perception that a software flaw can have a financial effect.
• Which aspects of the application are most important to the customer? From the above points, it should be more clear as to which are the points that a tester should focus on, things that matter to consumers.
• Which aspects of the application can be tested early in the development cycle? In any development cycle, there will be parts that will be developed first, and there will be parts that will be developed later on in the development cycle. It is necessary to understand which are the items that will be available early.
• Which parts of the code are most complex, and thus most subject to errors? A part of any design and development process is the estimation of which workflows and areas of code are complex, where there is a greater chance of errors.
• Which parts of the application were developed in rush or panic mode? This is not a scenario that most people would like to see, but in rushed projects, there are parts which are developed faster (could be parts that are developed near milestones, could be components that are based on existing code and where there is a perception that this area need not have much focus).
• Which aspects of similar/related previous projects caused problems? Heuristics is a big help. Working on the basis of previous cycles and evaluating problems that came in similar situations gives a good overall pointer.
• Which aspects of similar/related previous projects had large maintenance expenses? There are many projects which are in maintenance mode, and for which there will be a large amount of data regarding problems that have cropped up, and error prone zones of the application.
• Which parts of the requirements and design are unclear or poorly thought out? Such a situation is more difficult to evaluate; the common thought in such cases is to deny that any implementation has not been well thought out, and so on. One needs to probe much deeper to find answers.
• What do the developers think are the highest-risk aspects of the application? Typically, the people who have actually developed the application are the ones who have the greatest idea about which area of the application is the most risk-prone. The dev and QE need to spend time in discussion so as to make sure that the most risky parts of the application are identified and tested.
• What kind of problems would cause the worst publicity? This is a difficult area. A part of the application that prints names improperly could be a trivial task, but could cause the application to become a laughing stock.
• What kinds of problems would cause the most customer service complaints? Customer service complaints cost money due to the need to have an active customer service, and can quickly eat away into revenue.
• What kinds of tests could easily cover multiple functionalities? Such a situation is most welcome. If tests can be tweaked in a way that the same test or series of tests can help in the testing of multiple areas of the application, that is great.

If you can add to this article, please add a comment.