我们在我的组织中使用自制的缺陷跟踪系统。作为一名 QA，我之前曾在各种不同的组织工作过，发现当前的内部解决方案低于标准。我最初开始提出功能请求，但在这个阶段，列表太长了，开发它们的成本将等于购买 OTS 解决方案的成本。再加上我们在长长的请求队列中落后的事实——更令人怀疑的是，我们是否应该投入时间/金钱。
IMO - 我们开发自己的专业产品 - 开发缺陷跟踪系统不是我们的核心功能，也不应该浪费我们的时间。
有人告诉我，如果我希望看到我们转向现成的解决方案，我需要进行成本效益分析来证明其价值。
我有自己的一套功能和成本节约，我认为我们会从搬家中受益。
我真的很感激那些经历过类似情况的人的意见，他们从内部转移到 OTS 缺陷管理系统。
所以这是一个简短的问题 - 从长远来看，您如何说服您的团队迁移到 OTS 是公司的最佳解决方案？
谢谢！
在交换系统上销售它们的很大一部分是了解您的事实并做好准备。
您可以从功能列表比较开始。供应商将发布他们自己的功能比较，但他们会偏向于他们自己的产品，强调他们自己感知到的优势，而不是强调或反驳他们的弱点。根据您认为自己需要的内容进行自己的功能比较，而不是根据供应商希望您认为重要的内容进行比较。
如果您现有的系统已经存在了一段时间，它可能会与其他系统集成。您应该评估这些集成是否仍然必要，如果是，是否可以使用现成的系统来完成。当然，您也可以考虑与新系统集成但与旧系统（在其当前状态下）不可行的集成。
一些组织针对不同的受众使用多个错误跟踪系统，例如，一个系统用于客户支持，另一个系统用于内部错误跟踪。如果您当前的系统用于多个受众，请考虑这是否仍然是合适的选择。在某些情况下，为特定受众量身定制不同的系统或同一系统的多个实例可能是有意义的。
最后，制定一个过渡计划。包括您自己的部署/开发工作、数据迁移工作以及制作培训材料和培训课程的时间。切换错误跟踪系统将需要人们重新学习用户界面和工作流程。有些人不喜欢改变，有些人不喜欢你给他们忙碌的生活带来不便，即使从长远来看这是最好的。向他们展示你有一个计划将有助于消除切换系统的痛苦。
我也遇到过类似的情况。因为，我使用过不同的测试用例管理工具，所以当我使用内部测试用例管理工具时，我能够提供缺点/缺失的功能。
首先，您需要了解当前工具的缺点。如果您最终确定了新工具，那么要考虑的第二个重要事项是迁移方面。
我对测试用例管理工具进行了类似的练习。几点也适用于错误跟踪工具。分析标准基于
该工具是否提供 Web UI 界面来更新/管理测试用例和错误。这比使用客户端应用程序连接到服务器要好。
记录错误的可追溯性。它是否提供将错误与失败的测试用例联系起来的选项
如果您使用不同的产品进行测试用例管理，那么您需要查看如何将其与错误跟踪工具集成
记录错误的报告/指标。错误类型（代码/设计/部署）。生成报告是多么容易。该工具提供的内置报告是什么
工具的成本、可用性方面（添加图像/屏幕截图/复制粘贴）等。
开发工具/维护/支持工具所需的努力。您有很多相对便宜的工具，您可以从当前系统快速迁移
您可以开始寻找免费工具，成本相对较低的工具。如果您开始关注 HP、Microsoft 工具，您可能会遇到成本问题。
当前工具中缺少的缺点，您可以提供对手动跟踪它们或手动导出指标所花费的工作量的估计。您可以建议如何在新工具中节省这些努力
我还看到管理层意识到工具存在缺陷但对迁移到新工具不感兴趣的情况。原因是根据组织目标，这不是优先事项。它还取决于团队内部领导的成熟度，以通过更好的工具和实践来提高团队生产力l
找到了另一个与此讨论相关的工具。BugTracker.NET 是一个免费的、开源的、基于 Web 的错误跟踪器 - http://ifdefined.com/bugtrackernet.html