敏捷测试感悟（之二）

橙子0012

在本系列的第一部分中，我们简要回顾了敏捷开发，以及敏捷测试与传统测试的不同。在第一部分中，我们特
别提到，敏捷测试的要点之一就是，不依据于角色而是依据于任务来考虑整个开发过程中的测试。

但是，对一个开发组织来说，组织中一定存在开发工程师和测试工程师的角色划分，作为一个敏捷团队中的测
试工程师，他的主要工作职责是什么呢？或者说，他可以在哪些工作上发挥自己的作用呢？

敏捷过程中与测试相关的任务很多，概括说来有如下一些：

建立不同级别的测试验收标准（也就是test suite），包括单元测试、集成测试、系统测试等各个层面的验收标准；
推动整个组织的质量文化，保证整个组织的成员在质量责任与目标方面达成一致；
通过技术或是管理的手段，保证产品、代码具有良好的可测试性；
通过自动化测试手段缩短每个产品发布周期中测试所需的时间；
与客户沟通确认客户可接受的软件质量标准，并建立针对此标准的验收测试；
深入了解应用系统和业务需求，通过探索性测试方法设计有效的测试用例，发现产品中的缺陷；
建立对整个团队可见的质量度量体系，保证整个团队能够随时看到产品的质量度量值。

这些工作都可以是敏捷团队中测试工程师角色的工作任务，但显然，在现实中，不太可能要求所有这些工作都
由测试工程师来承担─同时，让测试工程师承担全部这些工作任务也并不合理，某些工作由开发工程师角色，
或是由开发工程师和测试工程师共同承担更为合理。
接下来，我更详细的把列出的这7项工作中非常成“测试工程师必须完成的工作”，“测试工程师需要去推进的工
作”，以及“能为项目带来巨大价值的工作”。

测试工程师必须完成的工作：
与客户沟通确认客户可接受的软件质量标准，并建立针对此标准的验收测试；
深入了解应用系统和业务需求，通过探索性测试方法设计有效的测试用例，发现产品中的缺陷；
建立系统和用户验收级别的测试验收标准；
通过自动化测试手段缩短每个产品发布周期中测试所需的时间；
测试工程师需要去推进的工作：
推动低层次测试（单元测试和接口级别的测试）的进行。低层次是测试对于需要快速发布的敏捷开发来说至关
重要，但在大部分国内的软件组织中，开发测试都需要经过不断的推动才能被最终执行下去，测试工程师具有
相关的测试技巧，并且能够用翔实的统计数据表明低层次测试的必要性，是最好的推动低层次测试的人选；
推动整个组织的质量文化，保证整个组织的成员在质量责任与目标方面达成一致。这一点对于敏捷组织来说也
是至关重要的；在许多传统的软件开发组织中，经常能看到开发和测试之间的扯皮，针对一个遗漏的缺陷，
大家考虑第一件事不是如何去修复，如何去防止，而是首先“追究责任”─在敏捷过程中，需要一个非常不同的
环境：也即，质量责任是由所有工程师共同承担的，对于出现的问题，重要的是解决和预防。
能为项目带来巨大价值的工作

建立对整个团队可见的质量度量体系，保证整个团队能够随时看到产品的质量度量值。保证产品质量度量的
可见可以让整个团队清楚的看到我们现在正在工作的产品与我们期望交付的产品在质量上还有多大的差距，这
样整个团队可以以质量度量作为指示，集中精力工作在这些差距上，从而可以尽快的发布“可工作”的产品。“验
收测试的通过度”，“单元测试的通过率”，“功能完成情况”等等项目都可以是质量度量中的度量项。

通过技术或是管理的手段，保证产品、代码具有良好的可测试性。良好的可测试性对于产品的维护，自动化测
试的进行都是非常有利的─我觉得，甚至可以武断的说，如果一个应用系统没有良好的可测试性，就很难期望
可以在该项目上设置良好的测试框架。测试工程师一般不参与具体的设计工作和代码实施工作，但测试工程师
可以推动开发工程师在设计和实现时尽可能的考虑可测试性设计，另一方面，测试工程师也可以通过测试覆盖
率这个质量及时发现应用中可测试性不强的地方，推动开发工程师的改进。

综上，就是我个人认为的敏捷过程中的测试角色必须，应该和可以进行的工作。当然，要完成这些工作，和
传统的QA工程师相比，敏捷过程对测试工程师提出了更好的技能上的要求。在我看来，一个敏捷项目中的测
试工程师应该具有这样一些技能：
良好的沟通和协作能力；
良好的设计和代码能力，至少可以和开发工程师在同一水平上讨论具体的设计和代码实现；
快速学习和总结的能力（运用探索性测试发现缺陷）；
对自动化测试有深刻的理解（至少要能清楚的认识到自动化测试不等于UI自动化测试，也不等于用自动化测
试工具进行录制和回放）；
快速的风险分析和判断能力（在许多情况下都不会有足够的时间开展full regression，如何判断风险和决定相
应的对策至关重要）。