2、评估测试代价
● 测试的消耗有多大?我们能承受的测试代价是多大?
● 我们能否从测试覆盖中消除不必要的冗余?
● 是什么让测试执行困难(代价高)?
● 产品的可测性能否再提高?
● 是否有工具或技术可以使测试过程更加高效?
● 早点测试好还是迟点测试好?哪种情况下测试的整体成本低一些?
3、检查测试对决策的作用
● 测试过程是否清楚管理者、开发人员或其它客户需要做的决定?
● 测试过程是否关注潜在产品和项目风险?
● 测试过程是否依赖变更控制过程和项目管理?
● 测试报告是否及时递交?
● 测试报告是否用易于理解的方式沟通?
● 测试过程和测试结果一样被传达吗?我们是否报告评估的基础以及融入我们的信心在里面?
● 测试过程是否对技术支持、发行、市场或其它需要使用质量评估的任何业务过程提供服务?
4、是否及时
以上三方面都是时间驱动的。所以带来了问题:我们永远也没有足够的时间去做每一件事,所以我们要做的每一件事都是与时间赛跑。
整合分析
1、我们的测试有多好?
● 综合前面的几个问题,考虑我们现在的测试过程中是否存在紧迫的问题?
● 我们的测试流程是否充分,是否能在产品质量未能达到预期目标时对项目管理提出预警?
● 是否存在某些潜在类型的问题是不可忍受的,如果有,我们是否有有信心我们的测试流程能发现定位这些问题?
2、是否值得改进?
● 我们能用什么策略改进测试?
● 我们有能力应用这些测试策略吗?我们知道怎样应用吗?
● 改进测试会消耗多大?会有多麻烦?是否是利用资源的最佳方式?
● 能否暂时不改进?能否在一个可接受的时间范围内达到改进?
● 改进是否会造成反效果,引入新的bug,对士气造成影响?
● 改进会带来明显的不同吗?
测试经理不愿意面对“毫无遗漏的测试是不可能的”这一事实的话,他就会选择一个不可能完成的测试。
Good Enough Testing 的目的是帮助软件测试工程师摆脱测试的条条框框、主观性、被动的局面,把结构化的、合理的方法应用到复杂的、多维的问题集合中去。