Jira and Quality Center notes

While it is difficult to locate full information about Quality Center [QC] on the web, it appears that the design of Quality Center and Jira are focused at different solving different problems.

• Quality Center's "Defect Tracking" subsystem is a minor feature of the product, and suffers in comparison to any modern issue tracking systems. The product's primary value lies in the test and scripting features [that can compensate from the decision made early in the UniWeb project planning to defer all test preparation and fixtures until after implementation was completed [contrasted with current development practice of tests first]]. The testing component seems focused on end user interaction, complete with capture and playback of user interaction [useful for regression testing, but not useful for testing libraries, components and services].

• Jira is an issue tracking system. Following current practice, automated unit and integration tests are the responsibility of a complementary 'continuous integration' build and test engine [e.g. Cruise Control, Team City, Bamboo.....].

Some organizations have found it useful to employ both systems, as there is little overlap in their use, and at least one product [Go2Group Jam Plugin ] exists to act a bidirectional bridge between them. [The free one-way version of this plugin may already be in place, as the example screen shots show a "Jira Defect #" field.]

The comparison chart may be incorrect about QC/TD as there is little information available on the internet. This relies on the online help system and basic experimentation.

comparison	Quality Center / Test Director	Jira
cost [enterprise system]	$$$$$$$ [not even implied on HP's web site, just requests for quotation]	$$ [no additional expense - all sunk cost]
cost per user	$$$	0 [unlimited users]
cost per project	unknown	0 [unlimited projects]
Hardened for public access	No [ActiveX client]	Yes  - J2EE web application
Client support	Windows Only [ActiveX]	Multiple [Any web browser, plus alternate clients for specialized applications]
Source code available	No	Yes [on distribution media]
Link issues to revision control commits of source files	No	Yes [multiple system support]
Integrates into development environments	No	Yes [Multiple IDE's supported]
Explicit issue linking	Yes	Yes, with configurable relationships [supersedes, prerequisite for, deploy with....]
Automatic issue hyperlinking	No	Yes - just placing an issue key in a text box creates a hyperlink.
Issues may have sub issues	Issues can be linked, but no explicit support for parent / child	Yes - A single reported problem may have multiple elements when the implementation is examined.
sub issues may be in different projects	No sub issues No cross project linkage only one project is visible at a time.	Yes - Documenting that a single reported issue may require multiple coordinated changes
Configurable workflows	Yes [VBScript]	Yes [Please note that the existing UniWeb workflows are far from optimal]
Threaded discussions in issue comments		Yes. Includes formatted text and Wiki style markup
Integrates with Wiki engine		Yes Confluence
User's dashboard has multiple projects	No dashboard available for feature comparison. Single project selected at login.	Yes [visible projects configurable] Project status is configurable, including time tracking, open and resolved issues, issues closed in past releases [release notes], issues targeted for future releases [roadmap], project home page. User status is configurable includes lists of unresolved assigned issues, user generated issues and watched issues.
Finding issues	Oddly enough, there is filtering but no search described in the online documentation. What appears to be shared search/filter configurations are in the 'Favorite' dropdown box. Text search is explicitly disabled in our installation. All filtered issues must be in the single visible project	Extensive search filters. Simple, range and boolean operator searches on all fields in the database. Searches can include multiple projects. Searches can be saved and shared. Search results can be exported as hyperlinks.
Screen capture	Including 'Movies' of user interaction leading to a failure [Windows only]	Simple image capture, relying on system clipboard [any platform]

Recommendations

Instead of migrating issue tracking wholesale to a system that is both less capable and more expensive, I would recommend:

• Retaining Jira as the primary issue tracking system for software development. The parent / child issue relations, along with tracking of related issues across projects and components is essential for our distributed architecture. During development and development testing, there will be issues encountered, logged, tracked and resolved without showing in Quality Center.
  
• Adding one of the Go2Group plugins to couple issue reporting from QC/TD to Jira
• Updating Jira to the current release [or at least the most recent on we have already paid for]
• Reviewing the Release Management workflow, including separating artifact releases and credential reset requests.
  
• Using QC/TD for it's proper role, for automated regression testing, script driven testing, reporting defects impacting the end user interface. Bugs can be reported in QC/TD but analyzed, tracked and resolved in Jira.

Collaboration Server proposal

The development team [e-commerce] could use a 'collaboration server' hosting several new services, together with minor enhancements to the existing Subversion and Jira servers to enhance communication and institutional memory.
There are two cautions regarding this proposal that I feel are relevant:

• Fred Brooks in The Mythical Man-Month cautioned that 'There is no Silver Bullet'. There is no magic tool or method that ensures success.
• Basic conservative thought is if it ain't broke, don't fix it. The problem with this is that our current process is broken. Symptoms include the reliance on email exchanges of 'error tracking' spreadsheet files and 'release documents' based on the old manual process. These are the cultural manifestations fostered by the limitations of the old tool sets.

New tools can be provided easily, but a cultural shift will be required. Many of the old, comfortable processes were improvised as work-arounds to limitations imposed by the previous generation of tools - or the absence of suitable tools.

Recent events have highlighted the urgency of adding a new set of resources.

• An implementation detail of the legacy Dynamo system was recovered from email, years after the developer had left.
• A week was wasted, delaying the 1.1 ecom launch as implementation knowledge left with a consultant.
• An unknown amount of personal knowledge and experience is leaving along with senior personnel in Operations.

In may ways, the current software development process resembles one for the mid 1980's. We are using current generation issue tracking and source code control tools, but not using them in their most effective configuration. Documentation is scattered, and resides in opaque files in revision control, the filesystem and email exchanges. Design and implementation decisions are arrived at in email discussions, but these discussions leave with the developers or are purged when mailbox capacity is reached.

A contrast to this would be one of the projects [for example Maven ] managed by the Apache group.

Collaboration server services

• Subversion
• Jira
• Jabber
• Wiki
• Library/Artifact Repository
• Project home pages
• JavaDoc repository
  
• Discussion system
• Developer pages
  
• Continuous Integration Engine

There is overlap in the categories - as examples, Subversion can hold binary artifacts and documents, Jira has threaded discussions attached to each issue - but specialty software is preferable, particularly when they can be connected as modules of the development system. Not all services need to be provided on the same physical [or virtual] host, but the services need to be able to communicate with each other and the developers. The services list might be expanded to include content management services such as TeamSite.

Administration

Primary administrative responsibility for the server and services should rest with the stakeholders [users] and not with a 'designated target' from operations. [But Operations, QA and other groups should be encouraged to take advantage of services that they find useful].
Operations will be responsible for routine backups, network connectivity, storage resources, disaster recovery planning and testing.

Subversion

Source code revision control remains the heart of any collaborative development team. There are several other systems that are 'just as good' but currently no other system [at any price] is clearly superior.

Enhancements

• Upgrade to current server release.
• Review backup practices to match current recommendations [including live copies]
• Review / simplify internal organization [lots of stale directories, documents and artifacts better suited to other storage]
• Review / provide pre and post commit hook scripts for housekeeping operations
• Move artifacts [build server output] to an artifact repository, use svn for source code, build scripts, shell scripts, configuration files and similar input documents
• Move documents [requirements, interfaces, implementation notes] to a Wiki or web server

Legacy support

With the unexpected extension of the old web server, middleware, reporting system, EUMA and possibly other modules. their source code should be placed into subversion for preservation and extension. Some of the systems may never have been in revision control, and the ones depending on PVCS are using a system years decades past it's 'best used by' date. The lack of a PVCS client on the deployment boxes has induced a manual, error prone workflow, without change control of the actual configuration or source files.

Jira

Enhancements

• Update to current version [this will require a dump and reload, as we are several major revisions behind]
• Review workflows as scripted, and modify them to match actual procedures - or the user's desired workflow.
• Combine the release workflow forms and procedures with Wiki templates to eliminate 'release documents'.
• Ensure that communication channels are available for Jira IDE plugins to communicate with the server.
• Configure Jira's subversion plugin to point to our repository for generating 'diff' output. [Currently points to TortiseSVN's repository]
  

Legacy support

When I was evaluating issue tracking systems, it took less than an hour to move all PVCS Tracker issues into a Jira project. Since Jira has no incremental costs per project or per user - and Tracker has both user restrictions and annual costs, there is no valid reason to continue with Tracker.

Jabber

Provide a local instant messaging server to allow for private dev to dev messaging, and notification from the Continuous Integration server. Jabber is a protocol, not a product.

Wiki

Add a wiki engine [e.g. Confluence ] to store documentation artifacts. Wikis have several characteristics that make them more suitable for a knowledge repository than common alternatives, such as shared filesystems or Lotus Notes databases. [I have not evaluated alternate wiki implementations for suitability]
A basic structure can be provided, with content imported from the filesystem and email archives, then with some cultivation its utility should grow. This is not a lightweight service, it's filesystem impact would be comparable the the shared 'G' drive, ultimately hundreds of gigabytes of indexed content [say the size of a typical workstation hard disk].

Artifact Repository

Acting as a proxy for Maven and/or Ivy dependency resolution. Locally developed applications and libraries would be uploaded here, and this would be where dependencies would be resolved during production builds. [Developer workstations may have local 'snapshot' artifacts, or may need to resolve against the master repositories] This may either be a 'passive' file system / https server combination or a Content Repository & network proxy such as Artifactory

Project Home pages

Each project would have a home page, typically refreshed and re-posted during project builds [or as part of a manual release cycle] The standard maven template generated site has links from the generated 'static' web site to related wiki pages, issue tracking, source repositories and generated JavaDoc.

Developer pages

Each developer will have a directory [or other basic URL], and may host a web site, shared files, private files or other content as the need arises. [Replacing the SMB shares to bsdevapp1, and the 'K' and 'G' drives]. These pages may be hosted on a conventional web server or by the Wiki engine.

JavaDoc repository

Provide a standard location for generated JavaDoc files. This would allow for cross-linkage of JavaDoc from the developer's current project with that generated by [or supplied with] the libraries the current project depends on. There is overlap here with the Maven/Ivy repository and Maven generated project home pages.

Discussion System

A threaded discussion system to be used either to supplement or in place of email or instant messenger, when searchable, durable communication is desired. Some systems allow the discussion to start in one mode and then be captured and supplemented in a more durable environment. This would also be useful to capture design decisions or as the basis for a FAQ.

Continuous Integration Server

If revision control is the heart of a development process, a CI server is the animus animating the process. There are several good candidates, both commercial and open source. I've prototyped a system using JetBrain's Team City, but other systems [Bamboo, Cruise Control, Continuum ] may have partisans.