Scrum团队由比测试人员更多的开发人员组成/>
有一些针对多个用户流的E2E测试要求。在E2E级别上进行了一些回归测试
其中大多数在上游/ UI上进行了更改，因此自动化并非总是一种选择；组件级的新功能正在添加，需要进行功能测试；这些测试的自动化；文档
，因为测试和步骤领域通常包含新的领域和复杂的环境设置
尽管理想情况下，产品经理也可以添加质量检查的技术用户案例，但大多数时代，此类自动化积压案例没有比其他测试任务优先
由于上述原因，在大多数情况下，质量检查人员需要集中精力进行大量的手动测试。
并且因此，自动化就倒退了。
有时功能需要尽快推出，以至于自动化倒退。
问题1：
在这种情况下，团队如何管理应对自动化的问题？
问题2：
我们要做的一件事是要求开发人员帮助完成自动化（针对他们未编码的功能） 。但是，由于以下原因，发生了两件事：
QA没有机会提高自动化技能组
由于QA不再进行自动化，（性能评估的标准）质量保证在评估过程中受到负面影响
如何处理这种矛盾的情况？
#1 楼
您认为这是不可能的！并不是的。这是完成此操作的方法。简短而甜美。QA涉及故事。您可以决定在冲刺计划/优化中是否需要对故事进行任何自动化。包括QA在内的每个人都知道将要付出的努力。因此，您指出他们要牢记这一点。而且，您提到作为完成自动化需要接受的标准。
从技术上讲，对于所有新功能，您都应该编写端到端测试，如果是这样，则不需要其他回归套件，因为可以进行一套拟合
“因为测试和步骤的领域通常包含新的领域和复杂的环境设置”：您不应该编写任何不能完全自动化的自动化测试。因此，此业务情景仅保留手册并创建文档。而且，我忘了提一下，当您编写自动化即测试计划时，无需编写手动测试计划，而您会完全专注于该功能的自动化。通过工具生成报告的方法有很多。
质量保证不能放任不管：因为从技术上讲，敏捷中没有指定的角色作为质量保证。他们都是团队成员，如果故事在质量检查通道中变得越来越重，则开发人员必须加紧并清理质量检查通道。而且，如果您在没有给质量检查人员足够时间的情况下就发布了故事，或者质量检查无法完成它们并且您想让它们消失，那么故事指向当然会出问题。它们的指向不正确。
选择与应用程序体系结构一起使用的自动化工具和语言。例如，如果您是Java商店，请选择依赖Java的工具（Selenium with Java），以便在QA落后于Dev时可以轻松地完成并完成，重新打补丁或编写一些自动化测试案例。该场景还将涵盖QA自动化技能的提高，因为它们可以轻松地从开发人员那里获得编写代码等的帮助。它大大加快了该过程。
编辑：
确保质量保证和开发人员的比例正确，否则质量保证将始终落后，因为有时编写自动化比编写应用程序要重。
评论
对于“如果故事在质量检查通道中变得越来越重，则开发人员必须加紧并清理质量检查通道” +1，这是关键。不仅是通过编写代码，而且还需要坐下来进行繁琐而漫长的环境设置（嘿，如果他们实际上必须自己这样做，您可能会突然发现有一些工具可以编写/一些重新设计可以使编写起来更容易） ）
– testerab
16年11月7日在10:44
#2 楼
如果您的管理层专注于短期回报，那么它就不会投资于提高技能来提高生产率-您还是应该在自己的空闲时间进行。所有工具和文档都是免费的，您只需花时间。当然，您的进度会慢一些，但是经过一段时间后，您应该能够显示出一些结果，向您的经理证明，为测试自动化提供更多支持对公司而言是一笔不错的投资。否则，您将获得技能，可以在具有更好未来的另一家公司（对公司和您自己）中都适用。意思是：用脚投票，换另一只手）。
评论
1.提高自我-我同意你所说的；但是，对于这样一个团队中的质量检查人员，期望他们能够做到以上所有各项，然后才能够达到绩效标准，该怎么办？那么，应该不应该进行更合理的工作分配和更好的计划，以使质量检查人员能够以可行的速度完成上述所有工作？
– Shanianp
2015年2月7日在1:26
在不同的公司中可能是可能的，或者更有可能。您需要这些新技能才能获得更好的工作。
–Peter M.-代表莫妮卡（Monica）
15年2月7日，在1:30
我不明白
– Shanianp
2015年2月7日，下午1:39
支持免费时间片。我在业余时间在老公司学习自动化，最终极大地改变了他们在质量检查中的文化。我还利用业余时间构建了自动化套件，并减少了实际“工作”所需的总时间，因此我可以进一步研究质量检查
– Paul Muir
2015年2月9日在14:19
#3 楼
您需要重新定义票证的“完成”定义。在手动测试，文档编制和自动化完成之前，票证不完整。项目经理起初可能会感到沮丧，但是当您告诉他们提高质量的手段时，赢得争议并不难。#4 楼
Scrum指南不认可单独的质量检查角色。这里没有例外；团队中有很多具有测试技能的人是很高兴的，但是这个人应该尝试与团队作为任何其他开发人员，因为质量是团队的努力而不是个人的责任。
我建议以下内容：
QA /测试人员开始使用配对编程会议，从长远来看，这将成为一个正式的团队成员。做手动探索性测试（也许要成对重新开始以使它们进入速度）
使质量成为团队的共同责任。
自动测试是完成定义的一部分，而不是您积压的事情
/>
您的首要目标是确保他们不要依赖您作为测试人员，传播技能。然后开始将您自己整合为开发人员。
最终目标是成为T形甚至更好的PI形开发人员，专业知识可能是自动和手动测试。
评论
这就是为什么自动化是开发人员的工作。这需要开发工作。