quality assurance
Articles
|
Quality: What a Fuzzy Term Most people in the software field don't seem to understand even the basics of what software quality means, even those who are labeled as quality "experts." They see it as being error free, satisfying users, meeting requirements, or hitting cost or schedule targets. But in reality, it's only partly about some of those things, and not at all about others. In this column, I try to set those erroneous viewpoints aright. |
Robert L. Glass
March 28, 2001 |
|
|
Snaring Black Widows in Ladybug Clothing The mood in the meeting was grim. All eyes were trained on Doris, the head of customer support. Doris surveyed the room as she spoke..."We have a problem in the field with the new release. Sixty-three users reported unrecoverable errors this week—a record high. An additional 152 people reported crashes, but the software recovered after reboot. This morning, I talked to an irate user who said he'd uninstalled our software after it crashed on him five times in a row. He wanted us to give him a full refund plus expenses. In short, the users are really angry. What do I tell them? When will we have a fix?" |
||
|
Looking for What's Not There This column asks the all-important question, "What isn't there that should be?" The same idea for spotting black holes also applies to spotting "holes in designs and requirements." For example, there are often connections between the quantity of bugs filed against an area and whether the area is thoroughly tested. There can also be holes in what KIND of bugs have been reported. Hendrickson lays out the territory for the search and goes on to suggest how to "look for where there's a lot of nothing." |
||
|
Who Is the User Anyway? "Users have rights!" But which user? And what rights? Clare-Marie Karat's User's Bill of Rights is based on the concept that the user is always right. But who is the user? Companies that make and sell commercial software spend lots of thought and money on just this issue. All users are not the same and they have different needs. So who decides which user needs to satisfy? |
||
|
Counting Defects Defect counts are often considered as measurements of product quality. However, the most important defect count in that respect is by definition unknown; the number of undiscovered errors. Defect counts can be used as indicators of process quality. In doing so, one should avoid assuming simple causal relations. Defect counts can provide useful information but have to be presented with care. |
||
|
The Open Source Test Tool Paradigm Testing is often seen as an effort to determine the quality of the product at the end of a project, so it needs to be executed when development has finished instead of being a means to deal with risks at the earliest stage possible. Therefore, project budget, is in most cases spent on the processes that actually produce tangible products, at the expense of the testing budget. Whatever budget is left for testing will be spent on people rather than on test tools, especially since most of the mainstream tools are often perceived to be too expensive. A solution to this may be found in the use of open source test tools. With no license fees, the use of open source tools can provide a customer some of the benefits of test automation, without the costs. |
||
|
Defect Depletion and Cost Analysis (template) You can use this spreadsheet to demonstrate the value of early defect removal. It includes defect depletion curves or phase containment effectiveness calculations. |
Pages
Recommended Web Seminars
Featured Resources
Visit Our Other Communities
StickyMinds is a TechWell community.
Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.