Click here to view the complete list of archived articles

This article was originally published in the Spring 2003 issue of Methods & Tools

---

How to Select a QA Collaboration Tool

Margaret Fross

This paper examines the methods for identifying and choosing a QA collaboration tool, which can serve to support and reinforce process for an organization.

• The following points will be addressed:
• Introduction—increasing importance of quality and what tools can facilitate quality
• Definition of the term QA collaboration tool—what is it and what can it do for you
• How to select a QA collaboration tool—key components of a good QA collaboration tool

Introduction

Because of customer expectations and some recent high-profile debacles, the software industry has begun to shift its focus toward improving software quality. For example, companies such as JD Edwards, Microsoft, and Key Bank were recently featured in an InformationWeek.com article touting "Quality First"

Of course time to market is still critical, but there is somewhat less willingness to sacrifice quality just to push software out the door.

• When organizations turn their focus to quality, they can begin by asking themselves a few questions:
• What parts of the organization have a stake in quality?
• What key quality assurance components are missing from our current development methods?
• What tools can be adopted and used by all members within the organization to improve quality?

The answers are fairly simple. All members of an organization have a stake in quality. This includes people selling, answering phones, developing applications, testing applications, marketing, and managing at an upper executive level. Anyone who may have contact at any time with the product or the customer has a stake in quality.

Next, organizations need to evaluate what goes on—from soup to nuts—when a new product concept or release comes up, or is planned. This is the organization’s process to get from the drawing board to the marketplace.

Ultimately, when talking about tools to unite all components of an organization to support its quality objectives, a good place to start is collaboration tools.

What is a QA Collaboration Tool?

A QA collaboration tool encompasses key aspects of the software quality process, providing many functions such as requirements, defect, and test case management in one easy-to-use tool. The purpose of a QA collaboration tool is to bring team members together, providing a central location for the functions above as well as provide a communication forum, document storage, and shared appointment creation. It can serve to alleviate many challenges faced by organizations, including:

Process: Lack of a defined process leads to chaotic unpredictable development. A defined process understood and used by all team members leads to repeatability and predictability. Project estimators can look at past projects to provide time estimate for future projects, predict defect rates, and make better decisions about resource needs.

Communication: Lack of communication leads to misunderstood requirements, missed deadlines, false status updates and general ignorance in the organization. This results in extra work for all team members. Cross-functional collaboration provides a forum for all team members, regardless of location or department, to communicate effectively, keeping everyone on the same page. This shared knowledge leads to a more coordinated effort resulting in on-time and on-budget delivery of high-quality software.

Traceability: Lack of a robust report tool leads to confusion among team members and upper management. Status reports are a critical component of any project. They serve to alert managers to staffing needs, development issues, and whether the project is on track or not. The ability to pull up accurate, real-time status reports at any given time allows decision makers to take action on items. Managers are better able to make informed decisions and mitigate risks. The team members in charge of delivering work items are empowered to take more ownership of their specific piece of the pie, giving them defined goals to shoot for and providing a better sense of accomplishment.

The benefits described above are just a few of the many organizations will experience should they choose to adopt a QA tool promoting collaboration.

What Constitutes a Good QA Collaboration Tool?

When selecting a QA Collaboration Tool, as with any tool, you must first assess the needs of the organization versus the budget and time that is allotted to bring in a new tool. Factors to consider are:

Cost: Examine the cost of each tool by looking at various licensing schemes (e.g., named users or concurrent users). Take into consideration any additional fees (e.g., yearly or other support fees). Identify any costs associated with implementation, conversion of existing data, staff training, and hardware.

Ease of use: Too many companies have "shelf-ware" (software collecting dust on shelves) because the tools purchased proved to be too difficult to implement or were too time-consuming to maintain. This is a tremendous waste of money and resources, remembering the time that originally went into selecting and attempting to implement the tool. Look for a tool that will fit well with what you may already be using. Pay particular attention to any import/export features that may prove useful when moving data from old systems to new systems. Good tools are ones in which an administrator can make changes on the fly, that don’t require specialized training or development skills, and are intuitive to your target user. It cannot be stressed enough: the easier you can implement a tool, the more likely you are to effectively use the tool.

Reliability: Will the tool support the user activity you predict? Can all potential users adequately perform their job functions free from frustration? Is there an uptime or availability guarantee with the tool? Does the vendor discuss the frequency with which updates are sent and will those updates necessitate down time for installation? These are important points to consider when selecting a tool.

Support: Verify that the vendor provides support. If you are paying support fees or maintenance fees, what are you getting for those fees? Look at what type of support the vendor provides. Questions to ask are: what is the average call back time for phone support and how fast are e-mail inquiries resolved? What is the charge or availability for on-site support and training?

Now let’s look at the components that make up a QA collaboration tool. Remember that the more functions you can get from one tool the easier the tool will be for your users, because they will not have to go into multiple applications to perform different functions and to get information. Desired components are:

Scheduling: A place where meetings and reminders can be created and added to team member’s calendars; project deadlines can also be displayed here.

To Do List: All projects have items that do not fit into obvious categories like Requirements and Test Case management and do not require other team members. A To Do List is a place where individuals can add personal items (such as reminders to provide a status update).

Project Tasks: Every project has deliverables and milestones. Deliverables include deliverables from the project and deliverables that are necessary to complete the project. Milestones are important because they provide goals for the group as well as a sense of accomplishment when those goals are reached. Milestones provide a simple way to tell at a glance if a project is on schedule. Having a place where tasks like deliverables and milestones can be stored, edited, and viewed by all team members promotes the accountability and traceability aspects of a solid quality assurance process.

