敏捷测试象限之Q2

本文章转载于搜狗测试

敏捷测试象限矩阵

具体敏捷测试象限分为支持团队、评价产品、面向技术、面向业务四类型。象限编号的顺序与不同类型的测试何时完成没有关系。

象限一代表测试驱动开发（TDD），是一个核心的敏捷开发实践。这些测试不是让客户使用的。内部质量不是通过客户判断的，而是由程序员定义。

象限二的测试也支持开发团队的工作，但是在一个更高的层次上。他们确定外部质量和客户需要的功能。

象限三属于评价产品的面向业务测试，是真正模拟真正用户，使用实际运行的软件进行测试，来验证是否达到期望。

象限四属于评价产品的面向技术测试。测试的目的是评价产品的性能、健壮性和安全性等。

支持团队的面向业务的测试Q2

根据小编的理解，支持团队的面向业务的测试主要是分为两部分：

用户故事测试

测试人员帮助引出各个故事的示例和情境，帮助客户端编写故事测试。

采用用户故事测试，所用的工具会比较多，如：思维导图、流程图、核对表等

小编曾经接触过一个团队，采取的就是测试用例驱动开发的敏捷模式，具体的流程如下，如此的好处是，开发在设计开发时，故事需求是明确的，避免了信息不同步等导致的项目迭代影响

小编所在的团队，为了避免忘记全局，对整体需求的理解有偏差，推行了在code前，对方案进行讲解。

功能测试

通过面向业务的测试驱动开发以确保团队时刻了解实现一个可测试的应用需求。支持团队的面向业务的测试必须自动化以快速和容易进行反馈，团队才能在短迭代中生产价值。

小编所在的团队，会提供自测case，在正式开始测试前，开发人员和测试人员均需要执行自测case。

小编团队后续的规划是：将待提测功能的自测case、未改动模块的主流程case转化为自动化，在提测后，通过执行自测case来满足快速的反馈。

自动化的执行需要开发配合来完成，在执行时，需要与开发达成共同的愿景。

支持团队的面向技术的测试Q1

针对团队的面向技术的测试，请参考文章<【质量管理改进】敏捷测试思想>