《 测试反模式:有效规避常见的92种测试陷阱》——3.2 一般建议

简介:

本节书摘来自华章计算机《 测试反模式:有效规避常见的92种测试陷阱》一书中的第3章,第3.2节,作者:(美) Donald G. Firesmith 更多章节内容可以访问云栖社区“华章计算机”公众号查看。

3.2 一般建议

除了在下文缺陷描述中提供的单个缺陷相关的建议之外,以下建议普遍适用于大多数常见的测试陷阱。

  • 预防建议。这些一般建议可以在最初防止落入陷阱。
    • 更新测试过程。测试人员、首席工程师和过程工程师更新测试过程以帮助项目避免落入测试陷阱,若做不到这一点,那么在已经落入陷阱时能够及时发现。
    • 将陷阱当作风险。当相关时,陷阱应该正式在项目的风险库中识别为风险,并做相应管理。
    • 正式要求解决方案。客户代表在适当的文档中正式要求测试陷阱的解决方案,如需求建议书(RFP)、合同和工作说明书(SOW)。
    • 内部强制要求解决方案。管理人员、首席工程师(开发团队领导)或首席测试人员(测试团队领导)在相应的文档中明确强制要求测试陷阱的解决方案,如系统工程管理计划(SEMP)、系统开发计划(SDP)、测试计划文档或测试策略。
    • 提供培训。首席测试人员或培训人员给相关人员(如采购人员、管理层、测试人员和质量保证人员)提供适当数量和水平的测试培训,涵盖潜在的测试陷阱和如何预防、检测及应对。
    • 确保管理层的支持。管理人员明确说明(并提供)对测试的支持,以及避免经常发生的测试陷阱的必要性。
  • 检测建议。以下一般建议使得识别和诊断现有的陷阱成为可能。
    • 评估文档。评审、审查或走查测试相关的文档(例如,测试计划和开发计划的测试部分)。
    • 确保监督。测试过程执行时提供采购方、管理层、质量保证和同行的监督。
    • 考虑度量指标。收集、分析并向利益相关者(例如,采购方、管理人员、技术领导或首席工程师和首席测试人员)报告相关的测试指标。
  • 应对建议。一旦检测到陷阱,以下一般建议有助于缓解。
    • 拒绝不充分的测试文档。客户代表、管理人员和首席工程师拒绝接受测试相关的文档,直到已识别的陷阱得到解决。
    • 拒绝交付。客户代表、管理人员和首席工程师拒绝接受被测系统或软件(SUT),直到已识别的陷阱(例如,测试环境、测试过程或测试用例)得到解决。然后对相关缺陷进行优先级排序和修复后重新运行测试。
    • 提供培训。首席测试人员或培训人员给相关人员(如采购人员、管理人员、测试人员和质量保证人员)提供适当数量和水平的补救测试培训,涵盖已观察到的测试陷阱和如何预防、检测及应对测试陷阱。
    • 更新过程。首席工程师、首席测试人员或过程工程师更新测试过程文档(例如,流程、指南、模板、工具手册),以最大限度地减少观察到的测试陷阱再次出现的可能性。
    • 报告陷阱的发生。测试人员应向项目管理团队报告陷阱的发生,包括测试经理、项目经理和技术负责人。
    • 将陷阱当作风险。如果相关时,陷阱应该正式在项目的风险库中识别为风险,并做相应管理。
相关文章
|
监控 测试技术
测试反模式的思考
习惯了的事,也不总是对的。当下舒服的,也不一定是正确的。软件行业已经发生了很大的变化,不怪企业对测试人员的技术要求不断的提高。而是应该庆幸测试的门槛越来越高,你才有更多的机会脱颖而出。
100 0

热门文章

最新文章