Home Library Translate
A A A
Share »
Follow us on Facebook Follow us on Twitter Follow us on LinkedIn
Connect »

Blog: Business Communications

Menu

  • This Blog's Home
  • Guest Writer Submissions
  • Policies
  • To Subscribe to a Blog
  • About
  • Feedback

What is a Bug List?

By Theresa Pojuner on February 20, 2012

When problems are encountered during the testing phase of a product or application, they have to be noted so that the problem can be corrected or prevented before the next testing phase. These problems have to be noted within a form known as a List of Errors form or a Problem and Resolution form or an Incident form. For us right now, we’ll simply call it a Bug List.   Any irregularities or anomalies noted within the Bug List will be passed to the development group, who will resolve the problem.

The Bug List should contain at least 5 columns.  The column headings should be listed accordingly: ‘Date Bug Found’, ‘Description of Bug, ‘Resolution’, ‘Date Bug Closed ‘, and ‘Comments’. The tester will describe in extreme detail the exact steps that led up to the occurrence within the ‘Description of Bug ‘column.  This part of the form is crucial for replicating an error. Without it, the developer will not be able to duplicate the error and hence correct it.

For finding bugs (problems), every test plan has to be extremely detailed and every test scenario listed. Yes, there will be times when not every case/scenario is noted. If the tester does create a unique case, this case should be noted within the bug list. This way, when the application/product goes into the next testing phase, this new test case will be added to the test plan, as well as tested.

When testing is completed, the list will be directed to the appropriate developer and Project manager involved. Every bug found should be corrected, but then there are various grades of bugs. There are quick fixes, such as spelling errors, simple fixes which involve minor programming, i.e., a value was to be added and wasn’t, medium sized fixes which take a few hours when a functionally will not work under certain conditions, serious ones which require rework, and red flag ones where the applications/product seizes to work. Depending on time constraints, the more serious ones  (red) will be corrected first. Then when time allows the minor ones will finally be corrected.

Once the problem is corrected by the developer and the fix is inserted into the ‘Resolution’ column, the tester will be informed. The tester will then perform regression testing where the tester tries to recreate the error. Once the tester is satisfied that the issue is resolved, a date for closing the bug can be inserted within the ‘Date bug closed’ column, and any pertinent comments needed can be added to the ‘Comments’ column.

For more complicated testing, there are now programs that will perform automatic testing when needed for direct testing and for regression testing.  These new applications are really helpful especially when repeated tests need to be done. To help you keep track of all the bugs, there are also programs out there now that will assist you in keeping track of all bugs.  These tracking programs are very useful, especially when a Quality Assurance Manager needs to be on top of all Red flagged issues.

This part of the Testing phase, where time is spent on creating the Bug list, has to be taken into consideration when scheduling time within the project plan. The same goes for adding in time for correcting problems and regression testing. Without the project plan, we would not be aware of our time line or different events that have to occur from a product or applications initiation or start to its completion. But to get back to the Bug list, without it, we would not be able to communicate and keep track of all these problematic issues that need to be resolved.

« Previous Next »

Search Our Site

Meet This Blog’s Host

Gail Zack Anderson, President of Applause, Inc., has nearly 20 years experience in training and coaching. She provides individual presentation coaching, and leads effective presentation workshops and effective trainer workshops. [Read more ...]


Theresa Pojuner is a Documentation Specialist with over 20 years of writing experience and is skilled in many areas of documentation, for example, Style Guides, Training Manuals and Test Cases, wth a specialty n Technical Writing and Procedures. [Read more ...]

Recent Blog Posts
Alternate Recent Posts Widget

  • Becoming A Technical Writer-Communicator Review
  • Creating A Knowledge Community
  • Tips for Handling Technical Writer Stress
  • Likeminded Communication
  • A Technical Writer Is Different From Other Writers
  • Involve and Engage Your Audience 20 Ways
  • Tips On Documenting Processes
  • Communicating Technical Writing Review
  • Communicating Via Visual Designs
  • Special Tips for Laptop Presentations

Related Library Topics

  • Body Language
  • Netiquette

Categories of Posts

  • Basics and Overviews
  • Body Language
  • Communicating Change
  • Communication Best Practices
  • Feedback (Sharing)
  • Humor in speaking
  • images
  • Listening
  • Netiquette
  • Presenting
  • slide shows
  • Speaking Skills
  • Team Presentations
  • technical writing
  • Telephone Skills
  • Uncategorized
  • Visual Aids
  • Voice and Vocal Habits
  • Writing

Library's Blogs

  • Boards of Directors
  • Building a Business
  • Business Communications
  • Business Ethics, Culture and Performance
  • Business Planning
  • Career Management
  • Coaching and Action Learning
  • Consulting and Organizational Development
  • Crisis Management
  • Customer Service
  • Facilitation
  • Free Management Library Blogs
  • Fundraising for Nonprofits
  • Human Resources
  • Leadership
  • Marketing and Social Media
  • Nonprofit Capacity Building
  • Project Management
  • Quality Management
  • Social Enterprise
  • Spirituality
  • Strategic Planning
  • Supervision
  • Team Building and Performance
  • Training and Development
About Feedback Legal Privacy Policy Contact Us
Free Management Library, © Copyright Authenticity Consulting, LLC ®; All rights reserved.
  • Graphics by Wylde Hare LLC
  • Website maintained by Caitlin Cahill

By continuing to use this site, you agree to our Privacy Policy.X