组建Scrum团队应包括开发用户故事所需的所有技能，以便在每个sprint中交付潜在的可交付产品增量。 ，我总是遇到对Scrum团队中测试人员集成的根本不信任。相反，将保留一个单独的测试团队，然后负责回归测试，负载和性能测试以及测试自动化。这种类型的组织的基本原理是测试人员的所谓独立性。 Scrum使团队对结果完全负责。 “独立”测试团队的建立假定Scrum团队没有履行职责，对产品增量中的错误视而不见。
独立测试团队的另一个危险是测试人员成为不参与消除问题的测试报告的报告人。问题解决者。 Scrum团队中的测试人员以及负责交付完美无缺产品增量的所有开发人员，在发现错误时将竭尽全力对其进行修复或修复。该团队中测试人员的另一个优势是可以轻松实现与用户故事的实现同步进行自动化测试的问题。所描述的过程已经显示出问题的一部分：新产品待办事项的交付时间增加到几个Sprint：1个Sprint实施加1个Sprint延迟测试（可能还有另一个Sprint纠错，如果不幸的是，这不再可能），而没有打破当前冲刺的承诺，并认为重要性不高）。这导致了进一步的问题：是否需要2完成的定义？ PO什么时候取物品？他会脱两次吗？部署团队需要保持多少缓冲区才能修复返回的错误？更不用说上下文切换是必要的。将测试人员和开发人员联系在一起，并尝试避免错误而不是发现错误（具有1个sprint偏移）？等等等等
如何改变这个问题？
#1 楼
我已经在SAFe框架下的sprint + 1系统中进行了测试。该框架并不专门针对此问题，而是适合于来自瀑布的组织。穆建议：
停止它
您对
的问题是否需要2完成的定义？ PO什么时候取物品？他会脱两次吗？部署团队需要保持多少缓冲区才能修复返回的错误？更不用说上下文切换变得必要了。将测试人员和开发人员联系在一起，并尝试避免错误而不是发现错误（具有1个sprint偏移）？等等等等
加上我要添加的内容，例如：
如何保持代码库正确分支？如何使代码与环境保持同步？如何通过多个环境以及测试和流程来管理部署？如何记录错误？
当我发现上面的文字时，我会停下来并回到：
过程和工具上的个人和交互
软件胜过全面的文档
客户合作胜于合同谈判
响应计划变更
尤其是
过程和工具上的个人和交互
/>
测试是sprint + 1正在引入整个过程，而不是个人现在在做工作并互相交谈。这种设置将不可避免地导致“测试团队成为开发的敌人”，这就是您所发现的。正是
，您需要不断强调改变这一点的重要性。这是一项投资。这将减慢本周的开发速度，并在X个月内加快速度。需要长期领导才能，并且可以来自组织中任何有权干的人。
如果您不能更改设置，我建议采取以下措施：
首先编写失败的测试（BDD）
为自动化工程师公平地付款
向开发人员传达测试的好处
研究应用程序和自动化工程师之间的关系
应用程序开发团队中的嵌入式自动化工程师
真正授权自动化工程师“拉线”，并说不，不要部署
公开谈论第二测试人员的阶级公民综合症及其避免方法
确保社交活动-午餐，聚会，午餐和学习等包括双方
将人们称为应用程序和自动化工程师，而不是“开发人员和测试人员”
#2 楼
获得一个优秀的Scrum Master，他可以使组织相信Scrum团队不应该依赖其他团队来交付可交付的软件。这是他（她）应该解决的障碍。传统组织希望在不改变方式的情况下获得Scrum的好处。即使对于优秀的教练，这也可能是数年的过程。不要放弃坦率地说，这些ScrumBut Mini Waterfalls（例如，在Sprint之后进行测试）要进行管理。优秀的Scrum领导者应该努力解决它。我认为您的想法是正确的，但是仍然需要赢得信任。看看您是否可以找到一支敢于证明您的想法可行的团队。也许会要求开发人员和测试团队花2-3个Sprint来试验您的想法。
反驳的观点是，拥有独立的测试团队是因为开发人员可以发现错误，因此开发团队可以采用捷径来进行Sprint。导致开发人员测试乒乓球和降低质量，因为测试团队也面临释放压力，并且将跳过高风险区域的低风险测试。导致发行周期变慢，整体质量降低。
Scrum测试人员应该在Scrum团队中创建一种优质的文化，指导团队成员了解如何在Sprint结束时产生经过良好测试的增量。
性能测试可以作为提高性能的单独产品积压项目。尽管在构建管道中自动化这种类型的测试变得越来越普遍。
update：
Alan Page确实说服我拥有一个单独的安全测试专家团队可能非常重要根据您的情况和风险。
评论
这很好地回答了这个问题，所以我希望我能坚持一个小的细节。您指出的更改是基于建筑质量的精益原则，而不是事后检查。对于真正关心职责分离的组织，您实际上可以一开始就保留下来，但是您的开发和测试团队中的测试冲刺人员与测试专家携手并进，以帮助开发人员提高质量。短期内，组织通常会看到在额外的层次结构分离中缺少价值，但这可能是一个好的桥梁。
–丹尼尔（Daniel）
19年4月19日在23:08
“关注职责分离”，我认为那些组织应该阅读敏捷原则。 Scrum并没有涉及他们，而是“自组织团队并相信他们能够完成工作”。走很长的路要走。 Scrum团队只有一个团队，其中应包含开发人员和测试人员。没有在同一个Sprint上工作的独立团队。 Scrum团队成员可以成为虚拟知识团队的成员，以调整实践并研究其学科。因此，测试团队可以作为社区存在，以提高质量。是管理层关心的，还是主要关注的测试人员？
– Niels van Reijmersdal
19年4月20日在7:20
这是一个公平的观点
–丹尼尔（Daniel）
19年4月20日在16:25
我在这些讨论中发现的一个有趣的方面是，在涉及微服务的好处时，现代开发意识形态主张将关注点强制分离，但是开发过程应全部由一个团队（即Scrum团队）处理。更重要的是，我经常发现一种混合方式非常有用，团队中有一些内部质量检查人员在进行开发测试，同时还与外部测试人员协调进行最终发布测试或生产错误报告验证等。蛋糕，也吃。
–弗兰克·霍普金斯
19年4月21日在13:49
#3 楼
我心里的愤世嫉俗者认为，如果能够依赖开发人员来检测和修复他们的错误，那么就永远不会发明出单独的测试团队。 ..评论
事情会改变的。为什么首先发明Waterfall？因为软件本来就不是软件。发布后，它必须可以工作，因为修复成本非常高。当然，如果您以电子芯片的形式发货。我们以前有命令和控制经理来告诉人们如何工作，现在我们有了促进者，可以使聪明的人获得更多成就。一旦有必要对周围的所有人进行领导。这不是狂热，我认为这是变革。
– Niels van Reijmersdal
19年4月21日在16:56
@NielsvanReijmersdal这仍然适用于许多软件项目，只是对于某些软件而言，修复相对“便宜”，而错误本身并不会产生很高的成本。但是就这个答案而言，Scrum团队不一定只由开发人员组成！
–弗兰克·霍普金斯
19年4月22日在18:28
@FrankHopkins同意，团队应根据需要提供尽可能多的学科，以交付有效的产品。但是希望不要将创建乒乓球或等待依赖关系的团队分开。我确实认为，变更相对便宜的软件项目的数量要比我们开发的可能杀死人的软件的数量大。一切都应该在自己的上下文中看待，是的，在某些情况下，单独的质量团队可能很有意义。我确实认为，最初的问题更多地是在传统与敏捷思维方式中提出的，而不是在具有特殊需求的利基软件中提出的。
– Niels van Reijmersdal
19年4月22日在19:23
@NielsvanReijmersdal嗯，不仅是现成的软件在其中存在错误，即使是很短的时间也会造成很大的成本，这可能是进行更严格的质量控制的一个很好的理由，在此之前，必须对任何版本进行单独的质量检查生产可以满足该质量目标。例如，任何具有用户和货币交易的内容，即很多在线游戏和赌博，都将落入此范围之内。是否有意义通常取决于公司的总体战略。
–弗兰克·霍普金斯
19年4月22日在20:43
@NielsvanReijmersdal话虽如此，我认为使用Scrum和拥有这样一个额外的质量门之间并没有矛盾。您仍然可以继续部署到进行这些质量测试的测试环境，并且可以根据需要建立使用快速通道的过程。当然，与过去相比，有更多服务可以实现快速交付，因此，在不需要这种门或重量很轻的情况下（例如，团队测试），会有更多的服务。我只是觉得，我们不应该犯这样的错误：对每个人严格应用一种新的酷炫新模型
–弗兰克·霍普金斯
19年4月22日在20:47
#4 楼
相信你的感受，卢克。严重的是，您描述的场景是反模式。他们根本不准备放开瀑布。当他们意识到不再需要现有的服务时，他们可能会担心测试主管以及经理和测试人员之间的恐慌。
但这确实是二进制的东西。您要么持续测试（所有开发团队成员）并保持敏捷，要么将其交出并保留下来。他们想要哪个？
#5 楼
如果您无法一次完成一个PBI，则它太大了，需要将其拆分成较小的部分。完成PBI意味着它必须是可装运的并符合您的DoD，这通常意味着它必须经过测试。
完全没有理由为什么一个团队无法在相同的sprint中进行构建和测试。如果您有良好的DoR，那么测试人员可以在构建代码时开始准备测试，并且可以在几分钟内完成这些测试-剩下很多时间来修复所有发现的缺陷。 />回归测试，负载测试，集成测试与交付增量的速度相同。
如果您不能按时完成编码以允许在sprint中进行测试，则您的PBI太大，团队应该考虑考虑较小的增量。
单独的测试团队应该不能发现实际的缺陷：为什么您的团队提供了不符合规范的东西-这似乎是国防部最重要的部分？
如果在发布过程中弹出新的规范-sprint测试，它们是新的愿望，可以像其他任何更改请求一样处理。如果发现与原始规格的实际差异，则不应认为您的PBI已完成。为了检查您团队的工作是否符合要求，您需要进行...测试！这意味着，即使有单独的测试团队，您仍然需要自己的Scrum团队中的测试人员。
#6 楼
如果您无法解决问题，请尝试让利益相关者，您（以及您的团队*）和公司管理层都满意。实际上，我经常发现混合很有用，团队中有一些内部质量保证人员在进行开发中测试，同时还与外部测试人员协作进行最终发布测试或生产错误报告验证等。
这样，您就可以吃蛋糕了。
您的团队是负责任的，可以使用团队内部质量检查专业知识来帮助开发人员查找错误，
但它使用现有的公司资源来完成更大的任务。
通过这种方式可以设置发布/生产测试，这也迫使您能够将您的产品/新功能移交给外部合作伙伴，以确保文档是最新的。基本上，要确保为所构建的产品提供适当的界面文档，并请具有独立思维模式的人员重新检查产品。
Btw。您应该完全避免与产品相关的其他任何一方自动取消您对产品的所有权或责任。您不会在团队中进行安全的笔测试，也不会认为笔测试器是您的敌人（我希望！）。进行外部测试（在内部测试之上）只是要承认，由于您如此根深蒂固地了解产品以及产品的工作方式，因此您可能看不到所有内容，因此您可能会忽略一些问题，以至于某些人只是看表面。是否需要该质量水平，如何最好地实施（自动还是手动等）都是细节，但是原则上您不应该受到某种方式的攻击，因为公司希望（也）希望外部测试人员来看看您的产品。
*我会很谨慎，因为假设您对团队应该如何在Scrum中工作的愿景得到了团队的支持，但并没有与他们澄清。
#7 楼
如何使编程团队的一名成员担任测试员（或质量改进员）一两个月，然后将他们轮换出给团队的另一名成员（已在另一条评论中提到）呢？与“普通”测试人员不同，他们不仅会更好地了解要寻找的内容（例如，在代码级别），而且能够帮助自动化测试-需要调试和编码标准，并采用自动测试来捕获软件期间的错误开发，等等。他们还需要评估内部测试的有效性，即例如，是否保留更改或保留更改，或者更改期限更长或更短，或者更改权限变大或变小。这是真正的推动者，因为它将确保仅推动那些不受欢迎的更改，这些更改实际上显示出积极的结果。得分高的人甚至可以摆脱旧的程序来确保质量，但如果他们认为不再需要新的措施，就可以简化流程。质量提高后，测试团队成员可以每隔一秒钟旋转一次。届时，人们将习惯于这种干扰，这可能会增加更多的想法，这取决于他们的设置容易程度，可以直接完成，也可以由下一个程序员测试这些事情。
评论
让其他人测试您的代码的目的在于，他们将尝试您没有的东西，因此，当您解决问题时，他们可能会发现您和您的团队无法提高软件的质量。