ISO/IEC IEEE 26513:软件工程 — 用户文档测试者和评审者的要求

测试和评审软件用户文档质量与可用性的系统方法

ISO/IEC IEEE 26513定义了作为软件文档生命周期组成部分的测试和评审用户文档的要求。虽然许多组织在测试其软件产品方面投入了大量资源,但随附的用户文档往往受到的严格评估要少得多。该标准确立了用户文档必须经受与软件本身相同的系统验证和确认过程,认识到文档缺陷可能导致用户错误、支持成本和客户不满,就像软件缺陷一样。

文档缺陷不仅仅是表面的问题——它们可能直接导致用户错误、安全事件、数据丢失和支持成本。以与软件测试相同的严格程度对待文档测试是一种成本效益高的质量策略。

文档评审类型与流程

标准定义了三种不同类型的文档评审,每种服务于不同的目的,需要评审者具备不同的技能。技术评审验证文档是否准确地代表了产品的功能、特性和行为——评审者必须能够在实际产品上执行文档化程序并识别任何差异。编辑评审根据语言质量标准评估文档,包括语法、术语一致性、风格指南遵守情况以及表达的清晰度。可用性评审评估文档是否使预期用户能够在预期的使用环境中有效、高效和满意地实现其目标。

每种评审类型都有定义的进入和退出标准。例如,技术评审需要稳定的产品版本或原型、已记录的评审范围以及具有适当技术专长的评审团队。退出标准包括按严重程度分类的记录结果、所有关键和主要结果的解决,以及由评审负责人签署的评审报告。标准强调应在整个文档开发周期中进行评审,而不仅仅在最后——对大纲和草稿的早期评审比对已完成文档的后期评审更具成本效益。

评审类型 关注领域 评审者所需技能 典型时机
技术评审 准确性、完整性、正确性 主题专业知识、产品知识 草稿完成后
编辑评审 语言、风格、一致性 技术编辑、风格指南掌握 开发全过程
可用性评审 有效性、效率、满意度 可用性工程、任务分析 编辑评审之后
一个经常观察到的问题是技术评审和编辑评审合并在一次评审中进行。这是低效的,因为技术评审者关注事实准确性,而编辑评审者关注语言质量——将两者合并会导致认知过载,并降低两种类型发现的效率。

缺陷分类与度量

标准引入了一个结构化的文档问题缺陷分类方案。缺陷按严重程度(严重、主要、次要、外观)、按类型(准确性、完整性、清晰度、一致性、可访问性、格式)和按位置(特定章节、图形、表格、程序步骤、代码示例)进行分类。这种分类可以系统跟踪文档质量指标,并识别文档开发过程中的系统性问题。

缺陷度量包括密度指标(每页或每个主题的缺陷数)和老化指标(按严重程度分类的缺陷解决时间)。标准建议基于组织历史数据或行业基准建立基准阈值。例如,每页超过0.5个严重缺陷可能表明技术评审阶段需要流程改进,而编辑缺陷增加的趋势可能表明风格指南偏离或作者培训不足。这些定量度量将文档质量从主观印象转变为客观管理的参数。

实施26513缺陷分类和度量框架的组织报告称,系统的文档测试使发布后的文档缺陷率降低了60-80%,并在实施的前六个月内将与文档相关的支持电话减少了约40%。

文档可用性测试

26513的一个独特贡献是其对文档可用性测试的详细要求。标准区分了可用性评审(基于既定可用性标准的专家评估)和可用性测试(与代表性用户进行实证测试)。可用性测试包括:定义代表用户目标的测试任务,招募与目标用户画像匹配的参与者,观察参与者仅使用文档尝试执行任务的情况,测量绩效指标(任务完成率、任务时间、参考文档的次数),以及收集主观满意度评分。

标准规定应在代表实际使用环境的环境中进行可用性测试,每个用户组至少需要五名参与者(基于已有的可用性工程研究,表明五名参与者可以识别大约85%的可用性问题)。可用性测试的结果直接输入到文档改进优先级中——导致任务失败或显著延迟的问题应以最高优先级处理,无论它们是否会在传统评审中被分类为严重问题。

文档可用性测试中的一个常见错误是与过于熟悉产品的参与者或文档专家而非代表性最终用户一起测试。这会使结果产生偏差,并无法揭示真实用户将遇到的可用性问题。标准强调了招募符合实际目标受众特征的参与者的重要性。

常见问题

问:26513如何区分测试和评审?
答:在标准的术语中,评审包括基于检查的评估(技术和编辑评审)和实证测试(可用性测试)。测试特指在受控环境中使用代表性用户对文档进行实证评估。

问:文档测试可以自动化吗?
答:某些方面可以部分自动化,例如拼写和语法检查、风格指南符合性检查、在线文档的链接验证以及术语用法的一致性检查。然而,技术准确性验证和可用性测试需要人工判断,无法完全自动化。

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注