从交付产品到交付价值
功能测试：书写是否流畅、颜色是否合适……
性能测试：能否长时间书写、墨水定型的时间……
安全测试：笔壳是否足够耐摔，笔芯是否有毒……
外观测试：是否好看，尺寸是否合适……
等等等等，不一而足。
这个是比较典型的交付产品的测试思路，对于“笔”这个产品，它需要满足以上我们考虑到的信息，在这个过程中，我们关注的是对于笔的产品说明书，以此为蓝本来设计我们的测试用例，测试人员关注的是说明书是否写的足够清晰、规范，是否有变更。
在敏捷的环境中，我们关注的是交付价值，需要澄清原始需求背后客户的真实痛点是什么。比如上面的例子，我们可能需要先了解清楚的是，这笔是给谁用的（学生、老师、工作人员），在什么场景下用的（写作业、改卷子，还是正式场合的签约），可以解决客户的什么问题（方便书写、快速定型、体现专业和品牌价值）。从而设计其核心的测试用例，再辅于其它用例。这样是否可以在有效的时间内，设计更好的用例呢？
我们常见说，测试即需求？质量内建的实践之一是测试左移，为了获得更低的缺陷修复成本，测试需要在需求引入阶段就介入，即针对需求的测试。在整个需求产生的过程中，测试人员都可以参与进来，输出自己的想法，贡献自己的业务上下文和测试思路，这种行为对需求最终产生的内容或形式都可能有直接影响，所以我们在某种程度上可以说“测试即需求”。
那么在整个需求产生的阶段，测试人员如何帮助需求正确表达呢？具体的实践有很多：如在需求未明确时，可以帮助业务或产品梳理现有逻辑，提出预期需求；在迭代计划会议和开卡时，可以帮助补充验收标准和支撑性需求，亦或是针对界面交互和用户体验提出改进建议。
笔者在推广自动化测试平台在业务侧的落地时，遇到过一个需求：基于版本管理的需要，测试用例在进行数据驱动测试时，数据驱动文件需要支持从GIT上获取，这样可以较为方便的进行版本管理，也方便团队多人协作。当时的产品经理拿到这个需求后，内心是拒绝的，因为我们已经有了上传驱动文件的功能了。
在得知这个需求后，笔者（不仅仅是测试员，还是架构师，所以产品会找我一起确认需求）和产品一起和客户再次做了沟通，客户的想法是：当下平台只能保存最终的数据驱动文件，对于此驱动文件本身的修改历史没有做记录（从平台的角度看，不需要保留过程，只需要用户传一份最终的驱动文件就行），证券行业的内部规则要求所有的数据都要有历史记录可追溯。所以他们需要通过GIT来保存数据驱动文件，也符合一切资产代码代的要求。经过沟通后，和产品一起再次评估，觉的此需求合理，应该给于满足。于是实现了此功能。为此还开发了GIT配置功能，用于不同的用户连接不同的GIT分支。最终交付了此功能，并与客户简单讲解了整个使用配置过程，得到了客户的认可。
来看一下，在这个过程中笔者做了什么：
需求澄清——基于业务上下文的需求背景分析；
分析现有逻辑——提出现有逻辑的不合理性；
提出支撑性需求——为满足需求，增加额外的功能支撑；
关注用户体验——做好功能交付及业务培训。
另一个例子
