目录
摘要
在短短一年内，一个测试团队将测试周期缩短了50％以上。 它需要分析，计划和努力 - 首先他们研究了他们如何度过他们的时间，然后他们质疑他们是否可以减少任何这些领域的时间。 一旦他们知道哪些方面可以更有效率，他们就可以开始攻击他们的阻挡者了。 你也可以这样做。
内容
“没有躲避的方式！”
当我问我们是否可以将系统测试时间表加速一周时，这就是团队的反应。 谢天谢地，自动更正。
在这个项目中，我们通常有九个月的交付周期，在代码完成里程碑之后有三个月专门用于系统测试，并且在这三个月中每天都需要使用。 我们在最后几周的夜晚和周末工作。 我与团队一起探讨可能会花一周时间的会议遇到了很多原因，为什么我们需要更多时间，而不是更少。
所以，我们采取了不同的策略。 我们花了一些时间询问时间在哪里。 我们开始列出我们在这12周内所做的所有事情，最后我们得到了一个模拟时间的伪方程：
系统测试持续时间= RC *（TC / TV + B * BHT）/ PC
RC =重新测试周期，或者因应用程序更改而重新测试的次数
TC =每个周期中执行的测试用例数
TV =测试速度，或平均而言，我们在一个单位时间内执行了多少测试用例
B =在测试阶段发现并修复的bug数
BHT =bug处理时间，或处理每个bug的工作量（诊断，记录，验证修复等）
PC =人员容量，或测试人数，以及他们的生产力
现在我们已经将这个模型作为一种以更简单的方式表达时间的方式，我们可以提出更实际的问题：
1）我们可以做些什么来减少重新测试周期的数量？
2）我们需要执行所有测试用例吗？
3）我们怎样才能提高测试速度？
4）我们如何减少测试阶段我们必须处理的错误数量？
5）我们可以更有效地处理错误吗？
6）我们在哪里可以找到更多人来帮助测试，我们如何才能提高他们的工作效率？
花时间将这个大而丑陋的问题分解成更具可操作性的问题确实帮助我们看到我们实际上可以有所作为。 毕竟我们并不那么无助。
我们重新开始会议时只询问其中一个问题，然后探讨了改进这一个变量的方法。 最后，经过一年的改进，我们能够将系统测试时间缩短到五周。 当我们开始谈论它时，我们认为我们不能在一个为期12周的测试周期中去掉一天时间; 我们最终将时间缩短了一半以上。
减少系统测试中的bug
我们开始解决在系统测试期间发现的bug数量，因为我们确实发现并修复了许多bug，因此有很好的机会进行改进。 但更重要的是，减少bug对于我们提供高质量软件的主要目标至关重要。
在此之前，我们没有记录系统测试中发现bug的根本原因，因此我们不得不使用一些判断和与开发团队的协作。 我们阅读了上一个测试周期中发现bug的样本并查找了任何模式。 我们发现了许多简单的编码错误和许多内存泄漏（它是一个C ++应用程序）。
我们花了一些时间确保我们从代码审查中获得最大收益，以帮助减少编码bug的数量。 我们进行了代码审查培训，跟踪了代码审查，并将代码审查结果报告给了团队。 我们还开始使用一些旨在检测内存泄漏的工具。 这两项改进开始削弱在系统测试期间处理错误所需的工作。
我们最终开始记录bug的根本原因，我们定期进行分析以找到其他改进的机会。
改善bug处理时间
当我们查看我们的bug列表时，我很尴尬地发现我们报告的一半bug是在没有修复的情况下关闭的。 其中两个最大的因素是开发人员无法复现bug，并且该bug与系统中已有的bug重复。
这需要一个简单的改变：我们培训测试团队在创建新bug之前搜索bug跟踪系统。 如果他们发现了类似bug，他们会考虑使用更新的数据修改原始bug报告，或咨询分配给该bug的开发人员。
对于无法复制的bug，我们尝试了一个实验。 而不是测试人员编写bug并继续前进，测试人员将持有一个“biug的蜷缩”来向开发团队演示bug。 这个bug的蜷缩通常发生在一天结束时。 然后，测试人员会在该对话之后编写bug报告。 这导致更快的修复，因为开发人员经常会说，“啊，我看到发生了什么。”bug演示在减少重现bug的步骤中的任何歧义方面走了很长的路。
经过这些改进之后，我们看到80％以上的报告bug实际上得到了修复，我们减少了“bug乒乓”游戏。
提高测试速度
提高测试自动化覆盖率似乎是提高测试速度的明显方向，自动化确实提供了帮助。 但是我们发现其他一些东西也有助于提高速度。
我们构建工具以帮助在安装后自动填充测试数据，因此测试人员已经安装了构建版本，并且在他们早上到达工作时已经安装了所需的测试数据。
我们还创建了“最想要的bug修复”列表，并提出了这些bug的优先级。 最需要的bug是阻止测试完成的bug，因此我们将开发人员使用的优先级与测试人员的工作效率联系起来。 这有助于减少测试人员等待修复的时间。
减少测试用例
当我们开始考虑它时，减少我们执行的测试数量的想法是相当有争议的。 但是，如果我们将其视为基于风险的测试，我们将最多的测试工作放在风险最大的领域，我们就开始取得进展。
我们将每个测试套件分为两个维度：这些测试会发现bug或bug的概率，以及如果产品的某个区域存在bug，对客户产生后果的严重程度。 每个维度都被评为高，中或低，我们使用图表来确定我们的方法：
| 发生问题的概率 |
||||
| High |
Medium |
Low |
||
| 严重性 |
High |
P1 |
P1 |
P1 |
| Medium |
P1 |
P2 |
P3 |
|
| Low |
P2 |
P3 |
P3 |
|
我们与开发团队一起审核了这个分析，询问他们认为风险最大的领域。 他们能够立即命名一些区域，并且他们还在更改日志中对经常修复bug的代码进行了一些研究。
我们与产品管理团队一起审核了这些数据，以评估客户对严重性级别的影响。 同样，他们有一些直接关注的问题，并根据使用情况分析进行了后续分析。
具有P1优先级的测试套件是我们测试的最高优先级。 我们确保在周期的早期和早期测试这些测试，然后再次测试，确保在周期内没有”衰退“。
接下来是P2测试套件，为此，我们在循环结束时对回归测试采取了更多的自由度。 对于P3测试套件，我们对它们进行了详细检查，并使用采样并在系统测试中仅执行一次，对这些测试套件进行了修整。
寻找更多的人
我最后保存了这项改进，因为这是团队要求的第一件事：一个更大的团队。 我一开始很担心要求更大的预算; 我不想做更多同样的事情。 但是，在完成上述一些改进并展示其进展后，我们的领导者询问我们还能做些什么。
做出显着改进确实需要您的团队投入时间。 我们能够要求更多人，并展示我们对新投资所期望的具体改进。
我们最终找到了一个离岸合作伙伴来帮助进行大量的回归测试。 这使现有团队有更多时间进行进一步改进，最终成为一个良性循环。
在与离岸合作伙伴合作之前，我们确实通过与组织中的其他人一起帮助进行一些测试来获得一些帮助。 产品经理，客户支持和技术文档团队真正投入到帮助制作更好的产品，并且他们自愿花时间帮助进行测试。
我们还做了一些“测试卡纸”，我们将整个团队聚集在一起，测试产品的各个方面。 开发人员和经理都参与其中，每个人都进行了一天的测试。 我们给找到最有趣的bug和最严重的bug的人奖励。 测试果真很有趣，也是一个很好的团队建设活动。
选择你的战斗
最后，我们将测试时间从12周减少到5周。 这不容易或直截了当，但是一旦我们创建了这个等式来表示时间并开始削减每个变量，我们最终成功地解决了我们的挑战。
自从这个项目以来，我多次使用这种技术来加速测试周期。 团队非常喜欢将时间分解为特定变量并找到立即改进的机会的过程。
