Blog Home

If we look at defects as catalysts for process improvement, we can see how something as frustrating and annoying as defects can actually have value. I am certainly not proposing a lax attitude toward defects. They cost money, delay projects, and even place lives at risk in some cases. However, since each defect does cost money and time, let's learn the most we can about defects so we can prevent them or at least find them earlier in the software development process.

When assessing the success and value of a software product, one metric frequently measured is adoption. In other words, how many people are using or engaging with the product/technology? For example, one measure of adoption is the number of people using it. Sometimes, this gets reported by age group, country, etc.

 It’s easy to misinterpret adoption with acceptance. People may be using something, but only because they are forced to, as in the case of enterprise applications.

There is a line that exists not only in software, but also in other domains such as writing, music, and movies, just to name a few. That line is the release point of whatever is being built. Before the release point, there is an opportunity to find and fix defects before the intended audience experiences them. In pre-release, testing is possible.

There are many ways to approach test design. These approaches range from checklists to very precise algorithms in which test conditions are combined to achieve the most efficiency in testing.

There are situations, such as in testing mobile