You’re a software development leader who takes managing an application lifecycle seriously. You’ve spent time installing, configuring and training your team in tools for software version control such as Subversion or Git; bug tracking tools such as Bugzilla or Trac, and all your documentation is stored in a central repository (such as CogniDox).
That still leaves a gap in the methodology if your project information ends up in separate silos – one for problems in software; one for problems in documentation. It happens one day that your QA tester logs a bug against a software program, but fixing it changes something in the design specification. The next day, your UX advisor asks for alteration in a user interface screen that causes a change to your user manuals.
One of the most widely-used bug tracking tools in software engineering is Bugzilla. It’s been downloadable for free since 1998 and on February 15th 2011 Bugzilla 4.0 was launched to the world. It was as good a reason as any for us to increase integration with this popular FOSS project, which is used in around 1 in every 6 software projects on the planet. It's now a feature that will be included in our forthcoming CogniDox 8.5 release.
We extended Bugzilla by providing a CogniDox connector add-on that uses custom fields for additional Bugzilla functionality. Our add-on does the part number to title mapping in the bug view. That enables us to log in each bug report any affected documents or related documents in CogniDox. When software such as Bugzilla provides open data, the flexibility of the CogniDox plug-in architecture makes it easy to integrate.
It’s a good start – it allows you to log more information about the problem at the point of discovery when you are creating the bug report.
It gets more useful however when you use CogniDox as a software release manager. You start by configuring the CogniDox Bugzilla plug-in via the plug-in manager so that it points to the Bugzilla system and uses your user credentials to authenticate you. From here on, any time you look at the document details page for an affected document, you can instantly see whether there are any open bugs.
You can use the CogniDox search engine to show you any documents with open Bugzilla bugs and you can store the results of that search in a spreadsheet format if desired.
This can be taken one step further. A popular way for describing a software release in CogniDox is to create a document holder. This is a container document that encapsulates what other documents/content are needed for a specific product release.
If we have a document holder for CogniDox version 8.5.0, for example, we can list in there the full set of components that we need to have to make a successful release. We’ve shown how tracking documents from Draft to Issue to Approved is an indicator that the project is reaching the required QA level.
One thing we can do is specify that bugs logged in Bugzilla are now also included in that report. From a document holder details page, click view related documents and then choose the spreadsheet link. A list of all the contained documents will appear in the report with their open bugs.
Simple but effective.