敏捷测试----左移右移的思考

      元旦期间发了文章《用户故事--需求实例化》，然后周一云大进行了转载《敏捷测试左移-需求实例化实践》，周三也有大神探讨了《测试左移右移还能往哪儿移 ，于是我想将为什么写《用户故事--需求实例化》这篇文章的想法，和大家再谈谈我的想法，其实叫什么不重要而是目标是什么。

       测试左移我说的是进行“需求实例化”，大神文章中的观点是“手工测试点点”，测试的岗位都是因为“开发”不够严谨而产生出来的。测试之所以需要“左移”是在鼓吹焦虑，担心被优化后不需要这个岗位，于是开始左移做PO应该做好需求的这部分的一些内容。

       对于我来说，左移是测试这个职位天然的优势和必然的质量优化路径。测试对于开发的实现逻辑、产品的需求业务流程清晰，为什么不能左移？

       需求实例化中的内容，是针对简短需求或一句话需求进行扩展，按用户故事模式进行梳理、补充。需求在业务流程上，从模糊不清到团队能理解的用户故事；在系统架构设计上，从开发团队关门梳理分析、设计到整个团队一起进行软件梳理分析、设计。当然大多数公司现状软件设计都是开发自己负责，很少有其他部门介入。

       我们分析下软件产品是如何被开发实现的？首先基于对需求的了解，对软件未来有一个较清晰的认识，相对处在一个较可控的范围之内就可以进行了。然后开始做软件设计，一般软件设计都会先建模输出抽象模型，然后在这些模型上进行文字等说明形成设计文档，在依据这些设计文档进行实际开发工作（UML建模，不包含UI）。

       模型这东西是对客观存在的一种抽象，比如我举的“快递员放快递至快递柜，用户取件”的用户故事，这里面场景是：有个快递柜可供快递员放件，用户可以取件。

       而这个场景下的对应的是：

       1）快递员如何放快递

       2）哪些快递柜可以放

       3）快递公司如何管理快递单派件信息

       4）用户如何获取取件信息

       5）用户如何取件

       6）快递公司与快递柜之间费用关系

       7）快递公司快递单履约完成通知

       …….

       这些客观问题的抽象，就是各种功能及其关系，各种模型对象及其关系，各种业务处理流程，各种数据交互映射。开发要做的是将这些客观问题编码实现出来，对于软件来说其实就是由一些主要类，不同类组合成对应的一个个服务，不同类与组件之间进行依赖协同，基于不同业务框架进行数据调用，然后发版测试通过后上线。

       现在“测试左移”在行业内被大家提及及认可，是因为在现实环境中用户对我们研发交付的速度、质量要求越来越高。而我们大多数研发模式还是瀑布模式或敏捷研发模式，在这这种环境下，身处研发团队作为“测试”的我们，能做些什么满足用户的真实需求了？

       所以我进行了“测试左移”，进行需求实例化。在整个实例化过程中，我们将整个团队有机关联在一起，将模糊不清晰的目标进行梳理，逐渐确定了我们的共同目标：   

       首先我们这个需求或版本共同业务目标到底是什么，是不是MVP；

       其次是共担责任，无论需求梳理不清晰，理解不透彻或生产环境有BUG，用户不认可等，这些都是整个团队一起输出的共同结果，大家的整个心都是贡献出来了，而不是如PO需求没写，我不知道有这个流程，测试没发现等；

       最后是学习或者说赋能，PO将业务梳理、分析的思路告诉团队；DEV将业务关联、数据传递、通信链路告诉团队；TEST将用例设计、质量保障方法告诉团队。

       在这种团队下的我们已经不再以各岗位、职能去进行单一的“部门墙”思想，打破了大家不说“人话”的局面，我们会日益形成自治的团队。

       在需求评审时我们的需求实例化是否为后面的开发、测试、产品持续沟通过程消除了浪费？

       我们将一些隐患或未来的风险提前规避，这从某种层面上来说是否将质量事故消灭在发生之前。

       需求永远是我们的源头，开发基于此进行研发，测试基于此进行用例编写，进行质量反馈。而在需求实例化过程中是可以引入质量内建的，如实例化过程中测试从哪些角度、使用哪些方法、方式进行，开发知道了是否可以在编码过程中刻意重视？毕竟知道了这个功能测试会以某种方式进行检测，开发应该不会忽略吧？

      需求实例化在我理解中，除了是让研发团队（产品、开发、测试）开放、投入的讨论出共同业务目标、责任共担、赋能外，还有我们在研发过程中持续改进、持续优化的思想。

       测试基本都是发现问题，解决问题，这种动作与行为是否和精益思想中的持续反馈有点类似？精益下的持续反馈是通过不断的降低库存，来发现问题和解决问题，且永不休止的消除浪费和持续改善。

       而测试给大家的普遍认知是从需求到研发，从研发到上线的测试过程中，发现问题、消除问题，这不就是持续反馈么？

       这时我们在做端到端的反馈，在这个过程中进行左移、右移、上移、下移的目的是什么？为了提升技能、学习么，不否认。但更多的是为了软件产品的持续高速高质量交付，因为我们是一个团队，消除个体只能的属性，融入团队，实现团队为我，我为团队的高度集中思想。