测试自动化的所有权

#1 楼

您没有指定开发者是否已经在编写低于UI的级别的测试，例如单元/组件/ API级测试。目前尚不清楚开发人员和测试人员目前是否紧密合作。

我同意Rsf的看法，它在很大程度上取决于内部文化，技能等，只有您和您的团队才能决定。但是，这里有一些建议可能会影响您的决策：



可测试性。当人们在构建应用程序时，开发人员具有增强应用程序可测试性的强大功能。如果他们也正在构建自动化，那么他们显然有一定的动力来使自己的生活变得更轻松，但是如果团队合作良好，他们可以通过与使UI自动化的人们交谈并愿意进行更改来帮助增强可测试性。帮助-可能很小，比如添加一个id，或者更大一点，比如添加清除缓存的功能，这样就不会因为无法重置某些状态而使测试偶尔失败。讨论提高团队可测试性的最佳方法。

调查失败。如果测试失败，谁会花时间找出问题所在？如果第一个承担这项任务的人是测试人员，他们会与开发人员合作吗？他们会达到某个目标并移交给开发人员吗？那是什么意思，作为一个团队，您将优先考虑使未通过的检查再次变为绿色？ （注意：如果团队不关心修复/调查失败的测试-那么也许他们不应该花时间编写测试。）

它们运行起来有多容易？这与上一点有关。如果难以设置和运行测试，或者它们需要12个小时才能运行-没有开发人员会愿意运行它们。无论是谁编写运行在基础架构上的测试，投资团队建设都是值得的。

了解整体覆盖范围。如果您有不同的人在编写单元测试，API测试，UI测试-他们需要在某个时候进行交谈，以找出其他测试已经涵盖的内容，可以推到较低水平的内容，所有这些内容中缺少的内容真的应该被遮盖住这可能很简单，例如在过程中的某个时间进行5-10分钟的聊天，也可能是正式的审查。一切都会为团队工作。

创建一个可维护的，可靠的框架。当您了解有关所需的更多信息（并查看导致问题的原因）时，您可能会不时坐下来进行重构。即使开发人员通常不为框架编写测试，对他们来说仍然有价值吗？

我想我的主要建议是，您不应将测试自动化视为必须由一个小组或另一个小组完成的单个任务。实际上，这是许多不同的任务和技能，您既可以选择将这些任务划分为不同的组，也可以在需要时让两个组的成员配对以完成任务。除了“ //”以外，还有更多选择。

#2 楼

您必须与您的团队和公司进行讨论，这取决于内部文化，技能，日程安排甚至内部政治。

FWIW我从以下两个方面看到了成功和惨痛的结果： br />独立的基础架构团队，独立的团队添加测试用例并执行它们
与上面相同，但另一个子团队与开发人员紧密合作
一个团队将它们统统统称为“联合工程”。这可能需要专门负责维护和构建测试基础架构的团队

#3 楼

您的问题当前没有报告太多变量，例如：


有多少成员会加入团队？它们会和其他项目一样吗？
您期望有专门的测试人员和开发人员吗？还是可以更改角色？
产品所有者将专注于该项目还是与其他团队/项目共享？
测试人员是否具有编码技能？团队成员和测试人员都具有编程技能，我建议您将自动化任务分为两部分：
开发人员：他们应该编写单元测试和组件测试以确保软件核心部分的稳定性；
测试人员：他们应该编写功能测试，以确认和验证用户需求。功能测试可能包括端到端测试。

不用说手动测试是另一回事，应该单独进行管理。

#4 楼

坦率地说，这是许多测试人员的现代祸根。团队因其知识和专业领域而受到尊重。您是专门从事Webdriver测试编写工作的开发团队的成员。

在您提到的问题中，您提到测试自动化的所有权。我认为这与运行和检查夜间Webdriver Suite的结果类似。向您的团队说明，如果您度假几周，则无论如何都要继续进行日常检查。

为他们提供培训，以便他们可以在需要时提供帮助。运行任何人都不会查看效益的测试，请确保整个团队都理解。

为确保编写了自动化测试，建议您将自动化测试添加到故事的完成定义。在计划会议期间帮助定义这些内容，作为故事中需求的一部分。

在敏捷中，测试人员是BA，PO，Dev和Tester。所有的开发人员也是如此。

更改将需要时间，不要指望一夜之间就能发生。但是一旦团队看到了带来的好处，他们就不想再回头了。

这里和这里的一些好地方需要进一步阅读

#5 楼

我建议测试人员应该处理自动化脚本。由于开发人员也有开发任务，将来可能由于并行开发任务而无法维护自动化任务。

对于任何测试，预期和思维方式也完全不同开发人员和测试人员。根据ISTQB词汇表，由于缺乏客观性，开发人员无法进行有效的测试。我同意，因为开发人员和测试人员的目标和思维方式是不同的，并且它们的行为/工作方式是一样的。测试用例和场景。因此，测试人员比开发人员的测试覆盖率要高。

#6 楼

要考虑的另一件事是，如果您最终敏捷，那么选择取决于您自己。有约定，但是敏捷的目的是为了团队的最大利益。如果您决定在测试人员编写测试时最好地专注于开发工作，那么这可能是最适合您的方法。
关于敏捷性最好的部分是，它应该是团队决定可行的一切。您应该始终遵循严格的准则，并且随着团队逐渐适应最佳标准和实践，他们可以根据自己的需求进行更改。