敏捷中测试左移效果不佳？

某问答站看到关于测试左移成效不佳的问题，这里分享下秋草的回答

概括

题主的问题，其实不单纯是测试怎么左移的问题。所谓“测试成为瓶颈”，更多还是各种问题积压导致的。

而运用敏捷开发，并不是说你把两周进行一个迭代就叫做敏捷了。从问题中，我们可以看到，这个迭代其实还是跑成了小瀑布，还是有需求、设计、提测、测试，团队实际上并没有敏捷起来。

先分析下题主提到的诸多挑战：

敏捷确实不强调文档，但不代表迭代中的需求可以是不清晰和完善的。

敏捷实践中，在迭代开始之前，PO就应该完成了PBI清单，并和团队共同完成了需求的精炼（grooming meeting）。而迭代启动的重要条件，是在sprint planning会议上，团队共同确认了SBI以及工作量。不确定的需求是不应该进入SBI的。

当然，敏捷拥抱变化，迭代过程中需求发生变化和增补都是可能的，但并不是提倡在迭代内频繁发生，因为在团队生产力既定的情况下，变更会导致WIP工件的变化，燃尽图、速率图都会背离理想曲线。成熟敏捷团队会尽可能避免此类情况。

敏捷团队中其实没有定义开发、测试两个不同角色。也就是在敏捷中，不存在绝对的开发和测试的分工。

“Eating your own dog food” 是敏捷中实践经常提到的一句话，其实就是明确开发自测的必要性。

开发者不进行测试的敏捷，必然是伪敏捷。

这就更难解释了。

敏捷所有的原则和实践，其实根本上都是奔着打破隔阂、提升沟通协作效率而去的。如果团队内，特别是开发和测试还难以沟通，可以说，这根本就不是敏捷。

所以，先把敏捷跑成敏捷，再看测试左移的成效比较好。

题主谈到的左移是怎么做的呢？

让测试人员更早介入需求评审，也尝试编写更详细的测试计划，但效果不明显

首先我们要再强调下，敏捷团队中是不存在测试人员这个单独角色的，除了PO和SM，所有成员都是Dev Team。因此不存在让测试人员更早参与需求评审，需求的grooming、SBI 的确定，测试必然都是应该参与的。
而更详细的测试计划，这个反而是敏捷中弱化的，敏捷中更多提倡一页纸计划这样的测试策略，测试前理清6W2H即可。

所以这里所谓的左移，本来就是测试的正常操作。

即便是瀑布模式下，需求评审、测试计划也都是测试人员应该参与的。

这并不是真正的左移！

那么敏捷中，我们说测试左移，实际应该怎么做？

正常理解，当然还是需求评审、设计评审的提前参与，以及还有开发代码时和开发的结对，协助单元测试等。

但我要说，敏捷中真正的测试左移，其实不是简单把测试活动进行左移。测试活动是应该贯穿在整个开发活动中，是团队每个人都要实施和负责的。

就像跟随敏捷的推行，BDD、ATDD这些实践，左移的着手点应该是具体的业务和用户验收场景。或者更直接说，就是需求本身。

测试左移，更多应该是测试人员作为团队中一个质量视角的存在，从最开始（PO产生需求开始），就注入质量和风险控制基因，并协助整个团队建立和普及质量意识、进行风险管控的一系列活动。

单独靠某个测试角色就提升质量和效率，本是空谈。只有团队全体重视质量、从最开始就把风险规避贯穿到所有活动才是根本。