摘要：测试不断发展，很明显，我们已经习惯了的一些概念在今天已经不再适用。定期期评估我们的测试实践并剔除那些不再有意义或完全有害的测试实践非常重要。下面是三种常见的测试实践，我们最好停止再这样做。
软件行业经历了许多创新和演变。有多个模型、周期和框架，如瀑布，V模型，敏捷及其多种变体等等。
也曾有人试图使测试标准化, 但遭到了测试界的抗议。测试人员认为没有标准是一件好事，他们会进行多种形式的测试，包括生产中的测试，基于会话的测试管理，探索性测试以及测试和行为驱动的开发。
但即使有了不同的实践，测试也在不断发展，很明显，我们以前习惯做的一些概念在今天已不再适用。仅仅因为它是我们一直以来的做法而继续做一些事情将是危险的，所以定期评估我们的测试实践并筛选那些不再有意义的测试实践，或者是完全有害的做法是很重要的。
以下是三个常见的测试实践，我们最好停止这样做。
1、基于bug数的绩效评估
如果根据提交和修复的bug来评判测试人员，那么重点就不再是产品质量的提高了。人们现在更担心发现了多少bug，而目标就出现了转移。
测试人员开始提交易发现的bug或为每个平台创建多个bug报告，开发人员开始拒绝难以重现或不存在bug的错误。花了相当多的时间为一个关键bug设计一个好的测试的测试人员现，在正在寻找低垂的果实。正在设计长期解决方案以制造一个更健壮的产品的开发人员，现在正在采用短期的修复方法来解决严重性“低”的bug。
仅bug统计从未说明完整的故事。将“bug”改为“idea”，概念更清晰：一个人有五个想法，另一个有两个想法。这是否意味着有五个想法的人是更好的测试人员或程序员？如果不了解bug是什么，或者发现或修复它们的复杂性，我们就无法得出最佳的结论。
那么，我们如何评估测试人员的表现呢？
首先，与测试人员交谈并制定有助于他们和公司的技能计划是个好主意。如果测试人员从未测试过移动应用，并且你的团队可能在未来几个月内需要移动应用测试人员，那么这对每个人来说都是一个很好的机会。
如果你想定量衡量测试人员的技能，你仍然可以测量它们。尽可能具体地列出测试人员应该能够执行的活动，并为其分配一个相互商定的时间表。例如，测试人员应该能够在UI、数据库和服务器级别找到bug，以使用X，Y和Z等工具，并执行以下操作。
这些目标专注于测试人员的学习和技能，而不是狭隘地关注特定属性。它可能比仅关注bug数更耗时，但它更有价值并提高了个人和公司的效率。
2、测试套件通过和失败百分比
任何发现一些bug的测试人员都知道，大多数bug是在脚本之外发现的。然而，团队在与产品交互之前，会花费大量时间编写测试用例脚本。一个测试可以在一个条件下通过，在多个其他未记录的条件下失败。你甚至可以获得95％的通过率，但仍然有100个bug要修复。
编写出所有的测试场景，并为每个bug准备一个测试用例并不是一个好主意。更有趣的是, 决策仅基于通过失败的百分比。团队依靠这些百分比，但这是一个错误的希望！
如果我们摆脱通过/失败百分比，并专注于团队给予的信心，我们会做得更好。我们可以使用低技术含量的仪表板，在覆盖范围（阻塞、理智、深度）和信心（低、平均、良好）方面进行主观评估，并根据组合进行汇报。我们应该放弃询问有多少测试通过以及有多少测试失败，并开始问：“这里有问题吗？”
我已经开始使用功能列表以及每个功能中存在的问题来共享我的仪表板。这让我们知道是什么阻止了我们发布一个功能，以及我们是否覆盖了关键的用例。
3、测试团队签字
众所周知，质量是每个人的责任。测试人员可以单独证明他们的质量份额，但他们无法保证整个产品的质量。尽管如此，项目团队还是期望测试团队在测试周期后给出一个signoff。
可以通过多种方式确保产品质量，但需要采用整体团队方法：
- 每个人都同意对可接受的质量有一个共同的定义，并有可衡量的检查点来确保它们；
- 每个团队都对其质量份额负责，并采取措施确保交付物符合质量标准；
- 角色之间的障碍被打破，专家们作为一个团队一起工作，并相互协助；
- 每个人的独特优势都被用来创造一个成功的团队文化，每个人都拥有品质；
- 当每个团队的代表参与决策并可以查看测试结果时，我们可以更加协作并停止玩责备游戏。开发人员和业务分析师对测试想法进行审查, 单元测试由开发团队完成，用户验收测试由业务分析师完成。这确保了每个人现在都知道产品质量，并且发布的决定是共享的。开发和测试团队都向产品所有者和业务分析师提供意见，最终决定权在于产品所有者。测试团队并不拥有signoff。
这里强调了我认为应该废除的三个概念，从而改善了测试过程。什么适用于你所处环境，以及你已经从日常工作中剔除了哪些实践或概念？不妨发表评论大家一起进行交流。