篇前话

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

本文由职坐标整理并发布，希望对同学们有所帮助。了解更多详情请关注职坐标软件测试之测试管理频道！