风险管理计划中的BUG应对方案
BUG就像软件的影子一样,其生命周期和软件的生命周期同步持续进行。产品是想BUG的,研发是写BUG的,测试是找BUG的。在软件开发这场战役中,几乎所有的项目人员都在不停的与BUG做斗争,直到被打败。(在风险管理中,软件产品的风险被认为是不可避免的,只能设置相对完全的应对方案来降低风险度。就是说,BUG是永恒的,就看用户对它的容忍度。)
相对产品和研发,测试应该是防范BUG的最后一道保险。那么,需要解决的问题就是:怎么才能让BUG尽早的最大化暴露在测试过程中?
1.详细的产品需求文档
在开发之前,一定要有一份繁琐到不能再繁琐的详细需求文档。详细到每一个单元可单独量化,可测试。
2.规范的研发文档
研发文档这里指的是项目中编写的代码文档。涉及到《代码编写行为规范》
3.详细的单元测试文档
对应需求文档,会有一份单元测试文档,每个测试单元都对应一个需求单元,有一个独特、可证明的测试方案。完整的单元测试是基于详细的需求文档制定的,回归测试只是重复了一整套的单元测试。
4.规范化的BUG管理软件
这里借用禅道,禅道远远不只是BUG管理,虽然BUG管理只是软件项目管理的一部分,希望还是能用起来。
5.确认BUG到底属于需求还是代码
不是所有的BUG都是代码错误造成的,在需求中的BUG更难被发现。能及时的纠正需求中的BUG,能在时间维度上降低产品的风险。
6.确认BUG的重要程度,分级管理
在BUG被确认后,要对BUG的重要程度进行分级管理,ABC,不能做一揽子计划,保证最紧急的BUG最优先修改。
7.确认负责人
每个BUG对应每个实际的负责人,由该负责人出具BUG解决方案。
8.确认修复时间
在敲定负责人后,由项目负责人与该BUG负责人确认修复时间,到期及时结算。
9.修复后的重复测试和回归测试
总有一天我会有一座面朝大海的房子