软件测试自动化工程师（SDET）在现代软件开发中扮演着重要角色，作为开发和测试之间的桥梁。这一角色的组织位置——它应该位于开发（DEV）团队中还是集中式的QA团队中——一直以来都是一个备受争议的问题。作为一名测试自动化工程师，我曾在两个团队中工作过。基于我在开发团队和集中式QA团队中的经验，我会在这篇文章中提供一些我所认为的测试自动化工程师在团队合作中的最佳实践。
瑞典团队中作为软件开发测试工程师 (SDET) 工作的好处既然测试自动化流程与开发流程没有区别，因此单独考虑它们没有意义。测试自动化是一项纯粹的技术任务，需要大量的技术和技能。因此，开发团队应始终支持测试自动化及其知识的传递。简而言之，作为SDET开发团队的一员，有许多优势可以使技术流程和协作更快、更有效。
让我们更详细地看看这些优势。
紧密合作与沟通- 直接与开发人员接触: 在我作为开发团队成员的日子里，我与开发人员建立了牢固的关系，并能够快速直接地获得他们在测试自动化任务上的支持。我成功克服了许多单靠自己无法解决的任务，这也得益于开发人员的直接支持。例如，我们与开发人员一起创建了一个用于模拟其他系统所有依赖关系的测试库，以便在隔离中测试系统，并将其作为模拟系统，至今我们还在测试中使用它。我还迅速解决了测试自动化过程中遇到的问题。
- 消除官僚作风: 官僚作风是敏捷方法的敌人。在开发团队工作时，有关工具许可证和其他测试自动化所需资源的请求得到了迅速处理，因为团队共同拥有问题并共同创造解决方案。因此，测试自动化流程没有受到团队间官僚作风的制约。
- 测试自动化流程自然融入了开发团队的工作流程中，并且优先级逐渐增加。同时，开发团队承担了满足测试自动化期望的责任，并通过团队协作解决了现有问题。
- 在冲刺计划中加入测试自动化任务后，个人工作负担得以减轻，鼓励团队成员共同承担职责。由于我作为测试自动化工程师是DEV团队的一员，我经常能够与开发人员一起连续数小时之久解决测试自动化问题。这种工作在规划工作流程和分配任务时被充分考虑。因此，测试自动化不再是SDET的单一责任，而是整个团队的合作任务。
有些人可能在这里会有疑问。这不会使他们本已沉重的工作负担变得更重吗？面对测试自动化问题，开发人员需要应对的任务已经很多了。
这是一个确实相关的问题。如果所有在测试自动化过程中遇到的问题都能由SDET解决，那么DEV团队就不用处理这些问题了，那当然是理想的情况。
但这并不可能。因为在测试过程中遇到的问题通常与基础设施、被测应用及其可测试性密切相关，无论SDET的知识和技能如何。在这种情况下，向开发人员求助是不可避免的。无论如何，认为SDET能独自解决所有问题的方法是不现实的，也不符合敏捷等方法论中的实践。另一方面，正如我上面试图解释的那样，当开发人员处理测试自动化问题时，并未将此视为额外的工作负担，相反，这些责任已被纳入业务规划过程中。因此，我可以轻松地说，当SDET是DEV团队的一员时，这种工作计划可能比其他情况更轻松和有效。
个人成长与职业发展- 培训机会: 如上所述，测试自动化是一项技术性强的工作，离不开开发过程。它需要定期培训和知识分享。与开发人员紧密合作，我有机会学习新程序和工具，并直接参与开发团队的知识共享。我还能够和开发团队一起参加各种培训。
- 共同目标: 年度目标通常包括开发人员和测试工程师的共同目标，从而提升测试自动化的质量和工具的水平。
质量优先度下降： 在开发团队里，开发流程总是优先考虑。测试流程常常因为开发团队的交付时间而被置于次要位置。这种情况在测试自动化中尤为明显，这是不好的。谨慎创建可复用的自动化测试。有时这会迫使开发流程加快测试自动化进程，质量优先度可能因此被忽视。我在开发团队时最常见的问题是，主要路径测试被自动化，而否定测试和验证测试往往被忽视。然而，大多数bug都是通过否定测试发现的，因为开发人员通常不会在主路径上出错。
缺乏标准、工具和流程管理：独立于中央QA团队的SDET的最大劣势是项目间缺乏统一的标准。每个团队自行定义测试流程导致了不同团队间的一致性问题，难以达到高质量标准。想象一下，存在多个开发团队，不同的SDET负责不同的开发团队。这通常会导致测试自动化框架、测试用例编写方式以及测试执行策略等方面的差异。这给知识传递和标准化带来了巨大风险。乍一看，如果各个团队采用各自的测试自动化方法也能取得效果，似乎无妨。然而，控制、改进、维护、向新同事传递以及保持测试自动化流程的标准至关重要，这些是必不可少的。
中心化质量保证团队对SDET（软件开发工程师测试）的益处中央质量保证团队通常是一个独立的单位，负责组织内所有项目的质量保证活动和开发流程的标准化，并控制测试实践。
作为一名软件测试自动化工程师，我在我们公司的一个集中质量保证团队中工作。我想这样来解释我在这个过程中所做的贡献。
接触到广泛的知识和项目搬到我工作的公司集中QA团队后，最先改变的是我拥有了几乎所有项目的信息。通过我们每天的会议，我对公司在质量保证方面的活动有了全面了解。同时，我也参与到多个项目的测试自动化工作中。在DEV团队时，我们只了解自己负责的项目，而QA团队则大大提升了我们的知识水平。这让我从质量保证的角度，对公司内所有项目有了更全面的了解，并将测试自动化的优点推广到更广的范围。
细致入微的测试工作在与开发团队合作期间，我的主要关注点是开发测试自动化框架。在开发团队的热情和协作下，我更多地专注于开发工作。当开始与集中式的QA团队合作时，我的这种视角发生了变化。与QA团队合作时，我开始更多地关注测试导向的测试自动化流程。这让我能够扩大自动化测试的覆盖面。除了专注于测试自动化，我还有更多机会关注测试相关的流程，如测试用例、测试计划、测试理念、回归测试和验收测试。因此，我努力使测试自动化与这些流程相匹配。
合作与技术转移定期的知识分享在集中的QA团队内帮助我们获得新的知识和技能，同时也优化了测试自动化。在这个过程中，我有机会与我的队友分享我的测试自动化知识，并合作分配任务。同时，我也从我的队友那里学到了新的工具，这进一步增强了我的知识和技能。
测试自动化的流程标准化我认为说测试界存在概念混淆并不算过分。然而，我觉得这是完全正常的。在不同的公司中，你可能会看到这些基本概念有不同的定义和实现。虽然ISTQB在标准化所有测试概念方面做得确实很出色，但在实践中这仍然主要是理论层面的。不同的组织仍然使用不同的定义和实现方式。正如我之前所说的，每个组织根据自己的特定需求和挑战来定义测试流程是很自然的。
当我开始在中央化的QA团队工作时，我非常重视这些定义。诸如“如何编写测试用例？”、“我们应该从测试计划书中学到什么？”、“测试概念应该包含哪些内容？”以及“在启动新项目时，如何规划测试流程？”等问题都被仔细地讨论。这种方法不仅在团队内部，而且在整个公司内部，为QA流程建立了一种共同语言。因此，这使测试自动化流程标准化。我认为这种标准化对于知识共享、维护、开发和执行测试自动化等方面至关重要。此外，这种标准化使得控制和审查QA工作更加容易。
作为集中式QA团队中的SDET所面临的难题。在集中式的 QA 团队工作，如上所述，有很多好处。然而，说在这种环境下 SDET 没有任何挑战是不现实的。我参与的 QA 团队实施更接近于混合方式。换句话说，我们的 QA 团队并不是完全独立于 Dev 团队来管理测试流程，而是通过积极参与 scrum 团队，力求加强 Dev 和 QA 的合作。
尽管采取了这种协作方法，从开发团队转到质量保证团队时，在测试自动化流程中遇到的一些挑战。我试着在下面解释一下这些挑战。
我们与开发团队的合作减少了一些过渡到集中式的QA团队后，测试自动化现在成了集中式QA团队的责任，这导致了与开发团队在测试自动化上的合作明显减少。尽管开发团队在计划过程中仍然会考虑测试自动化，但这种考虑并没有以前那么强烈。我还是参加所有的Scrum会议，并与开发团队合作，但是无形中却形成了明显的界限。测试自动化现在被视为另一个团队的职责。我感觉不到从前那样来自开发团队对测试自动化的支持了。如之前所述，我们曾与开发团队合作开发了一个用于隔离测试的测试库。在转移到集中式QA团队后，虽然与开发团队合作并非不可能，但可以说长期的合作努力变得更为艰难。此外，与开发团队协调以满足测试自动化技术要求的过程也没有以前那么顺畅了。
最近，我遇到了与微服务测试流程相关的技术基础设施方面的挑战。在过去，有了Dev团队的支持，这个问题原本可以很快解决。但现在，由于Dev团队的工作负担较重，他们抽不出时间来帮忙。可以理解，这个测试自动化问题被看作是给开发人员增加的负担，这使得解决问题的合作和协调变得更加困难。
行政程序如我之前所说，敏捷方法中的一个主要挑战是官僚作风，而所有敏捷实践都旨在尽量减少这一点。在转到质量保证团队之后，我开始遇到许多之前在开发团队时没遇到过的官僚障碍。以前，如果我需要访问任何用于测试的自动化应用程序或工具，团队会内部快速解决。现在，这个过程比我之前经历的要长得多。
我甚至遇到过小需求卡在团队之间的交接处的情况。由于团队的工作量，我不得不经历审批过程。当然，这是组织正常运作的一部分。然而，在某些时候，这种官僚主义会让人疲惫不堪，并降低生产力。
在我在开发团队工作时，能够参加许多技术培训和知识转移会议。转到其他团队后，利用这些机会变得更加具有挑战。开发团队不再像以前那样频繁邀请测试自动化工程师参加技术培训和知识转移会议。
当然，如果你申请加入，没有人会反对你参加这些培训。然而，需要经过各种批准。此外，与测试自动化间接相关的培训课程，我没有及时收到通知。这最终导致错过了几次技术培训的机会。
在标准化与灵活性之间的平衡之前提到的合作减少的情况并非仅仅是因为开发团队。正如我之前提到的，将SDET从开发团队转移到集中的测试团队，会带来各种测试标准。这有时会让开发团队觉得他们需要严格遵守这些测试标准。
我认为，测试自动化应该完全集成到开发流程中。因此，质量保证标准不应过于僵硬，以便不阻碍测试自动化与开发流程的整合。例如，在敏捷开发中，开发人员的工作量和优先级不断调整。测试自动化应适应这种变化和动态性。
然而，成为 QA 团队的一员，有时会因为过于严格遵循标准而减少灵活性。在这种情况下，需要找到灵活性和严格遵循标准之间的平衡，必须保持这种平衡。QA 团队也必须像开发团队一样，采用敏捷的工作方式。
责任的不同一个集中的质量保证（QA）团队负责组织内所有质量控制流程。自然而然地，这也涉及团队内的任务分配。在一个集中的QA团队中，SDET可能会遇到超出测试自动化的工作量，这可能导致他们不再专注于自动化任务。测试自动化是一项专门的任务，增加额外的责任不仅会拖慢自动化进程，还可能降低其质量。
我经常看到许多同事试图同时处理自动化测试和手动测试。就我个人而言，我认为这么做是行不通的。自动化测试和手动测试需要不同的知识和技能。手动测试者的工作量和工作流程可能没有足够的时间来处理自动化。另一方面，专注于自动化测试的软件开发工程师（SDET）在处理手动测试流程时可能不像专业的手动测试员那样有效。
在我所在的集中QA团队中，我们将手动测试流程和自动化的测试分别处理，并使它们互相帮助。这种做法可以使每个人都在各自的领域内高效工作。
另一方面，正如我之前提到的，作为中央化 QA 团队的一员，不可避免地会带来新的职责。在我的情况下，这指的是性能测试。除了测试自动化，我开始参与到性能测试中。由于性能测试对我来说是全新的领域，团队提供了足够的时间和资源支持让我学习和应用。
虽然学习新技能无疑是一件好事，但在性能测试上花的时间让我不太关注原本的测试自动化。
成功实施SDET角色的关键考量SDET角色的一种常见实现方式，也是我目前参与的一种，或许可以称为一种混合模式。在这种情况下，有一个集中的质量保证团队，SDET虽然是该团队的一员，但与开发人员紧密合作，并参与敏捷Scrum会议。虽然这种模式有很多优点，正如我前面所解释的，它也带来了一些挑战。
在这里，我想问为什么SDET角色一定要归属特定的团队。为什么一个本质上是跨职能团队成员的SDET会被限制在一个团队内？从这个角度来说，我想谈谈一些关于如何定位SDET角色的重要考虑点，接下来我会详细说明。
跨越职能的思维: SDET 角色不应该只属于任何单一团队，而应与 QA 和 Dev 团队紧密协作。这种做法打破了团队界限的限制。此外，SDET 角色确保与 QA 标准一致，同时有效地将测试自动化融入开发流程。
在这种情况下，SDET（软件开发测试工程师）应该参与两个团队的所有敏捷 Scrum 会议，同时作为 QA 和 Dev 团队的一员，并起到连接两队之间的桥梁作用。
共同目标: 避免团队边界限制同样重要，确保SDET角色不仅限于任何一个团队，而是成为开发和测试团队共同目标的一部分，这样SDET可以与开发人员在共同目标上保持一致，促进持续的合作。同时，分配给SDET的任务也鼓励其在测试自动化方面保持与测试团队的标准一致。
左移测试和动态角色适应： 测试自动化应从项目的早期阶段开始就被考虑，并融入到整个开发流程中。必须消除任何阻碍SDET角色在设计和规划阶段与开发团队合作的障碍。此外，软件开发测试工程师角色应适应敏捷工作流，平衡解决开发团队的即时需求和质量保证团队的长期需求的工作。
培训和知识共享: SDET角色应该被鼓励参加由开发和测试团队组织的所有培训和知识共享活动。这将增强他们的技术知识和技能，同时提供从质量保证的角度了解项目的见解。在这些培训和知识共享活动中，两个团队都应该把SDET视为自然的团队成员。
透明沟通： 虽然SDET角色与两个团队紧密合作有助于透明沟通，但这可能还不足以实现透明沟通。SDET应该与两个团队分享与自动化测试流程及其当前状态相关的反馈。他们必须确保向开发和测试团队清晰透明地分享自动化测试流程及其当前状态的信息。
SDET决策流程图自动化测试开发工程师决策流程图
当然，SDET（软件开发测试工程师）角色的定义在不同的组织中可能会有很大差异。以下是，我将尝试将之前提到的所有场景总结成一个结构化的算法。
第一步：先看一下组织结构和项目情况
首先，必须分析组织和项目的规模与需求。在较大的组织中，团队和角色会更加专业化，这无疑会对SDET角色的定位产生影响。
第二步：确定开发生命周期的方法论
这一步骤侧重于在开发周期中使用的方法论。是否使用了敏捷开发，还是使用了其他的方法？这也影响了SDET的角色定位。
第三步：评估跨职能团队的使用情况
在第三步中，应该评估是否会在项目中采用跨职能团队的方法。我认为，如果可行的话，SDET 应该扮演一个跨职能的角色。
步骤4：如果没有跨职能团队，则确定左移测试的优先级
如果无法组建跨职能团队，另一个问题就是：左移测试是否被优先考虑？
- 如果答案是 是的，那么SDET角色将最受益于位于 开发团队中。
- 如果答案是否 否，算法将继续提出 下一个问题。
步骤5：评估质量保证的关注点
测试是否更侧重于更广泛的质量保证目标？
- 如果是是，SDET最适合的位置是在QA团队内部。
- 如果否，算法会继续检查工程师的能力。
第六步：评估双重角色的能力
测试自动化工程师能不能同时担任两个职位？
- 如果 是 ，则 混合方式 会是比较合适的选择，此时SDET既可以为DEV团队也可以为QA团队工作。
- 如果 不是 ，则更适合放在QA团队。
在这篇文章中，我基于不同定位，解释测试自动化工程师的角色优缺点，并探讨它应如何融入开发和质量保证团队以实现更有效的协作。我试图总结并分享我认为是最佳的SDET角色定位方法。
自其出现以来，SDET的角色及其在测试自动化中的作用经历了重大的转型。其职责以及对QA和开发团队的影响一直在不断演变。毫无疑问，这种演变将继续，这让我们再次思考如何最有效地定位SDET角色，以尽快发挥其最大效益。
共同学习，写下你的评论
评论加载中...
作者其他优质文章
