篇前话

经历过传统的软件测试工作，每天的任务就是写测试用例，跑测试用例，改测试用例，报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。来自项目实践真知，希望对大家有帮助。