从交付产品到交付价值

老问题的新思考

初入测试行业，基本上都会遇到一个有趣的问题面试题：给你一支笔（或者是其它的物件），你如何开展测试工作。本意上，这个问题考察的是面试人员对测试方法论的理解及思考问题的方式。可以给出很多经典的答案出来：

需求测试：查看需求说明书，看看产品是怎么定义这支笔的

功能测试：书写是否流畅、颜色是否合适……

性能测试：能否长时间书写、墨水定型的时间……

安全测试：笔壳是否足够耐摔，笔芯是否有毒……

外观测试：是否好看，尺寸是否合适……

等等等等，不一而足。

这个是比较典型的交付产品的测试思路，对于“笔”这个产品，它需要满足以上我们考虑到的信息，在这个过程中，我们关注的是对于笔的产品说明书，以此为蓝本来设计我们的测试用例，测试人员关注的是说明书是否写的足够清晰、规范，是否有变更。

在敏捷的环境中，我们关注的是交付价值，需要澄清原始需求背后客户的真实痛点是什么。比如上面的例子，我们可能需要先了解清楚的是，这笔是给谁用的（学生、老师、工作人员），在什么场景下用的（写作业、改卷子，还是正式场合的签约），可以解决客户的什么问题（方便书写、快速定型、体现专业和品牌价值）。从而设计其核心的测试用例，再辅于其它用例。这样是否可以在有效的时间内，设计更好的用例呢？

我们常见说，测试即需求？质量内建的实践之一是测试左移，为了获得更低的缺陷修复成本，测试需要在需求引入阶段就介入，即针对需求的测试。在整个需求产生的过程中，测试人员都可以参与进来，输出自己的想法，贡献自己的业务上下文和测试思路，这种行为对需求最终产生的内容或形式都可能有直接影响，所以我们在某种程度上可以说“测试即需求”。

　　那么在整个需求产生的阶段，测试人员如何帮助需求正确表达呢？具体的实践有很多：如在需求未明确时，可以帮助业务或产品梳理现有逻辑，提出预期需求；在迭代计划会议和开卡时，可以帮助补充验收标准和支撑性需求，亦或是针对界面交互和用户体验提出改进建议。

一个真实的例子

笔者在推广自动化测试平台在业务侧的落地时，遇到过一个需求：基于版本管理的需要，测试用例在进行数据驱动测试时，数据驱动文件需要支持从GIT上获取，这样可以较为方便的进行版本管理，也方便团队多人协作。当时的产品经理拿到这个需求后，内心是拒绝的，因为我们已经有了上传驱动文件的功能了。

在得知这个需求后，笔者（不仅仅是测试员，还是架构师，所以产品会找我一起确认需求）和产品一起和客户再次做了沟通，客户的想法是：当下平台只能保存最终的数据驱动文件，对于此驱动文件本身的修改历史没有做记录（从平台的角度看，不需要保留过程，只需要用户传一份最终的驱动文件就行），证券行业的内部规则要求所有的数据都要有历史记录可追溯。所以他们需要通过GIT来保存数据驱动文件，也符合一切资产代码代的要求。经过沟通后，和产品一起再次评估，觉的此需求合理，应该给于满足。于是实现了此功能。为此还开发了GIT配置功能，用于不同的用户连接不同的GIT分支。最终交付了此功能，并与客户简单讲解了整个使用配置过程，得到了客户的认可。

来看一下，在这个过程中笔者做了什么：

　　需求澄清——基于业务上下文的需求背景分析；

　　分析现有逻辑——提出现有逻辑的不合理性；

　　提出支撑性需求——为满足需求，增加额外的功能支撑；

　　关注用户体验——做好功能交付及业务培训。

另一个例子

在信通院的自动化测试平台三级认证中，原来有这么一条：自动化平台需要有录制回放功能。这条要求的价值主张在于通过一些自动化的方式能够直接生成用例，让平台的可用性更高。但是实际的自动化平台中，我们很多时候并不需要录制回放功能（很鸡肋，懂的都懂），完全可以通过其它的方式来实现（如接口平台可以通过接口分析自动生成基础用例，UI自动化可以通过自动解析页面HTML结构树来自动生成元素），如果只是为了平台过级而去研发这个功能，意义不大。因此，笔者建议去掉此内容，经过各位专家的讨论，认可了本意见，所以在本年度（2021年）的信通院 DevOps自动化平台能力成熟度模型认证中，已经去掉这条内容（笔者是该项目的参与者，此标准为DevOps平台的建设提供了一个方向，有兴趣的可以自行查询）。

以上两个例子，都是基于价值主张的思考，来解决实际问题。在测试左移的大环境下，测试人员应该更深入的去探讨需求背后的真实价值是什么，多思考，多讨论，而不仅仅是按需求完成对应的测试任务。提升整个团队的交付价值，不仅仅是产品需要思考的问题。