互联网大厂的测试员是怎么交付测试项目文档的

背景介绍

产品文档作为产品交付的配套，承担着产品交付后的部署、开通应用操作指导的作用。

编写的文档质量好坏，直接影响产品交付开通应用的整体用户体验、产品口碑。

结合当前项目的研发过程中，对文档交付的质量、交付的时效性以及交付流程实践进行一下分享探讨。

按照整个产品研发过程中涉及到交付文档类别、交付阶段、文档作用以及交付周期大致划分如下：

由于当前工作涉及内容主要在敏捷测试阶段，针对敏捷测试阶段涉及的特性指导书类文档交付过程实践进行分享探讨。
 

问题分析

对于敏捷测试特性文档交付，从一开始被文档交付的困扰，到改进实践并形成一定的固化流程，跌跌撞撞中一路调整走上了正轨，实践过程分别从组织、流程两个方面来完善调整。

特性文档交付痛点：

文档交付难/拖延

没空写：特性的交付都有明确的迭代周期，按照项目敏捷交付的流程，特性所配套的文档是特性交付中的一部分，是特性完成交付中检查标准中的一项，特性会按交付周期来完成，但受迭代交付压力，随之一起交付的特性文档永远是优先级最低的任务，没空写。

没人写：对于文档，也没人愿意写，认为只要编好代码，做好测试就行；对于交付给用户指导特性开通的文档，工程师站在实现的角度来编写，工程师思维和用户使用的贴合度不高，用户文档也不会写。

特性文档质量不佳

看不懂：编写的特性文档大多是拷贝的特性方案中的内容，系统具体的内部实现，对于使用用户对系统没有深入的知识背景，看此类拷贝方案内容的文档，就不知所云。

有错误：特性文档编写优先级低，没人写、没人控，导致文档错误，质量不佳。

无价值：对于用户来说，文档无法指导用户对特性的开通使用；没有价值。

文档交付拖延、质量不佳，直接导致了产品在外场上线后，无法指导实际的开通应用，需要后方研发工程师人力支持，耗时耗力，用户对产品体验下降。

存在、发现了问题是变革的动力，于是项目通过一定的管理手段、技术手段在特性文档交付上做了优化改进，在敏捷测试交付过程中完善特性文档的交付。

实践过程

组织上

为保障文档交付的时效性和质量，项目的各组织：

多岗位协同编写

全程进度控制

随迭代同步交付

在时效性方面：需求阶段识别>特性开发阶段编写。由对应测试专家进行编写计划的跟踪，并且特性文档交付加入验收高压线，随特性一起交付，在验收时未完成交付，则特性提交不通过。

在质量方面：由熟悉特性应用市场的SE、特性实现的SE、特性测试的QA共同编写完成。由验收专家TS进行文档审核，由系统测试TE进行文档测试验证。通过相关人员协同组织来保障文档质量。

流程上

特性文档的交付嵌入到研发流程中：

在需求分析阶段识别是否编写，提前识别为下一流程环节中预留编写时间；

在特性开发阶段进行编写、评审、跟踪，在开发过程环节中控制编写质量；

在系统测试阶段验证发布，通过最后的系统测试来为文档交付质量再次守护。

各阶段流程中对应的要求、相关输出、以及参与人员如下：从整个流程上来控制特性指导文档的输出质量、输出时效。

实践总结

为解决特导文档交付的时效性、保证文档内容质量，项目做到了以下几个方面。

协同交付

组织上创建团队协作氛围，市场规划、特性开发、特性验收、系统测试共同合作，互帮互助，让输出的文档从工程师思维向用户思维转变，交付高质量文档。

流程保证

特性开通指导文档嵌入研发流程，提前识别、预留编写时间、跟踪编写计划、纳入验收DOD通过流程来保证文档提交的时效性。

需求阶段识别，特性阶段编写、评审、修订，验收阶段审核，系统测试阶段测试验证，研发各流程环节共同协作保障文档交付。

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取