ࡱ> 7 VbjbjUU U7|7|Ol4R$$$hV%4%\Re%(44(4(n(.Z162p e e e e e e e$Sh sjf0e2-@6.^220e54(n(Ee5552j84(:n( e52 e5 5@F~_dn(% 0(,'R$3bTd[e0eb,k4kd5RR Evaluating a Bug Tracking System White Paper By Stephen Blair,  HYPERLINK "http://www.metaquest.com/" MetaQuest Software Published: October, 2004 Abstract Evaluating a bug tracking system requires that you understand how specific features, such as configurable workflow and customizable fields, relate to your requirements and your current bug tracking process. This article provides tips and guidelines for evaluating features, and explains how these features fit into a defect tracking process.  Contents  TOC \o "1-1" \h \z  HYPERLINK \l "_Toc84390899" Contents  PAGEREF _Toc84390899 \h i  HYPERLINK \l "_Toc84390900" Introduction  PAGEREF _Toc84390900 \h 1  HYPERLINK \l "_Toc84390901" Adaptability  PAGEREF _Toc84390901 \h 2  HYPERLINK \l "_Toc84390902" Bug Change Histories  PAGEREF _Toc84390902 \h 3  HYPERLINK \l "_Toc84390903" Customizable Fields  PAGEREF _Toc84390903 \h 4  HYPERLINK \l "_Toc84390904" Notifications  PAGEREF _Toc84390904 \h 5  HYPERLINK \l "_Toc84390905" Ease-of-Use  PAGEREF _Toc84390905 \h 6  HYPERLINK \l "_Toc84390906" Security  PAGEREF _Toc84390906 \h 7  HYPERLINK \l "_Toc84390907" Reports and Metrics  PAGEREF _Toc84390907 \h 8  HYPERLINK \l "_Toc84390908" Workflow  PAGEREF _Toc84390908 \h 9  HYPERLINK \l "_Toc84390909" Version Control Integration  PAGEREF _Toc84390909 \h 10  HYPERLINK \l "_Toc84390910" Web-based Client  PAGEREF _Toc84390910 \h 11  Introduction Before you start evaluating bug tracking systems, make sure you identify your requirements for the system. Understanding these requirements will help you build a list of features that you can use to guide your evaluations. To identify your bug tracking requirements, take a look at your current bug tracking process. What are the different roles and responsibilities of the people who will use the system? What is your workflow for managing and resolving bugs? Identify the steps in the process, and determine who is responsible for each step. What information do you need to track for each bug? What reports and metrics do you need? Do you need to provide different levels of access to different users? Once you identify your requirements for the system, you can translate the requirements into a feature list. Table 1 provides an example of a feature list that could be used to evaluate a bug tracking solution Table 1. List of features to evaluate AdaptabilityChange historyVersion control integrationCustomizable fieldsEase of useE-mail notificationsReportsSecurityWeb-based clientWorkflowThe rest of this document provides tips and guidelines for evaluating these features. Hopefully these guidelines will help you choose a bug tracking system that meets your requirements. Remember, the purpose of a bug tracking system is to support your process, not to impose its own. Adaptability If you want to track more than just bugs, make sure the bug tracking system can be adapted to track other types of issues (such as support calls, test cases, or purchase orders). A system that is designed specifically for bug tracking can be hard to adapt, so look for a system that provides pre-built templates for tracking different issue types. Also, as you evaluate the various features of the tracking system, look for any hardwired "bug-tracking" terminology or functionality. Fields, queries, reports, notifications, workflow: everything should be adaptable. Otherwise you'll end up trying to fit a round peg into a square hole (for example, trying to fit trouble tickets into bug reports). For example, if a tool provides a default bug-tracking workflow that you can't replace completely, you won't be able to implement workflows for other issue types. Evaluation Checklist: Pre-built templates for different issue types (support calls, test cases, ) No hardwired bug-tracking terminology or functionality Bug Change Histories Consider whether you want to track changes to bugs. Some tools maintain change histories (audit trails), which allow you to trace who did what to an issue and when (for example, who raised the priority of a bug). If the tool provides a change history, look at what information it records. For example, if you change the priority, does the change history simply say Defect modified (not so good) or Priority modified (better), or does it say Priority changed to High (best)? Some tools offer a sort of compromise, where the tool adds Defect modified to the revision history and allows the user to add a comment such as Changed priority to High after speaking to customer. A related feature is something called timestamping. In tools that support timestamping, information entered into text fields such as Description, Resolution, and Workaround are time and date stamped with the User ID of the individual who entered the text. This time stamping provides a history of the changes to important text fields. Evaluation Checklist: Changes to issues are automatically logged to revision history Change history indicates exactly what was changed (for example, Priority changed from Medium to High) Change history can be enabled/disabled on a field-by-field basis Changes to text fields be timestamped Customizable Fields You need to be able to customize the fields used to collect defect information. Otherwise, youll end up collecting only the information the tool thinks you should track, and using the tools terminology instead of your own. Fields Most bug tracking tools come with a predefined set of fields. You probably can use some of these fields as is, and others by simply changing field labels and drop-down list values to match your terminology. For example, if you already classify defects by severity and priority, and the tool includes predefined Severity and Priority fields, you just need to change the severity and priority levels to match those you already use. If you cannot reuse a predefined field, you should be able to delete it, or a least hide it so that users never see it. To collect all the information you want to track, you may also need to add new fields. The tool should be flexible enough to allow you to put new fields anywhere you want. If you cannot rearrange fields, or if all new fields are put at the bottom of a page or on a separate tab, the usability of even the simplest bug form will suffer. Field relationships Consider also whether you want to define field relationships. Field relationships can help you keep drop-down lists short and uncluttered. For example, by creating a relationship between the Product and Version fields, you can display only the version numbers of the selected product (instead of displaying all version numbers of all products). Similarly, for software bugs, you can display only the software components and filter out documentation and hardware components. Some tools also allow you to select a value from a drop-down list based on the values selected from other lists. For example, you could automatically assign bugs based on the selected product and component. Custom views and field sets Based on the user's role and the task at hand, do you want to display different sets of fields? The ability to display custom views allows you to reduce UI clutter and present only the fields necessary for the task at hand. For example, a custom view for logging new bugs wouldn't need to include the fields used by QA and Engineering to add information during the resolution process. Evaluation Checklist: Change field labels and drop-down lists to match your companys terminology Custom fieldsadd and remove fields as required Control over which fields are required and which are optional Customizable field layout Add, remove, and rename tabs Define field relationships Create custom views Notifications Notifications are really a workflow feature, because they help you track and manage bugs. For example, notifications can keep team members informed about important changes to bugs, such as changes in priority or addition of new information (such as how to reproduce the problem). Notifications can also help automate the defect management process. For example, you can notify development managers when new bugs are submitted, and developers when bugs are assigned to them. When evaluating a bug tracking tool, look closely at what kind of notifications you can send. Most bug tracking tools support a fixed, standard set of notifications: Bug added Bug edited Bug status changed Bug assigned Obviously theres a potential for a spam-like deluge of notifications, especially if you enable Bug edited notifications. So look for the ability to define notifications for specific changes to specific fields. For example, can you send a notification when someone changes the priority of a bug? Or when your most important customer reports a must-fix bug? If you want to allow customers to submit bugs directly into the system, check if the tool allows you send notifications to the customer (e.g., send the customer a confirmation, notify customer when bug is fixed). Finally, look at what information goes into a notification message, and how easy (or hard) it is to customize the contents. Some tools offer a predefined list of possible content, such as summary, full details, change history, or all of the above. Evaluation Checklist: Automatic e-mail notifications for comment events (new bugs, changes to bugs, status changes, bug assignments) Support for custom events (send notifications for specific changes to specific fields by specific users, for example, notify the developer when a tester modifies the Repro Steps fields) Send notifications to users or customers (where customers dont have a user account for the tool) Easily customizable notification message contents Ease-of-Use Is the interface consistent and easy to navigate? Web-based applications can often be difficult to navigate, especially if they behave more like a sequence of HTML pages than an application. Some Web applications are constantly reloading pages because responding to user input requires a round trip between the Web server and the user's browser. This constant reloading of pages can make an application difficult to work with, because the application doesn't behave the way users expect an application to behavelike a Windows application. When a Web application behaves like a Windows application, its easier to adopt into your development process. There's less learning curve, and less resistance to change. Another important consideration is the user interface text; is it user-friendly, simple, and clear? Finally, and maybe most important, is the interface easy to use? Try evaluating how easy is to perform common tasks, such as logging a new bug or searching for keywords in common text fields. Is it obvious how to do these tasks? And how many mouse clicks does it take? Frequently-used features should never be more than a few mouse clicks away. Evaluation Checklist: Interface is easy to navigate Easy to enter new bugs Easy access common features (requires only a few mouse clicks) User interface text and messages are easy to understand Security Security is typically based on user accounts, user groups, and user group permissions. Look for a bug tracking system that provides different levels of permissions: Field-level permissions control whether users can edit, or even view, fields. Bug-level permissions control access to bugs by users. Feature-level permissions control access to specific features, such as reporting or user account administration. Project-level permissions determine which users can access which projects/databases. There are two approaches to providing field-level security. One approach is to specify on a field-by-field basis which user groups have permission to edit the field. Other tools, such as Census from  HYPERLINK "http://www.metaquest.com/" MetaQuest Software, take a different approach, and allow you to define custom Web views of the bug database, where each custom view includes different fields. For each custom view, you can then specify which user groups that have permission to access the view. For example, a customer view would include only the fields required to submit a new bug, while a developer view would include all fields. Customers would not be allowed to access the developer view, while developers would be allowed to access either view. Bug-level security is usually accomplished by limiting the available queries. Evaluation Checklist: User groups and user group permissions Field-level security Bug-level security Feature-level security Project-level security View-level security (define multiple views of a project and then grant access permissions) Reports and Metrics A bug tracking system should allow you to quickly gather the information you need for staff meetings (bug listings and printouts), as well as provide more detailed metrics to help you make decisions. Look for tools that provide both distribution metrics (metrics that break bugs down by category or classification: for example, issue age by severity) and trend metrics (metrics that show changes over time: for example, defect arrival rate). You may also require the ability to build your own custom reports, preferably using an industry-standard reporting tool such as Crystal Reports. Evaluation Checklist: Bug listing reports, summary and detailed Distribution reports (cross-tab or chart) Trend (time-based) reports Web-based reporting Library of predefined reports Export reports and metrics Support for industry-standard reporting tools such as Crystal Reports Workflow A bug tracking tool should automate and enforce your process for managing and resolving bugs. The tool should provide a configurable workflow that allows you to define the steps in your process and the order of the steps. Workflow is typically modeled as a series of states, such as New, Fixed, and To be Verified. To support your process, youll need to be able to add and remove workflow states, as well as define the allowable transitions between states. For example, between Fixed and Closed you may want to add a required Verify Fix state, to ensure that an issue is never closed until after QA verifies the fix. You should also be able to control which users are allowed to move bugs between states. For example, you may want only members of the QA group to be able to move bugs from Verify Fix to Closed. Granting workflow permissions allows you to enforce accountability and responsibility throughout the process. While workflow is based primarily on states, you may also want your workflow to depend on other bug attributes, such as product or defect type, or even on user group membership. For example, you may need different workflows for software, hardware, and documentation issues. Finally, you should also expect a bug tracking tool to support different workflows for different projects. Evaluation Checklist: Default workflow Configurable workflow: define custom states and transitions Enforceable workflow: specify possible transitions and who has permission to make the changes Separate workflows for different projects, different issue types Version Control Integration The starting point for any worthwhile version control support is the ability to link bugs to source code. Linking bugs to source code means developers can document a bug by linking to the related source files (which is especially important if the bug is deferred). These links will also allow you to track the work done on a bug. Next, verify the version control operations that can you perform from inside the bug tracking system. You should be able to perform common operations such as checking files in and out, viewing file histories, and getting different versions of a file. The ability to check files in and out is key, particularly for Web-based bug tracking systems. Not all Web-based systems support the check in and check out operation, which limits the usefulness of the version control integration. Web-based check outs/ins help to improve development workflow and save time. If a bug tracking system has both a Windows client and a Web client, make sure you can perform all version control operations through both interfaces. Evaluation Checklist: Link bugs to source code Remote, web-based access to Visual SourceSafe databases Perform basic version control operations through the bug tracking system Web-based check outs and check ins Web-based Client In addition to evaluating the usability (see  REF _Ref48443050 \h Ease-of-Use on page  PAGEREF _Ref48443050 \h 6) of a Web-based client, you should also evaluate the implementation of the client. Architecture Web-based clients can be implemented in a number of ways: Internet Information Server (IIS) applications. An IIS application is a Visual Basic application that lives on a Web server and responds to requests from the browser. An IIS application uses a combination of ASP and HTML to present its user interface and uses compiled Visual Basic code to process requests and respond to events in the browser.  IIS applications offer good performance. They also offer easy customization and branding, because the user interface is driven by HTML templates stored outside of the DLLs. Internet Server API (ISAPI) applications. ISAPI was developed by Microsoft to address the resource problems of CGI. ISAPI uses Dynamic Link Libraries (DLLs) that are customized to return specific HTML. The IIS Web server loads the DLL the first time a request is received and then keeps the DLL in memory to service other requests. This minimizes the overhead associated with executing such applications many times.  ISAPI applications offer good performance. However, they are often difficult to customize or brand, because all the HTML that makes up the user interface is emitted by a DLL. Common Gateway Interface (CGI) applications. CGI is a standard way for a Web server to pass a Web user's request to an application and then forward the results back to the user.  One of the problems of CGI is that every request from the browser starts a new process on the Web server. Consequently CGI applications are resource hungry, and can impact the performance of your Web server. Active Server Pages (ASP) applications. ASP is a server-side scripting environment for IIS that combines HTML pages, script commands, and COM components.  ASP performance can be hindered by the fact that ASP is driven by script languages that must be interpreted at run time. Application standards Does the Web-client behave like an application, or like a series of pages? Many Web applications are page-based, like a Web site, and are basically a series of HTML page generated on the server. Every interaction with the user requires a round-trip to the server and a page reload. Something as simple as running a predefined query, or switching to another tab, can require a page reload. For example, suppose you log on to your bug tracking system to review the defects submitted yesterday. One looks familiar so you decide to do a keyword search for related or duplicate issues. In a page-based tool, this loads a new page, replacing the list of new defects you were looking at. After you type the text you want to search for and click Ok, another page is loaded, this time listing the defects that matched your query. And so it goes, back and forth between different pages as you search, scan lists, and read details. Contrast this with the behavior of a Web application whose interface follows familiar Windows standards. In this type of Web client, the keyword search, the list of issues, and the issue view/edit form are all part of a unified interface. You don't load another page to define the query, running the query updates the list in place, and the defect you're viewing doesn't disappear just because you ran a query. Customer communications If you want to allow customers to submit bugs or to monitor issue status through a Web-based interface, check that the tool includes a Web-based client that customers can use. The customer submit interface should allow an unlimited number of customers to submit bugs. Evaluation Checklist: Web-based client implemented using best technology Web-based client follows familiar desktop UI standards Web-based client for customers     Copyright MetaQuest Software Inc.  PAGE i Co[yright Copyright MetaQuest Software Inc. Evaluating Bug Tracking Systems   PAGE  WindowsXP White Paper PAGE 12 Copyright MetaQuest Software Inc. Evaluating Bug Tracking Systems Stephen Blair is a programmer-writer at MetaQuest Software, developers of the  HYPERLINK "http://www.metaquest.com/Solutions/BugTracking/BugTracking.html" Census bug tracking system as well as solutions for e-support, application self-healing, and desktop management. Web site:  HYPERLINK "http://www.metaquest.com" www.metaquest.com Telephone: 514 341-9113 Fax: 514 341-4757 E-mail:  HYPERLINK "mailto:info@metaquest.com" mailto:info@metaquest.com +7JKrst&'()DEFGOPQjklmnopqrĻ⭻⫤℻⫤|jUj>*B*Uph5CJOJQJaJj U jUj>*B*Uph j0J U5 j5UOJQJ56j56UmHnHu0J jU jUCJ(jUmHnHu0  +78p/xxp]p4Ch^hBh^hA@STV    '()*>?@YZ[\]^_`a|}~۶۠js>*B*UphjUj}>*B*UphjUj>*B*Uphj U jUj>*B*Uph0J 5CJOJQJaJ j0J U9p _M3 0  H n +$If. (@/ !,-.GHIJKLMNOjklmuvw ڶڠjUjU>*B*UphjUj_>*B*UphjUji>*B*Uph0J 5CJOJQJaJ j0J UjU jU<     - . / 0 1 2 3 4 5 P Q R S n o p S͕ 6CJ]5\j5UmHnHuj Uj7 >*B*Uphj UjA >*B*Uph5CJOJQJaJj U jU j0J UjK >*B*Uph0J 5 @t+$Ifj$$Ifld`   t 064 l` a   ()23DENT4X$(H(+$Ifj$$Ifld`   t 064 l` aNOkx28oY-|7 & F'xCj$$Ifld`   t 064 l` aS_{**D-d---2222222DDDDDDDDDEEEEEEEGGGGVIWIJ4JJJKK'L(LSSSSSSSSSSSSSSSSSS0J&mHnHu0J& j0J&UjUmHnHuCJ jWU jU jMU j U mHnHujM Uj U0J j- U jU5\6]>7x'm!!!!="W"t""""$0%:%E%X%e%Exx & F'e%&'((!))=*o*{*,D--//6/M////s000i113455CEx5@5U5h5555667P8f888889"9h9i9r9P:; =>>>>>xE>J???@ CCCCDgDDDgEtEEGGVIJJK'LLL=NQP ^`xEQPQRS&SYSSSSSSSSSSSSSSSSTBTCTETFTLTMTNTjTkTqTrTtTuTvTTT U U UZU[U\UvUwUUUVVVVVGVHVoVpVqVVVVVۺӷ۬j6U]0J jU 0J 6]j6U]j6U]6]0J&mHnHu j0J&UjUmHnHu5\0J&-@TATBTDTETNTgThTiTjTvTTTTUVVVVEF$a$  @h]hh]h3&`#$ P/ =!"#$%0 0 000&PP/ =!"8#;$%* 00&PP/ =!"8#;$%n_C\ROVPNG  IHDR(wPLTE3f3333f333ff3fffff3f3f̙3f3333f3333333333f3333333f3f33ff3f3f3f3333f3333333f3̙333333f333ff3ffffff3f33f3ff3f3f3ffff3fffffffffff3fffffff3fff̙ffff3fffff3f̙3333f33̙3ff3ffff̙f3f̙3f̙̙3f̙3f3333f333ff3fffff̙̙3̙f̙̙̙3f̙3f3f3333f333ff3fffff3f3f̙3fguhtRNSAbKGDH cmPPJCmp0712HsmIDATXGX=v &M"I."7AMti⋬+"I8 ßmm~^3~boa@?~N]ؿ,}/ Q-E/7Bs-TEE#e˃Qs$:)2=Hv"j̾Mu֛{@UVuUeQdQzT`ăV#Q3ZrlʕlJVrHhmM#DS[I1|<>2T:E担/z`RbꅁoL%^b<+x4mL }׭@4}>zI+O0&3YTw'hހ9 ^UP Q]ؗo@yr+=5I^Ss0ʀkc%I·y7H>8b<9sڂ.~%qy}`u!(r[2^V!der*)|?OJwN)&Onƾ]4q0dlf$+9cЄM`jn)ҹ+hξsչ#:y:=9߷Ơp$I> 2?M>jT@AίycEX/B/!xKpfS![E.-~Gc `#V<^>\JMz$ #OhDl۹C,dK:jɏȻ^sǧov߰~g|8 ƃ˓:&=㩝LXt8*? ;YS #.t ̾IjҦmSnӠE7]<2a)kui{ `br5΋+ ќIM{}=ֹ+i ZUH}GZی#1 mJ4ҦTI/zPi͑85 ܥ"ÂeT&3BfP q_a^g/?axYeS>fMΟ\d᏷mZ4J$'\4DW+ߟŸ6~&HAǨL00AC浉o}GנEIENDB`DyK yK 4http://www.metaquest.com/{DyK  _Toc84390899{DyK  _Toc84390899{DyK  _Toc84390900{DyK  _Toc84390900{DyK  _Toc84390901{DyK  _Toc84390901{DyK  _Toc84390902{DyK  _Toc84390902{DyK  _Toc84390903{DyK  _Toc84390903{DyK  _Toc84390904{DyK  _Toc84390904{DyK  _Toc84390905{DyK  _Toc84390905{DyK  _Toc84390906{DyK  _Toc84390906{DyK  _Toc84390907{DyK  _Toc84390907{DyK  _Toc84390908{DyK  _Toc84390908{DyK  _Toc84390909{DyK  _Toc84390909{DyK  _Toc84390910{DyK  _Toc84390910DyK yK 4http://www.metaquest.com/{DyK  _Ref48443050{DyK  _Ref48443050DdT  C 0Acaution.gifbO5,K, gnO5,K,PNG  IHDR \'. PLTEZRtRNS A cmPPJCmp0712Om(IDATcky E0lt__-`X WcֻIENDB`DdT  C 0Acaution.gifbO5,K,gnO5,K,PNG  IHDR \'. PLTEZRtRNS A cmPPJCmp0712Om(IDATcky E0lt__-`X WcֻIENDB`DdT  C 0Acaution.gifbO5,K,gnO5,K,PNG  IHDR \'. PLTEZRtRNS A cmPPJCmp0712Om(IDATcky E0lt__-`X WcֻIENDB`Ddb  C 0Acaution.gif"@@bO5,K,gnO5,K,PNG  IHDR \'. PLTEZRtRNS A cmPPJCmp0712Om(IDATcky E0lt__-`X WcֻIENDB`DyK yK http://www.metaquest.com/Solutions/BugTracking/BugTracking.htmlDyK www.metaquest.comyK 4http://www.metaquest.com/DyK yK 4mailto:info@metaquest.comG iB@B Normal dxOJQJ_HmH sH tH P@P Heading 1 $$h$d@&N 5CJKH8@8 Heading 2$x@&58@8 Heading 3$@&5<< Heading 4$@&5CJ<A@< Default Paragraph FontXOX Abstract Text dCJOJQJ_HmH sH tH lOl Abstract Title)d(x$dN]5CJOJQJaJ@O@ Bullet 1 & F d1$R"R Bullet 2 & F 1$^CJOJQJaJZ2Z Bullet 3' & F 81$^8`CJOJQJaJhBh Caption Large Picture`d8<^`6CJOJQJaJRRR Caption Normald8<6CJOJQJaJ2b2 Code dL CJOJQJ:'@q: Comment ReferenceCJaJF@F  Comment Text dxCJOJQJaJ(O( Contents\:: Document Type5KH,@, Header  !TOT Footer-even#  5$dN^55CJTOT Footer-odd& 5$dN^55CJ8&@8 Footnote ReferenceH*LL  Footnote Textdx1$CJOJQJaJ(U@( Hyperlink>*B*VV Legalese! XdtF0$^6CJOJQJaJdd Picture1 Small!"$dx1Z  &a$6CJOJQJaJ`2` Masthead Descriptor#d8^6CJOJQJaJB Number$ & F (1$>T.Tf^`(BARB Number after bullet %]^]&)@a& Page Number:r: Paper Title'h(]hCJ @R@ Picture2 Med ($ mHnHuLBLPicture3 Large)$`^` mHnHu>V@> FollowedHyperlink >*B* phBOB Table Body+sd((]sCJBB Table Bold,d((1$5CJFF Table Bullet- & F h].O1. Table Title.x>@>TOC 1/ % d5mHnHu66TOC 2 0 %CJmHnHu>>TOC 31 %^CJmHnHu>">TOC 42 ^CJmHnHu, @2, Footer 3 !0OB0 Byline4 h6&& TOC 5 5 ^ && TOC 6 6^&& TOC 7 7^&& TOC 8 8x^x&& TOC 9 9@^@TT Note2:d$d &d N P CJ\"W@" Strong5\DOD Heading 2 CharOJQJ_HmH sH tH 88 Comment Subject=5\2 2 Index 1>8^`8@@  Balloon Text?CJOJQJ^JaJfOf Product Head,ph@$$ $dH<*$5@CJ*KHHOJQJh^O^ Product Name,pnA$$Jd^J5@CJ8OJQJ\O\ Product-MS,pmsB $`d*$^`@CJ KHOJQJ@B@2@ Body TextCdx OJQJh<CB< Body Text Indent Dh^hDORD Checklist Item E & F'(OJQJFP@bF Body Text 2F$dN 6CJ]R R"T +78p _M30Hn  ( ) 2 3 D E N O k x 28oY-|7x'm=Wt 0!:!E!X!e!"#$$!%%=&o&{&(D))++6+M++++s,,,i--/011@1U1h1111223P4f444445"5h5i5r5P67 9:::::J;;;< ????@g@@@gAtAACCVEFFG'HHH=JQLMNO&OYOOOOOOOOOOOO' E0&>' E0'>' E0(>000?0e@ 0 e@0e@ 0e@0e@ 0e@0e@ 0e@0e@0?0G0G0G0?0L(0L' E0)N' E0*N' E0@0@0@0@0@30@0@0@0@30@0@0@0@0@0@0@0@0@30@0@0@0@0@30@0@0 0F0F000 14 SSV.1348>p N7e%5>QP@TV/25679:;<=?V0Js&'FPkmnp )?Z\]_~ -HJKMlv .013Ro...@@@@AARX tX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%T̕Xt%t4;=!!!NCUXXXT   Ob$_C\ROVgb$يح>^VgR$/ ,+kBqx$ gb$ +uD7hg@ ( P T   C    s AV`..\..\Artwork\Logos - MetaQuest\mqlogo.gifyK yK 4http://www.metaquest.com/B S  ?p X(   b  C ?3"!  C nAV..\..\Artwork\Logos - MetaQuest\mqlogo.gif   s AV`..\..\Artwork\Logos - MetaQuest\mqlogo.gifyK yK 4http://www.metaquest.com/R" XT  !]t1%T0k %T _Hlt85527264 _Hlt85527265 _Toc84390899 _Hlt84391352 _Hlt84391353 _Hlt85527908 _Hlt85527909 _Toc396470201 _Toc84390900 _Toc84390901 _Toc84390902 _Toc84390903 _Toc48469680 _Toc48469681 _Toc48469682 _Toc48469683 _Toc84390904 _Toc48469685 _Ref48443050 _Hlt48443067 _Hlt48449467 _Toc84390905 _Toc84390906 _Toc84390907 _Toc84390908 _Toc84390909 _Toc84390910k om$o&o&o&o&+1i5;@R@@@@@@ @@w &$o&o&z&z&+2q5;@OROOOOOOOOOOOOOOPPR 37 **t5566@:L:ZHHNNOOOOOOOOOOOOOOPPR333333333333338;J..3O4!5g5@@@AJJDKKKKKHLHLMM OOOOOOOOOOOOOOOOOO;PBPCPNPhPwPPPPPPP QwQQRRR Stephen BlairoC:\Documents and Settings\stephen.METAQUEST\My Documents\My Work\HelpDesk\Evaluation Guide\Evaluation-Guide.doc Stephen BlairoC:\Documents and Settings\stephen.METAQUEST\My Documents\My Work\HelpDesk\Evaluation Guide\Evaluation-Guide.doc Stephen BlairuC:\Documents and Settings\stephen.METAQUEST\Application Data\Microsoft\Word\AutoRecovery save of Evaluation-Guide.asd Stephen BlairoC:\Documents and Settings\stephen.METAQUEST\My Documents\My Work\HelpDesk\Evaluation Guide\Evaluation-Guide.doc Stephen BlairoC:\Documents and Settings\stephen.METAQUEST\My Documents\My Work\HelpDesk\Evaluation Guide\Evaluation-Guide.doc Stephen BlairuC:\Documents and Settings\stephen.METAQUEST\Application Data\Microsoft\Word\AutoRecovery save of Evaluation-Guide.asd Stephen BlairuC:\Documents and Settings\stephen.METAQUEST\Application Data\Microsoft\Word\AutoRecovery save of Evaluation-Guide.asd Stephen BlairuC:\Documents and Settings\stephen.METAQUEST\Application Data\Microsoft\Word\AutoRecovery save of Evaluation-Guide.asd Stephen BlairoC:\Documents and Settings\stephen.METAQUEST\My Documents\My Work\HelpDesk\Evaluation Guide\Evaluation-Guide.doc Stephen BlairuC:\Documents and Settings\stephen.METAQUEST\Application Data\Microsoft\Word\AutoRecovery save of Evaluation-Guide.asd'|:uк}\o,~ (+l>2ᐵ/&FtE+2s+&8a*7 }O`WLS f9_ (|1&|21)%v1~m&6H7{_}8XeY8 {H`3JZR@S _T`UZZ#[`;txLhy`e}22e1M~`^`.^`.88^8`.^`. ^`OJQJo( ^`OJQJo( 88^8`OJQJo( ^`OJQJo(hh^h`. hh^h`OJQJo(@](^]`(CJOJ QJ o(.h ^`OJQJo(h ^`OJ QJ o(oh pp^p`OJ QJ o(h @ @ ^@ `OJQJo(h ^`OJ QJ o(oh ^`OJ QJ o(h ^`OJQJo(h ^`OJ QJ o(oh PP^P`OJ QJ o(@(^`(CJOJ QJ o(.@(^`(CJOJQJo(.h^`OJQJo(hHh^`OJ QJ ^J o(hHohpp^p`OJ QJ o(hHh@ @ ^@ `OJQJo(hHh^`OJ QJ ^J o(hHoh^`OJ QJ o(hHh^`OJQJo(hHh^`OJ QJ ^J o(hHohPP^P`OJ QJ o(hH hh^h`OJQJo(@(^`(CJOJ QJ o(.h^`.h^`.hpLp^p`L.h@ @ ^@ `.h^`.hL^`L.h^`.h^`.hPLP^P`L.m^`m56OJQJo(-@(^`(CJOJ QJ o(.hhh^h`CJOJ QJ o(qh 88^8`OJ QJ o(oh ^`OJ QJ o(h   ^ `OJQJo(h   ^ `OJ QJ o(oh xx^x`OJ QJ o(h HH^H`OJQJo(h ^`OJ QJ o(oh ^`OJ QJ o(h ^`OJ QJ o(oh ^`OJ QJ o(oh P P ^P `OJ QJ o(h   ^ `OJQJo(h ^`OJ QJ o(oh ^`OJ QJ o(h ^`OJQJo(h ``^``OJ QJ o(oh 00^0`OJ QJ o(@(^`(CJOJQJo(.@(^`(CJOJQJo(.@](^]`(CJOJ QJ o(.@(^`(CJOJQJo(.@(^`(CJOJQJo(.@(^`(CJOJQJo(.h ^`hH.h ^`hH.h pLp^p`LhH.h @ @ ^@ `hH.h ^`hH.h L^`LhH.h ^`hH.h ^`hH.h PLP^P`LhH.@](^]`(CJOJ QJ o(.hhh^h`CJOJ QJ o(qh 88^8`OJ QJ o(oh ^`OJ QJ o(h   ^ `OJQJo(h   ^ `OJ QJ o(oh xx^x`OJ QJ o(h HH^H`OJQJo(h ^`OJ QJ o(oh ^`OJ QJ o(@(^`(CJOJQJo(.@(^`(CJOJQJo(.@](^]`(CJOJ QJ o(.@](^]`(CJOJ QJ o(.h^`OJQJo(hHh^`OJ QJ ^J o(hHohpp^p`OJ QJ o(hHh@ @ ^@ `OJQJo(hHh^`OJ QJ ^J o(hHoh^`OJ QJ o(hHh^`OJQJo(hHh^`OJ QJ ^J o(hHohPP^P`OJ QJ o(hH@(^`(CJOJQJo(.h hh^h`OJQJo(@](^]`(CJOJQJo(.'e}eY8&69_ (Tq{H _T#[ }Oe1M~hyoUZ3J%v1sR@SkOsu^a*77kr1)~}|WLS ;tx+&{_}8^''                                    =                   ( ) 2 3 D E N O OOOOOPR@BR`@Unknown Gz Times New Roman5Symbol3& z Arial7&  VerdanaE5  Lucida Console3z Times71Courier?& Arial Black5& zaTahoma5"Geneva?1 Courier New;Wingdings"1h;wfsDxHnI A! 4? !;0dPJJ 2qXeC:\Documents and Settings\toddph.SEGROUP\Application Data\Microsoft\Templates\Windows White Paper.dotEvaluating Issue Tracking Tools Stephen Blair Stephen BlairOh+'0$ <H d p |  Evaluating Issue Tracking ToolsvalStephen BlairueteptepWindows White Paper.dotStephen BlairPa328Microsoft Word 9.0.@ B @]@ XV@ ' A՜.+,D՜.+,` px  \\!P  Evaluating Issue Tracking Tools Title  8@ _PID_HLINKSA \Nhttp://www.metaquest.com/:G _Toc84390910;A _Toc84390909;; _Toc84390908;5 _Toc84390907;/ _Toc84390906;) _Toc84390905;# _Toc84390904; _Toc84390903; _Toc84390902; _Toc84390901;  _Toc843909002 _Toc84390899\http://www.metaquest.com/Qnmailto:info@metaquest.com\http://www.metaquest.com/{.@http://www.metaquest.com/Solutions/BugTracking/BugTracking.htmlv=G caution.gifv=VI caution.gifv=J caution.gifv='L caution.gif\http://www.metaquest.com/@Y+..\..\Artwork\Logos - MetaQuest\mqlogo.gif@Y+..\..\Artwork\Logos - MetaQuest\mqlogo.gif\ http://www.metaquest.com/@Y +..\..\Artwork\Logos - MetaQuest\mqlogo.gif  !"#$%&'()*+,-./0123456789:;<=>?@ABCDFGHIJKLMNOPRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~Root Entry F@-'Data EM1TableQkWordDocumentUSummaryInformation(DocumentSummaryInformation8CompObjjObjectPool@-'@-'  FMicrosoft Word Document MSWordDocWord.Document.89q