Software quality defects are an inconvenience that can stop a project in its tracks, but who should be responsible for managing them? Who should rectify the errors caused by the defect? And who should document the details of the process? Every software quality analyst and software tester should be prepared to answer these questions long before beginning a project.
In industry, the department responsible for managing and documenting software defects is often the same department that is charged with implementing the solution. The owner of the defect should not simultaneously delegate the solution because it can be difficult for defect owners to look at the issue objectively. It is therefore necessary to have a streamlined process for defect management – particularly when working with large, geographically dispersed teams. Insufficient planning may lead to poor communication, thereby creating confusion as to who, specifically, is supposed to monitor the defect (i.e., who should document and resolve the issue). I believe it is easy to manage this process in small companies or departments because of direct-access to the right people. But in a large enterprise organization, the right resources tend to be stretched over a multitude of platforms, and sometimes several time-zones. Therefore, the resolution strategy must be centrally managed by a process and a tool.
One way to overcome the challenges of software defect tracking is to assign each department a specific role or task. Ideally, the owner of the tool should be the software testing and software quality group. Then, a triage group or process needs to be conducted to document each new defect, along with the mitigation strategy for each defect and an owner to whom the defect is assigned. It is also very important to ensure that the correct process is implemented and used by a governance department. In large organizations, governance may be an independently-operated entity, whereas in small- to mid-size companies, the governance role may be wrapped into the software testing and the software quality department. Both departments should be able to clearly answer the following questions without stepping on each other's toes:
- Who is allowed to report a defect?
- Who should the defect be assigned to?
- How will the defect be documented, and details changed, over time?
- How will the status of the defect be managed? (i.e., New>Open>Fixed>Closed)
- Will the defects be managed by a specific defect-management tool?
- Will the defects be automatically e-mailed to the appropriate people who will manage them?
- Will reporting be conducted to assess the project's current status and its future progress?
- Who should work on each defect, and which defect is the most severe, thus warranting it a "high-priority?"
Once someone or a group of people is assigned with a strategy and documentation, the next step to address is how the defects will be communicated among personnel across the organization. There are many ways to accomplish this – a simple e-mail outlining the defects as they are found, holding regularly scheduled meetings, or drawing up a detailed hardcopy report of all errors and distributing it to the team. In many cases, the tool used for defect tracking will include notification options. All communication must inform software quality analysts, software testers, business analysts, the development/architecture groups, change and configuration management, the infrastructure group, project managers, and ultimately senior management. In other words, all of those essential departments that make up the end product or service within software development must be informed.
In some organizations, the best way to reach everyone is to hold meetings on a regular basis. The "owner" of the tool (who, again, should be the manager of software quality assurance and software testing) should be the ambassador of the meeting, offer a summary of progress made so far, and make some decisions about what needs to happen next. Using a visual of the defect repository tool on a projector screen, the owner should be able to facilitate active discussion among the group, thereby addressing the severity and status of high-priority tasks and managing the changes that need to be made. Large meetings may not work as well at some companies as they do at others (i.e., if e-mail conversation is typically the norm instead of face-to-face chat around the water cooler, a meeting may just take up unnecessary time), so the employee culture should be taken into consideration when deciding how to communicate defects.
If it is decided that the changes are especially severe and will require a lot of work, the Change Control Board (CCB) must be notified. The CCB is a group of representatives from nearly every department in the company. Some businesses create a CCB after a formalized process for software defect management is put into place. After the CCB accepts the changes, the decision is escalated to senior management for final approval and then carried out by the CCB through the Software Quality Assurance department.
In closing, a well-documented, communicated and agreed-upon defect management process is essential to have in place before a software project has begun. The software quality assurance team should be in charge of the project as a gentle guiding hand, all the while keeping governance and other departments that are part of the software development life cycle (SDLC) as informed as possible. Both the software quality analyst and software testing roles are often thought of as nothing more than "bug finders." But the truth is, they maintain the integrity of the vital software products and services, so many individuals and even entire organizations depend on in order to function.
About the author: John Scarpino is director of quality assurance and a university instructor in Pittsburgh. You may contact him at Scarpino@RMU.edu.
Learn how the Bugzilla tool helps DevOps