类似于软件工作产品，测试过程中的每个阶段都有可能会输出测试文档，即测试工作产品。ISTQB基础级大纲中是以ISO 29119 - 3（ISTQB基础级2011版本参考的是IEEE 829 - 1998标准）作为测试工作产品的指南，其提供了结构化的测试文档架构，同时描述了测试文档与测试阶段之间的关系。其包含的主要文档包括：测试计划、测试设计说明、测试用例说明、测试规程说明、缺陷报告、测试总结报告等。详细内容可参考标准：ISO 29119 - 3。
但是，测试实践中感觉测试文档并没有发挥其应有的作用，经常发现的问题包括：
1）成本高：测试人员需要花费大量的时间编写测试文档，例如，按照公司模板填充内容；
2）效果差：测试文档填充了很多原始材料，但实际情况往往是写文档的人不看，需要看文档的人看不懂；
3）常变更：特别是在轻量级的开发过程中，变更是常发生的事情，导致变更的工作量巨大；
因此，纯粹照搬使用IEEE - 829标准或ISO 29199 -3标准，很难达到测试文档的使用目标，也不是这些标准的初衷。为了提高测试文档的效率和有效性，测试人员在编写时需要考虑下面的2个因素：
1、合理裁剪文档标准
编写测试文档时，通常我们不会完全按照模板进行，而是考虑实际的测试周境进行裁剪。例如：
1）测试目标：测试人员测试该产品或者系统的目标是什么。假如测试文档不能支持这个目标，或者无助于达到这个目标，那么这样的测试文档（与所创建的所有其他软件工作产品一样）价值就会降低很多；
2）测试文档是产品还是工具：假如测试文档是软件系统或者产品的一部分，即测试文档需要发布给客户，这时候测试文档就需要按照客户的要求遵循某种标准。假如测试文档只是内部使用的工具，那么就不必太完整、太整齐，能够在最低限度上有助于达到目标即可；
3）采用的开发模型：假如目前采用的软件开发模型是V模型之类的重量级模型，那么采用的测试过程通常是依赖于预先定义的测试，这时候需要详细的测试用例的操作和维护文档。假如采用的是敏捷开发等时间周期短的轻量级开发模型，相应的测试也需要调整，可能会更多的偏向探索性测试，而非完整详细的脚本化测试，此时则更需要策略方面的文档，例如：关于某个测试领域的想法，但不是具体的测试用例；
4）软件工作产品是否常变更：如果软件设计变更很频繁，则不要将许多细节写入测试文档中，因为这些细节很快就会过时。这种情况下，不要编写大量的测试文档，它们被修改或者放弃的速度太快，不值得在测试文档上投入太多；
5）给谁看：假如测试文档是主要给新的测试人员或者没有经验的测试人员看，那么需要足够详细使得他们能够正常开展工作。
测试人员在裁剪测试文档时，上面的这些问题可以帮助测试人员思考，写出他们所需要的东西，以及内容的详细程度，以达到测试文档的目标。
2、关注文档输出，更关注文档过程
前文“质量保证QA与质量控制QC”一文中，提到了过程质量会决定软件工作产品的质量。该理念同样适用于测试文档：我们平时讲到的文档，例如测试计划，通常指的是测试计划这篇文档，即Test Plan，是测试计划Test Planning的输出。而Test Plan是否有用，更多的是取决于你的Test Planning的过程，而不是文档本身。也就是说，我们在谈测试文档是否有用的时候，应该更多得关注在得到文档的具体过程，也就是文档的内容你是如何得来的。延伸一下：编写测试文档的过程本身，比测试文档的输出更重要。
还是以测试计划Test Plan为例，了解该文档有哪些内容组成可以是很快的，你可以参考标准，也可以借鉴组织提供的模板。但是，你看到的测试计划文档，只是我们测试知识体系应用的冰山一角，为了支撑这冰上一角，需要冰上下面更多知识的帮助。例如：测试计划中有工作量数据，文档中定义是20人周PW。假如我只是看测试计划的测试人员，我很容易就知道了工作量的大小。但是，我很可能并不知道这个20人周是如何得来的，其中考虑的测试任务有哪些？需要输出的工作产品有哪些？测试的范围，甚至是作者本身针对该工作量估算所做的假设。因为我不知道该数据背后得来的过程，那么在实际工作量和计划工作量之间出现偏差时，我很可能是一脸懵逼。你很难在实际与计划之间出现偏差时，快速地进行反馈响应和动态调整。
因此，我们在说测试文档是否有用时，首先需要考虑你是否基于你的测试周境对测试文档进行了合理得裁剪；其次，你是否是基于你的测试知识体系（参考文章：构建测试人员的能力体系），关注在测试文档生成的过程，了解文档中每部分与测试相关内容是如何得到的。假如做到这2点，你就可以不仅知道测试文档是什么，更清楚该文档告诉你应该怎么做，从而实现对测试过程、测试任务、测试执行进度等的有效监控。
网友评论