Pages

Tuesday, September 16, 2014

Defect management – Track and Trace Defects with MANTIS

Defect management is all about controlling bug life cycle using a defect tracker. You can find many open source and commercial defect tracking tools such as Mantis, Bugzilla, Trac, Flyspray, JIRA... etc. By this post I wish to discuss about famous open source bug tracking system – MANTIS.






What is Bug life cycle?

Defect in a software product is passing several stages in it’s lifetime.
  • New
  • Assign
  • Open
  • Reopen
  • Verified
  • Rejected
  • Deferred
       Defect tracking system helps to track and control changes in these stages.
Why MANTIS?

Mantis is one of the best open source bug tracking tool which has heavy usage around the world. It is light, fast, providing descriptive reports and easy to use. It has email notification support too. Also you can manage users, projects, tags, custom fields, global profiles, plugins and configurations.
Mantis Bug Tracking project was started way back in 2000. After 6 years Version 1.0.0 was released. In November 2008, project was switched from SVN to Git revision control tool. In July 2012, the MantisBT organization on GitHub became the official repository for the Project's source code. By today, the stable mantis version is 1.2.17.


There are four easy steps to install MANTIS in a windows server
           
1) Install xampp or wamp (apache, mysql, PHP package) - http://www.wampserver.com/en/
      2) Download the latest stable version of MANTIS - https://www.mantisbt.org/download.php
      3) Extract mantis to wamp project location (example - C:\wamp\www\)
4) Browse the project from your web browser (example - http://<ip>/mantis) and follow the installation instructions.



Defect reporting Tips and Tricks

  • Check the project and version before you report a defect in MANTIS.
  • There are few common fields in any defect tracking system. Study the characteristics of these fields.
    • Bug Category or Issue Type (Defect/Feature Change Request/ Improvement)
    • Severity (Critical/ Major/ Medium/ Low)
    • Priority (Urgent/ High/ Medium/ Low)
    • Assignee
    • Summary
    • Description
    • Steps To Reproduce
    • File uploader
  • Severity and Priority - Identifying Severity and Priority is the fundamental objective when you reporting a defect. Severity describes the impact of system functionality while Priority describes the urgency of getting fixed. Let me show you an example:
    • If user cannot login to the system, it is a High Priority & High Severity defect.
    • If a project title or heading text is misspelled, it will be a High Priority & Low Severity defect.
    • If some link of function is not working which is rarely use by users in the system, that should be logged as a High Severity & Low Priority defect.
    •  If a misspelled text appears in a page which is rarely use by users in the system, that is a Low Priority and Low Severity defect.
I can see few Common mistakes which QA engineers normally make. Make sure you are not among those people.
  • Not providing enough details about actual result (not mentioning error log, not attaching screen shots)
  • Not providing reproducing steps, locations and URLs.
  • Not providing expected results
  • Not providing the environment (OS & browser version) which the issue occurred.
{ Read More }


Blogger news

Blogroll

What's Hot