聊聊敏捷测试

聊聊敏捷测试

一、测试是一个活动胜于测试是一个阶段

在传统的瀑布模型中，测试作为单独的一个阶段存在，并且一般存在于开发阶段之后，上线阶段之前，如果在敏捷中，开发已经进行了改进，如完成的开发单元更小了，但是测试仍然在最后阶段才进行，那么其实没有从根本上改变测试的方式。

在敏捷项目中如何判断测试是否被当成一个阶段来处理呢？方法很简单，我们可以查看项目的任务板，如果任务板中有一个单独的“测试”列(分栏)，如下图所示，就表示测试可能仍然被认为是一个阶段，或者有可能变成“小瀑布”。

如何把测试当成开发过程中的活动？秘诀是在开发工作开始之前，先想清楚有什么测试任务可以做，然后把它们展示在任务板上。

在任务板上，可视化的一个关键是不要有单独的“测试”列，而是使用不同颜的便利贴，把测试任务粘贴在“待办”列中，把包括开发任务在内的所有任务放在一起做，这样处理的好处是能够确保在测试任务完成之后，整个用户故事才算开发完成。

另一个技巧是设置“评审”列，把它放在“处理中”列之后、“完成”列之前。大多数团队都会对每个用户故事进行代码评审、文档评审，以及测试用例评审。设置“评审”列背后的思想是，一旦任务完成，就对每个任务进行评审，如果任务很小，这些微评审可能只需几分钟。

这至少确保了一点，即团队中至少有两个人已经查看了每一项工作，这种方式有助于更早地捕获和修复问题。

二、预防缺陷胜于发现缺陷

传统上，人们认为测试的目的是发现缺陷(Bug)。一些组织甚至基于测试人员发现(或没有发现)的缺陷数量来衡量他们的工作效率，这种思维上的局限性会强化“测试是具最后阶段才会开展的事情”这一想法。

敏捷测试的目的是在开始编写代码之前就查和消除所有假设和未知，以防止缺陷出现，其目的是确保从客户到开发人员，再到测试人员，每个人对需求的理解都完全相同防止出现缺陷的最佳方法是提问，并且通过沟通来消除彼此理解上的差异。需要注意的是不要忽略一些大家都认为答案“显而易见”的问题。

三、做测试者胜于做检查者

传统的测试人员通常不喜欢敏捷，因为缺少详细的规范文档使他们无从下手。测试人员认为自己的工作就是检查被测系统是否符合需求规范，并报告存在差异的地方，认为自己唯一要做的就是检查开发出来的产品是否严格遵守需求规范。实际上，他们对产品本身的质量并未加以关注，只重点关注了产品是否真的满足用户需求。

我们称这项工作为检查。其实最擅长做检查的应该是计算机而不是人，检查1+1=2对计算机来说非常容易且不会出错，因为它永远不会感到无聊、疲倦或注意力分散。在敏捷测试中，简单的检查应该被自动化，这样就可以将测试人员从中解放出来，转而投入计算机无法处理的工作，如探索式测试或可用性测试。

在敏捷测试中，测试人员需要成为客户的代言人，每当客户要求增加一个功能时，可以询问测试人员：“你将如何测试它？”或“你怎么判断它是可工作的？”这有助于理解客户所期望得到的实际结果。同时，还需要把它翻译成验收标准给团队，确保团队能够开发正确的产品。

四、帮助构建最好的系统胜于破坏系统

在传统模式下，测试人员采用的是破坏性思维，这种思维使开发人员和测试人员之间产生了隔阂。开发人员构建系统，然后测试人员试图破坏系统，这是在强化在传统思维模式下测试仅作为一个阶段存在的观念。

敏捷思维认为测试人员应该帮助构建尽可能高质量的系统，而不应该等到缺陷出现后再去发现它，以显示测试存在价值。事前预防远比事后控制重要。对于敏捷测试人员来说，更应该在开发之前尽力帮助团队构建正确的系统。

五、团队为质量负责胜于测试者为质量负责

在传统模式下，只有测试人员或测试团队对质量负责，一个产品是否能够发布，他们拥有最终的决定权。这种思维意味着只有测试人员关心质量，也只有测试人员肯花时间确保质量。

而在敏捷中，整个团队都要对质量负责，这有助于团队意识到测试是一种活动，他们都需要参与其中，并且将测试贯穿整个工作过程。如果客户在产品中发现了问题，没有人会质问测试人员为什么没有发现，相反，整个团队会讨论如何共同防止这种情况再次发生。一旦采用了这种思维，测试人员就不再是上线前唯一忙碌的人，整个团队都会参与其中。

阅读后若有收获，不吝关注，分享，在看！！！