| |
| |
See Also
Keeping a database of bugs is one of the
hallmarks of a good software team. More...
How well you report a bug directly affects how likely the programmer is to fix it. More...
To have some
commonality between
assigning bugs priorities, use the following guidelines. More...
Top 10 Signs that You Need a New Defect Tracker. More…
|
|
|
| |
More Resources
What are some recent major computer system failures
caused by software bugs? More...
Software Cost Estimation
continues to be a weak link in software project management. More...
Software Quality
Assurance & Usability
Testing. More...
A checklist to help testers check GUI screens. More...
|
|
|
| |
Have Something
to Share
software testing tip, interesting bug, or had an
interview lately?
Send us an Email.
|
|
|
| |
Promote Your
Products or Services
Interested in promoting your products on
SQAtester.com?
If so, we think you'll like
our Product Storefront Program.
The concept is simple.
More...
|
|
|
| |
Learn more material at a Fraction
of Price!
Get the training that will help you face the challenges
and meet the demands of today's competitive market place.
Programs
Offered: Oracle DBA, Cisco Networking,
Software Testing & Programming. More...
|
|
|
| |
To compete in today's market, you need Access to your Information Quickly and without hassle.
We can make this possible.
FREE 2 week trial
|
|
|
|
|
|
One of our SQAtester.com contributors offers
this account of his experiences in defect and test case management
|
| One Bug or Many? |
 |
_____________________________________ |
|
by Michael Stebbins Sesame Technology
When One Defect Covers Multiple
Configurations
Recently, I have worked with some
top-notch quality departments who organize each tester to be responsible for a specific area of functionality -
regardless of platform, version, or release. Certainly this focused expertise yields higher quality testing, but
a logistical problem arises when one defect covers many configurations. For example, a user interface issue may
occur in all UNIX versions of a product, or firmware problems may occur in multiple hardware modules. Does this
represent one bug, or many? One ticket or multiple tickets? Testers have approached this issue in several ways.
Many is Better Than Zero.
Some diligent testers take the time
to initiate multiple tickets: one for each configuration. After all, many is better than zero. Some department
would rather have testers take the time to enter multiple tickets that route to all the possible engineering groups.
Each ticket is closed when each configuration is checked in with a fix. However, after routing, each department
is often unaware of the other's work. I have seen this method cause separate engineering departments to create
duplicate fixes for the same problem. While thorough, this method is time consuming and raises the barrier to getting
accurate problem descriptions entered and resolved efficiently. Often, testers look for an easier way to log a
problem.
Is This You?
One way that testers reduce entry
and tracking overhead is to simply enter the problem once and, within the constructs of the tracking system, make
mention the multiple configurations in the notes. I have sometimes watched testers enter the problem description
and then cut and paste the content into an email that is sent to multiple engineering groups. Beyond resolution
and closure issues, the routing alone leaves much to be desired in terms of notification and proper assignment
to engineering for a fix.
How This Changed ExtraView
ExtraView employs MHR (Multiple Hierarchal
Relationships) technology to solve this problem. If you are already an ExtraView user, ask your administrator to
switch on the feature that allows you to track multiple modules or multiple releases within a single ticket (or
problem case). Each of the modules (or releases, etc.) will then automatically trigger their own notification and
closure process. This allows each module or release within a ticket to be tracked independently. When all modules
are closed, the ticket may be moved to closed status (or some other status depending on your custom workflow setup
and nomenclature). Metrics and reporting may be based on modules or simply include them in an overall report.
Regardless of what tracking system you use, the hierarchal method of entry of problems that relate to multiple
configurations appears to be the most efficient. This method will categorize defects into a clearer reporting structure.
Keeping the data entry barrier as low as possible will empower your quality team to focus on testing, and ultimately,
should result in a higher quality product.
Brought to you by ExtraView - the top performing bug tracking system
ExtraView information may be found at www.extraview.com
Michael Stebbins is a Strategic Technologist with Sesame Technology, www.sesame.com in Scotts Valley California. He may be reached at stebbins@sesame.com.
 Share your thoughts on One Bug or Many? in SQAtester Group.
 E-mail to a Friend.
|
| Books to Read |
|
________________________________________ |
|
|
|
Quality Web Systems
This book provides a framework for ensuring that key Web system success criteria are addressed during the development
of a Web system. Detailed technical guidance is provided for all criteria, along with testing strategies that allow
for verification of a quality implementation. More...
|
|
|
|
Automated Software Testing
Written for those with some background in software engineering, Automated Software Testing: Introduction, Management,
and Performance delivers a rigorous guide to the state of the art in managing automated testing in a text that
will benefit anyone who tests software for a living. More...
|
| Categories |
|
________________________________ |
| Community |
|
________________________________ |
| Specials |
|
__________________________________ |
| Millions of titles discounted up to 40-90% off. Great
low prices on your favorite books. More... |
|
Find all of your favorite software.
More... |
|
|
