Project ManagementSoftware DevelopmentTechnologyWhitepapers

Software Defect Management

Mantis Online
Software Development Stages

Software development can be a very complex and overwhelming task that requires good organization and management.

Software development traditional progresses through all of the following stages:

  1. Requirements Gathering.
  2. Architectural Design.
  3. Development.
  4. Testing.
  5. Deployment.
  6. Maintenance.

In a perfect world, software development would be a very simple process. Software development would progress through each stage of the development cycle once and would be complete. In the real world, software applications with have defects, and the more complex the software, the more likely it will be to have defects.

Software Defect Origins

But what are defects and where do they come from?

Anything that is wrong with the application, whether it is something that causes the application to crash or not perform as expected is considered a defect. When the application does not meet the requirements, or it does not perform as expected by the customer, it has defects. When the application does not look good to the customer, or it does not “feel” right, it has defects.

Defects are not always coding mistakes done by the developers. Defects can originate from any stage in the software development cycle, because every stage involves people.

In the requirements stage, when communicating with the customer, there is ample room for errors. The customer’s needs may be misunderstood or misinterpreted, the customer may miscommunicate their needs, and even the requirements as written may introduce errors. Errors during this software development phase can be from either commission or omission.

In the architectural design stage, an inexperienced designer can always cause problems later on. Making the wrong choices for the architecture of the application or certain components, designing the wrong functionality, or lack of functionality, and overlooking component relationship and interfacing can spell trouble later in the development process.

The development stage is probably responsible for most of the defects in all applications. This is where software developers communicate with the computer. They have to translate the design document into code, they have to come up with algorithms, and even the simple task of editing a source code module by typing text in a software development language on the computer can cause errors. And these usually include the hardest defects to find and fix.

Software developers themselves are responsible for performing unit level testing on the software they development, but may be too time pressed from scheduling deadlines to spend adequate time to create and test all of the various boundary conditions. Similarly, software developers may also lack the ability to test out a broad range of test conditions, lacking either software or hardware from other team members or customers to be able to comprehensively unit test their software.

The testing stage is where most defects are found — but some defects can be introduced here as well. Testers usually take the requirements and write test cases against them, create testing scripts, and use automated testing software. Any of these actions can cause errors in the testing process. These may not necessarily cause defects in the application itself, but they certainly affect the development cycle of the application. For smaller companies, it is not always possible to have an independent software quality assurance department, and in many cases, the software developers and program managers and other corporate entities provide software QA. Independence is not always achieved in this case because software developers often times test their own code beyond the unit test level and unintentionally follow particular test patterns that may not reveal hidden bugs.

The maintenance software phase may include any or all of the above stages, since it involves anything from fixing defects found by customers to adding new features to the application. Thus the cycle repeats itself.

Software Defect Tracking

What then can be done to reduce or eliminate software defects? Prevention would be the goal, but with software complexity at an ever growing rate, errors will still be made.

From our perspective, the most important thing left to do is to make sure that all software defects get addressed and fixed, that they get fixed on time and retested, so the project schedule doesn’t slip. Therefore it is imperative that all defects get recorded and tracked so that the team can be alerted of any issues and they can properly validate and address them.

A good defect management system is, therefore, a necessity for all non-trivial software development. The non-formalized poor man’s alternative is to typically use email and white boards and short-term memory — all of which can be lost.

Software Defect Tracking Essentials

For a software defect/bug tracking software it is essential to have:

  • Reporting facility – complete with fields that will let you provide information about the bug, environment, module, severity, screenshots etc.
  • Assigning – making the bug fix the responsibility to an individual or individuals.
  • Progressing through the life cycle stages – workflow.
  • History/work log/comments.
  • Reports – graphs or charts.
  • Storage and retrieval – every entity in a testing process need to be uniquely identifiable; the same rule applies to bugs too. So, a bug tracking tool must provide a way to have an ID, which can be used to store, retrieve (search) and organize bug information.
Software Defect Tracking Benefits

From our historical use of bug tracking/software defect management software, the following are some of the benefits:

  • Record Defects – a team must be able to, first and foremost, record all aspects of what constitutes a defect so that defects do not get lost or forgotten.
  • Monitoring trends can tell you a lot about your product and you can get a better idea of the state of your product.
  • Used for setting milestones and accepting feature requests.
  • Provides statistics such as find rates and fix rates.
  • Provides accountability, progress tracking, and automation.
  • Bucketing – which features are the buggiest and who’s writing the most bugs.
  • Estimation of when milestones will be hit based on bug slope.
  • Work Items and suggestions – this is a list of features or TODOs for future releases, not just bugs.
  • Allows viewing what’s being tested.
  • One source for all communication about bugs.
  • The ability to store automated bug reports and attach to a particular issue.
  • Allows for a shared sense of the product. Everyone can look at the software to understand how many bugs are left to fix.
  • People seeing issues can look to see if they have already been found.
  • A common source of bug data can make triaging the bugs as a group easier.
  • Bug tracking software allows people at all levels of the product (development, test, program/project management, corporate management) to see a common view of the world.
  • Checking the progress of your software – having a measurable way to decide the status of your software (e.g. an “alpha” release could have high priority bugs still open, a “beta” release only minor bugs open, and a ‘release candidate” having no reported bugs open).
  • Assignment of bugs to the appropriate developer/team/department.
  • List of fixed issues to perform regression testing against.
  • Historical data for tracking the comparing projects respective bug slopes.
Software Defect Management Systems

A good defect management system can really make a difference in the software development cycle. It can be the difference between developing a good or a great software application.

There are dozens of commercial and open source software defect management products available that meet the basic requirements. There are multiple web sites that rank bug tracking software based on both essential and optional features.

As strong open source advocates, we have traditionally used either web-based open source BugZilla or MantisBT for bug tracking. Historically, this required us to dedicate a workstation to be the bug tracking defect server, usually Linux based. For this server to be externally accessible through the Internet to allow developers access from outside of the corporate network, secure access via VPN and a static IP was generally necessary.

Software Defect Management Cloud Based Solution

The modern trend in computer software it to use web accessible hosted versions of applications, whether it is online image editors, image/CSS/JS compressors, source code/XML/HTML formatters, spreadsheets, word processors, etc.

This trend applies as well to bug tracking software, where an alternative to dedicating a corporate resource is to use a hosted bug tracking provider for web-based bug tracking. Using the service provider model frees a company from having to budget, setup, and maintain an internal resource and expose the bug tracker for external access. External access becomes an essential tool when software developments occur between two or more companies where all companies need common access or to support access to remote developers.

We are currently working with a customer and utilize the MantisHub online bug tracker to collaborate and manage a software development project. MantisHub is a web hosted version of the MantisBT bug tracker. This has proven to be a very easy way to track, manage and collaborate on a software development project using a “cloud” based software defect management solution.