Requirements Management: Successful projects start with clearly defined and agreed-upon requirements. One way to ensure you get good requirements is to make sure everyone is providing the same information for every requirement. That’s where a function for requirements management comes in. Users have a format with specific fields in which to enter requirement data. Requirements are then assigned directly to team members. A central repository where users can add and edit requirements for specific projects provides a way to streamline and promote the requirements definition process. The history of that particular requirement is also tracked, which can help when inspecting requirements and comparing how a requirement evolved to its current state.

Test Case Management: Test cases should tie back to specific requirements. Using the same tool for both requirements and test case management instantly provides that traceability without impacting the user. Test cases should also be as detailed as possible. Use of a tool for test case development helps ensure the users are all adding critical details when writing their test case. Test cases can then be assigned to specific team members for maintenance and execution. With some tools, changing the status of a test case to "Failed" will automatically generate a Defect record. As with requirements, test cases will need frequent editing and the change history must be tracked.

Defect Management: Defects are typically filed when a test case fails. By selecting a tool with integrated components users will be able to trace their defects back to specific test cases that trace back to specific requirements. Managing defects in this way assists team members with risk mitigation and analysis of likely failure points in the application. Defect management tools also provide a place to track support issues and enhancement requests. Use of a standard form for reporting issues guarantees several thing: easy decision making when setting work priorities, faster resolution of items, and a faster turn around time once the item reaches the test team.

Reporting: Decision makers within any organization rely on accurate, real-time information upon which to base their decisions. This is where reporting is crucial. Look for a tool that allows users to create custom reports that they can then generate at will. A good reporting function facilitates easy distribution, resulting in information sharing. With robust reporting tools, organization members—particularly upper-management—will be able to obtain accurate status updates when they most need them. This reduces the amount of time a project or team lead spends providing status to different audiences. The reporting function also comes in handy when estimating future projects. Timelines and staffing needs are predicted more accurately when looking at specific data from past projects.

Document Storage: Over the course of a project many documents are created (design specifications, requirements matrices, test plans, test reports). Using a central repository for all documents created during the life of a project ensures that all team members can access the information they need to complete their tasks. Documents stored in a central location are easier to update and maintain than those stored on local hard drives or scattered around in different network locations.

Open Communication Forum: With the influx of telecommuting, companies have a difficult time getting team members together. Team members not working out of a central office often feel left out of the loop. Creating an open communication forum for both local and remote team members will open the lines of communication. Remote team members will feel more part of the team and less isolated. Team members will be able to easily communicate when customer needs change, when technical questions come up, and when project timelines shift. This promotes better decision-making and also provides an archive of what information was available when decisions were made. Remember that shared knowledge leads to more coordinated and successful efforts.

If you examine the functions detailed above and compare them to the process components of the Software Development Life Cycle you will see that the functions provide a vehicle to promote a stable, predictable quality process.

Additional Components and Considerations

Other than the core features described above, what else can you look for in a collaboration tool?

Look for a tool that supports some form of customization. You will want to be able to add your own fields as well as delete existing fields from the forms used to enter requirements, test cases, and defects. This helps you adapt the tool to your organizational needs.

Don’t forget security. Most companies try to avoid airing their dirty laundry to clients (i.e. defects). If you find yourself needing to allow clients to view, modify, or add requirements, you probably do not want them to view other things—especially the defect list. Being able to add, delete, and modify users (and their access permissions) and change security configurations is a basic function that should be present in any tool you consider.

Any tool you look at seriously should be robust, expandable, and have no limits regarding the number of projects you can create. Look for a tool that will allow you to easily create and manage multiple projects simultaneously.

A good Help system can make a big difference in adoption and usage of any QA collaboration tool. This includes online help, documentation (including training and installation documents), and vendor support. All team members should be thoroughly trained on the product prior to usage and understand the chain of events for resolution of a question or support item. This can save your team members a lot of stress and aggravation and they will be more willing to accept the changes the tool promotes.

What about related products? Does the vendor have any other products in its suite that work with the tool to further enhance the collaborative nature of the tool? For instance, what about a trouble-ticket function? Something that your clients can access to log defects directly without allowing them to see existing defects filed internally or by other clients? Defect management can end up being time-consuming and frustrating if you have to monitor two different systems depending on who filed the defect. Other peripheral components to consider are e-mail and database functions.

Select a tool that will work well with your e-mail system (since typically users are notified when items are assigned to them via e-mail). Verify whether or not existing data can be imported into the tool you are evaluating. Examine the relative ease of getting data into the system, and of unloading the data if necessary. Finally, do not purchase any tool without first receiving a product demonstration. Participate in a multi-week trial and try to start implementing the tool with your data. You would never purchase a car before driving it; purchasing a tool is no different.

Conclusion

Remember that process drives quality. A poorly defined or absent process is a sure-fire way to miss your product targets. Products lacking in quality will have a short life. The use of a QA collaboration tool can serve to reinforce a viable QA process.

A QA collaboration tool is not just pertinent to testing teams. Anyone who has a stake in quality can benefit from such a tool. Collaboration translates to shared knowledge, which in turn is beneficial for any team working under deadlines. Consolidating many functions already in use into one tool saves time, money, and promotes a common process.

Back to the archive list