技术文章

测试工作很容易变得不可见或难以辨认。大部分都发生在您的脑海中，有时当软件一开始就非常好时，没有证据表明测试确实发生过。

我经常被要求做的事情之一就是审查测试实践。我通常发现测试人员都在那里，他们正在努力工作，并且他们关心他们的工作。问题是他们的工作完全被隐藏了。没有人能看到它，正因为如此，没有人理解它或如何改进它。

那么，如何使您的测试工作对您的团队可见呢？

Scrum 站立会议

我参加过的大多数日常 scrum 对测试人员来说都很困难。我们从开发人员和产品人员开始巡视了整个房间。如果测试人员被要求进行状态更新，那是在最后，大多数人都对这一点心烦意乱或不感兴趣。有时，在测试人员说出自己的想法之前，就会开始讨论，而我们已经没有时间了。

当其中一名测试人员接到电话时，他们会说“我正在测试社交媒体共享卡”。如果他们正在处理多个项目，状态就更不具体，他们只会说他们当天计划处理哪个项目。

没有人离开 scrum 时比他们进来时更了解测试工作。

就像软件开发一样，测试也是多方面的。我们不仅仅是开发或测试——还有很多活动是在测试的背景下发生的。每日例会是强调其中一些活动的好时机。

团队从非常笼统转变为真正谈论工作。一个人可能正在致力于构建测试数据，一个人可能正在致力于重现一些看起来像是竞争条件并且需要一些帮助的东西，而另一个人可能只需要一两个小时才能继续进行下一个更改。

每日站立会议是分享此类详细信息的适当时间。

测试覆盖率

想知道产品或功能的测试程度是一件非常合理的事情。开发人员希望预测他们可能需要进行的任何错误修复。管理者需要了解版本的进展情况。产品人员需要能够解释客户何时会在生产中看到急需的功能或修复。然而，这些也是大多数测试人员很难回答的问题，这削弱了它们的价值。

谈论覆盖范围的最佳方式之一是库存。一个软件产品可以从不同的角度来描述——配置、页面、功能、文本字段、支持的浏览器、数据库等等。谈论报道的一种方法是对每一件事情都保留一份清单。当有人询问高级别测试覆盖率时，您可以告诉他们您已经在两个受支持的浏览器上测试了 45 个记录功能中的 15 个。您还可以讨论剩余的内容和超出范围的内容。

在功能层面，我发现它有助于保持较小的测试想法库存。这不必是文本文档或思维导图，也不必是文档页面。只需一个简单的参考即可。这可以作为组织测试想法的一种方式，也可以作为描述您测试变更的进度以及可能还需要多少时间的工具。

能够谈论报道可以消除你工作中的一些神秘感。这也表明你一直在关注。

适用于 QA 和开发团队的现代测试用例管理软件

跨团队协作

前两个想法都集中在沟通上。但在大多数情况下，测试发生在您的脑海中：您必须考虑面前的系统，想象它可能会失败的方式，然后使用鼠标和键盘将这些想法付诸实践。一段时间后，测试相互渗透，很难区分一个测试从哪里开始，另一个测试从哪里结束。大多数技术团队成员与测试人员所做的唯一交互是通过错误报告。如果软件相当好，除了花费时间之外可能没有什么可展示的。

向其他团队成员展示测试含义的一种方法是邀请他们参与您的工作。我喜欢通过与愿意的开发人员结对来做到这一点。在之前的工作中，我们大约 90% 的时间都是结对的。开发人员和测试人员将从待办事项中选择更改并与产品经理一起审查。两人共同构建变更，并在任何适用的级别（单元、服务或浏览器）设计自动化测试。在构建和部署新容器有意义的每个点上，他们都会一起进行探索。

我喜欢这个流程，因为它很高效，并且当配对完成后，更改就可以投入生产了。但这也消除了测试的神秘面纱。单元测试是一起设计和构建的，探索是一起进行的，在变更结束时，会审查测试覆盖范围以查看是否缺少任何内容。这是可见的测试。

变得可见

让你的工作更加引人注目的第一步是谈论你所做的事情，所以你的日常站会可能是一个很好的地方。不要掩盖你工作的细节，而是挑选一些人们可能感兴趣的内容：你正在探索的风险、你必须执行的技术任务、你想与之交谈的开发人员。之后，选择您想要分享的工作的具体要点——测试覆盖范围、测试设计、规划——并找到相关受众。