软件开发中的结对测试(测试配对结对开发人员人员)「软件结合测试」

培养观点差异的一种方法是使用结对活动。
结对编程和结对测试是最流行的两种。
本文重点介绍结对测试，我将分享团队如何利用结对测试发挥优势的经验。

结对测试可以在测试人员之间、开发人员之间以及测试人员和开发人员之间进行。
只要相关人员的关注点和观点不同，结对测试就会大有裨益。

无论测试计划和组织得多么周密，测试人员之间的配对都可能会发现遗漏的边缘情况。
特别是在具有不同专业水平的测试人员之间，在探索性会话中集思广益测试案例将有助于更多地了解被测系统。
例如，可用性测试人员与后端测试人员配对可能会以可能导致有趣发现的方式相互补充。
每次新功能准备好进行测试时，不同开发团队之间的测试人员都会安排结对测试会话。
在某些情况下，结对测试安排在测试执行之前和测试用例设计期间。

前端和后端开发人员可以集思广益，了解为什么事情在需要棘手实现的用例中以这种方式工作。
接下来，不同团队之间的开发人员可以对代码相互依赖性进行配对测试。
一个团队使用配对测试进行单元测试和集成测试。
其他团队从单元和集成测试一直到 API 测试都是成对进行测试。
最后，一个没有测试人员的开发团队使用结对测试来拓宽他们对实现的看法。

这通常是配对测试最有效的组合之一。
开发人员经常进行测试以检查已实现的代码是否按预期工作。
测试人员经常进行端到端测试，以检查软件系统是否按预期运行。
最重要的是，测试人员还必须探索系统中的任何类型的风险和意外情况。
与开发人员配对测试以应对意外和风险可以对所有相关人员进行教育。
测试人员可以从开发人员那里了解系统为何如此运行。
开发人员可以学习新的方法来检查系统和导致问题行为的用例。
例如，有一个 6 人的开发团队在发布前进行了配对测试。
开发人员已经在单元级别进行了测试，还在 UI 级别进行了冒烟测试。
测试人员完成了对系统行为的验证和探索。
他们使用了一个限时会议，整个团队都参与了最后的绿灯发布。
另一个团队在发布后进行了全团队配对测试。
在完成所有测试活动并发布被测功能后，团队聚集在一起进行全团队冒烟测试活动。
这有助于团队获得信心，相信发布不会引起不愉快的意外。

在遵循以下循环的团队中：开发 → 代码审查 → QA 测试 → 发布，在代码审查之前和开发期间进行结对测试有助于更快地发布功能。
开发人员与测试人员组织了配对测试会议，以演示他们的功能是如何工作的。
在配对测试中，他们检查了正面和负面的情景。
UI 的外观和感觉进行了讨论，以及可能的性能瓶颈。
当双方都对结对测试的结果感到满意时，开发人员将检查被测代码。
随后将进行代码审查，然后由测试人员进行全面的 QA 测试。
配对测试通常会发现基本问题。
这减少了开发 → 代码审查 → QA 测试周期，用于修复错误或在发布前实施重要改进。
更少的周期意味着更快的发布。

配对测试可用于发现新的错误。
无论我们编写了多少测试，无论我们执行了多少案例，当我们跳出框框思考并以新的方式测试系统时，我们总是会发现更多的错误。
我们可以拥有数量可观的测试用例，涵盖所有可用的功能和非功能需求。
及时，测试套件将捕获回归错误。
虽然回归错误对于查找和修复很重要，但可能还有其他未识别的重要错误。
结对测试期间的头脑风暴可能会带来探索和识别新问题所需的创造力。

在配对测试会话中向同事展示问题似乎比在错误跟踪系统中发布错误并等待同事找时间修复错误更有效。
必须在错误跟踪系统中跟踪错误。
然而，在远程工作环境中，人们在截然不同的时区工作，在配对测试会话中发现的错误更有可能更快地得到解决。
通过错误进行沟通和协作通常可以更有效地解决问题。

通常，当我们尽我们最大的能力解释一种现象时，我们往往会更好地理解我们刚刚解释的现象。
不仅听我们讲话的人知道，而且我们也理解得更好。
结对测试带来的最重要的价值之一是结对可以增进双方的理解。
这通常会带来新的想法和问题的解决方案，因为交流新想法可以提高创造力。
当开发人员试图解释新代码如何工作时，她可能会理解一开始不太清楚的事情。
当测试人员解释重现偶发问题所遵循的操作顺序时，问题的隐藏细节可能对他来说变得显而易见。

可以在软件开发组中的任何角色之间进行配对测试。
在产品所有者、设计师、开发人员和测试人员之间以及具有相同角色的同事之间。
为了充分利用配对，我们需要观点的多样性。
多样性可以带来创造力。
只要多样性也能带来建设性的反馈，结对测试就可以有效地提高我们对高质量功能发布的信心。