大家好！我是奥利弗。最近我加入了Dunelm的质量团队，担任SDET一职。SDET是“软件测试开发工程师”的缩写。这个职位几乎有一个被广泛认可的含义，但除此之外，我一直在苦苦思索我的角色到底是什么。长久以来，我花了很多时间纠结于这个问题。我曾在半夜惊醒，满身冷汗；我曾有过强烈的冒名顶替感，甚至有一度几乎陷入了斯德哥尔摩综合症。多年来，我与同事们开了无数次会议，不断探讨如何最大限度地提高团队的效能。现在，亲爱的幸运读者，我将与你分享一些我从这个被焦虑驱动（半开玩笑）的职业中学到的东西。

我的自画像

当我提到SDET时，我把所有通用的“质量保证”变体都归到了其中，因为“SDET”对某些人来说只是一种花哨的说法，说明你是一个懂代码的测试人员。我也会交替使用“SDET”和“QA”, 因为作为QA，我们实际上都在做同样的工作—我们对代码进行质量检查，左移至阅读代码并提供反馈，右移至在已完成的网站上点击按钮，以至于开发人员开始主动回避你的Slack消息。事实上，该角色的主要错误观念之一是认为懂得编码就是万能的。编码只是一种完成工作的工具而已。质量不仅仅是编写成千上万个自动化测试用例以确保某个功能正常—它还要确保考虑到细节。这种想法弥漫于技术的各个方面，从游戏到应用程序、网络，甚至包括像CI/CD流水线这样的内部工具。我相信你使用某个软件时可能会有这种想法：“是的，它可以用，但是总觉得不够完善”。作为一名SDET，我发现推动软件变得更加“完善”这一责任悄然落在了你的肩上，而定义好你在团队中的角色将使你在这方面发挥最大的作用。质量始终是整个团队的责任，但作为SDET，你是推动者。

我对这个角色的很多焦虑来自于缺乏明确定义。在普通的敏捷开发团队中，角色分工非常明确。所有的敏捷团队至少会有几名开发人员、一个产品负责人、一个敏捷教练/项目经理，以及一些形式的QA（手工测试或是其他形式）。经典的“瀑布式”QA通常只是等待开发人员完成代码编写，然后将其传递至下一阶段，并希望不会再流转回来。QA知道他们的职责所在—确保项目整体按照预期运行。然而，作为“敏捷”中的SDET，必须比当前的迭代周期和即将在其中构建的内容，更加超前一步。在我之前的角色中，我所做的最好的事情就是制定了一项策略，概述了我如何融入团队，以至于当我进入Dunelm时，这实际上是我做的第一件事情。

我的策略通常可以归结为我在某个文档中记录的几个要点：

在每日站会上，开发人员总是有一个他们正在进行的清晰明确的任务，而作为SDET，尽管你很忙，但你的工作有时候似乎是看不见的。在我们目前所处的敏捷模式中，QA人员可以并且应该尽早参与到开发过程中。作为SDET，对团队的主要贡献之一是在任务生命周期的早期就积极参与其中（测试左移，这是另一篇文章的内容）；根据经验设计测试用例，并制定验收标准，以确保所需功能与相关人员所期望的完全一致。这也是一个很好的机会，可以明确任何可能需要编写的“高级别”测试用例，例如端到端（E2E）或冒烟测试，这些测试将形成独立的“SDET工作”。确保与团队达成一致，尽早引入质量保证！

策略的第二部分是与团队就每个测试层级的定义达成一致。明确团队对单元测试、集成测试、端到端测试等的理解。这将使以后的技术讨论更加容易。

比你想象的更令人困惑

尽可能合理地推动自动化，以便腾出时间来对应用程序做一些破坏性的测试。很容易编写测试用例，直到达到98%的覆盖率，但实际的最终用户并不关心这一点。如果一个客户只是随意在你的搜索栏里输入一堆表情符号，并导致你的API崩溃（并非出于经验之谈），那么在粒度层面上进行测试的数量并不重要。确保你的团队知道你不仅仅在测试/编写代码；你还在以真实用户的方式测试团队正在构建的迭代版本。

推进间接有利于质量的流程。确保在进行改进时，注重质量而不是简单地完成任务。让三人会议成为固定流程。你将负责监管看板上的所有任务。你没有逐个处理它们的奢侈条件—尽早对它们进行评估和参与。

当所有任务同时到达时—没有比这更好的感觉了

当然，以上只是我的经验，你可以对任何角色做出自己的理解。关键是要制定一份策略，并确保得到团队的支持。它使你的角色和人们的期望更容易管理，而且你可能会开始觉得更放松一点。