篇前话
经历过传统的软件测试工作，每天的任务就是写测试用例，跑测试用例，改测试用例，报bug，验bug。测试用例和bug成了工作的核心，围绕它可以做很多学问，各种类型的测试也可以在此衍生。进入2011年，开始接触scrum的工作方式，也开始接触story，sprint，迭代周期等等的，慢慢的测试用例开始淡出。2015年元旦，加入ThoughtWorks，开启了真正敏捷QA的体验，一直听说敏捷软件开发，也一直认为之前的工作方式也算是敏捷的，实则不然。
结合之前的测试积累，以及在现在的项目中各种敏捷实践的应用，这里，我想跟大家分享的是项目中体会较深的几个敏捷QA实践。
Story Review
通常需求由BA客户反复的商讨，并做基本的整理和拆分后，会以story的形式产出。一个story会分别经过BA，UX，客户，以及QA的review，反复修改填充.
QA在这个环节中，通过review story对业务进行理解和分析，review story的AC，UI mockup，结合和现有系统的设计，对story的AC填充，加入相应的验证，错误处理，安全相关的验证点。
同时添加QA Notes，相关开发部署的环节的内容，或者经常出的bug提前标记在story里。
举个例子 story review 前和review 后：
在这个实践中，QA想的是：如何站在质量的角度，保证业务的完整性，补充业务之外的相关内容。
敏捷团队中的BA和QA一样，经常是一个人负责一块内容，这样使得BA和QA在工作中经常出现结对，互相补充和backup。
Tasking
在你现在的项目中，是否有为每一个story做tasking？
在你做tasking的过程中，是否有involve QA？
Tasking - 是在story kickoff之后，把story拆解成可以逐步实现的步骤，可以采用SBE的方式，保证每一步的实现都是可交付的，当然也有steps的方式。这两种方式都无可厚非，两种方式不做过多比较，毕竟story已经是客户可接受的最小交付对象了，story开发中，不同的dev开发方式和习惯不一样是可以理解的。
第一种，拆解成steps的方式：
1. 包含了前后端的验证
2. 同时包含了一部分dev 设计的步骤（蓝色标记框）
3. 基本是遵照从前端到后端逐步开发的思路
4. 按照用户的基本操作习惯，全面考虑各种case。
第二种，类似SBE的方式：同样的上面的例子，tasking之后的表现形式会是这样的：
每一条tasking item都有交付价值
每一条tasking都有自己独立的steps做分解
这样做的好处在于每做完一条都能体现出交付的意义
同样涵盖了上面一种方法的所有条目，只是组织方式和切入点不同。
QA和DEV pair tasking中达到的效果：
整理需求的逻辑，达到需求理解的一致。通常kickoff中会提到特别多的点，需要整理输出。
涵盖了所有story相关的测试point
在tasking过程中，跟dev pair，指出了在开发中可能遇到的坑，可能忽略到的点
同开发一起，站在质量的角度，从设计上考虑潜在的风险，提前预防，比如performance，security的问题，API的设计
了解开发的设计思路，帮助QA理解story的测试难度以及测试量
若遇到组里新来的开发，可以通过tasking pair帮助开发理解业务细节
在这个实践中，QA想的是：如何站在质量的角度，规避可能遇到的或者常被忽视的点。
也就是说QA在开发开始工作前，就已经把可预见的问题，bug，都已经在tasking的过程中规避了。同时，即使开发switch pair，也不担心细节的丢失，Tasking有效的保证了story没涉及到的细节点的不被遗漏。Tasking实践中，要求QA要有软件开发设计的理解力，可以跟开发沟通设计中的不足，理解开发遇到的难点痛点，并一起想办法。
Review Test
Unit Test, API Test, Contract Test都是属于测试的一部分，位于测试金字塔的下层，专注手动测试的QA很少会接触。UT，API测试，Contract Test都是属于内部质量保障，也就是代码质量的保障。QA关注产品的质量，除了外部质量，也包括软件的内部质量。UT，API测试，Contract Test是由开发人员编写的测试代码，也是QA关注的范围。所以也鼓励QA对底层测试进行了解。那么Review Test是怎么做呢：
Story signoff阶段，业务signoff之后，留下QA与DEV一起进行Review Test
QA driven，从前到后，充分掌握UT测试的逻辑链条，把控内建质量
对比UT测试和tasking list，是否每一条check point都有测试cover
前后端的测试同时需要根据需求做validation，例如字段不为空
Review之后，产出TODO list，需要修改的测试，或者遗漏的测试，或者需要重构的测试都是review之后的产出。
测试举例：
好的UT具备：
· 名字mi较强的可读性，传达的是业务意义。
· 清晰的数据准备，不相互依赖
· 清晰的测试点，verify point和description相符
· 整体结构清晰，一个UT一个测试点，一组UT相互结构清晰。
在整个review的过程中，开发和测试充分的沟通实现和测试case的设计，一方面帮助开发设计合理的测试，一方面帮助QA理解哪部分测试已经在底层做过了。
在这个实践中，QA想的是：如何站在质量的角度，组织有效的内部质量测试。构建合理的测试体系，把测试重心往底层推。
Review Test实践中，要求QA要有一定的代码能力，了解开发的设计模式，读懂测试代码，能够在Review Test中起到指导测试的作用。
构建QA checklist
你有没有发现kickoff的时候，有那么几个问题，或者几个点会重复提，例如：performance相关的用户量，例如是否要event(使用event store的话)，相信每个组都有自己组特殊的但是common的点。你有没有发现在signoff的时候，有一些common的问题被反复的在不同的story暴露，例如：button 颜色不对，忘记了排序，对齐问题等等。这个时候，敏锐的QA就会根据这样的反馈机制，建立一个checklist，把这些经常出现的问题搜集整理共享出来。可以添加到story的模版里，用来保证每个story都会过一遍这个list，把质量保障往前推。Checklist 可以包括：
· Performance相关的AC: support how many user/data
· 安全相关的AC: evil user story etc
· 是否有部署配置相关的要求：新的DB，新的site，数据migrate等
· 是否需要feature toggle
· Error handle
· 兼容性问题
· UI 问题
· 项目业务相关：类似与不同角色的权限控制
这个列表可以不断的扩展，可以来源于开发环节之后的任何一个环节多次出现的问题，也可能是经常出现的bug，也可以是技术的requirement。这个list如同九阴真经，可以帮助团队提供一个反馈平台，把后期发现的问题提前预防，避免一个问题多次出现，也避免宝贵的大脑资源记这些繁琐的零散的点。
如果你还没有这样一份checklist，建议构建一个，作为一个活文档，存活在每一个story中。
像这样，但不仅仅包含这些：
总结
敏捷QA，在敏捷软件开发实践中有自己的关注点，除了build quality in software,还需要build quality sense in everyone. 在团队中，QA需要参与到从需求到交付的每个环节，做到把质量构建在软件开发活动中的每一步。如果你还在天天做手动测试，跟bug打交道，那不妨开始想想，怎样把现在做的手动测试推到测试金字塔的合适位置，怎样减少bug的产生。
这篇文只列了四个敏捷QA实践：Story Review, Tasking, Review Test, 构建QA checklist。来自项目实践真知，希望对大家有帮助。
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
