关于测试时间的话题,一直在讨论、一直在解答,却一直有人存在疑惑和不解;

在老徐的文章底部,或者个人微信PYQ,一些比较高频的留言,

如:

1)开发一个月、测试一周;

2)开发一周,测试3天 ;

3)开发一周,测试1天;

4)项目周期三个月,开发一个月,测试1天 ;

5)开发一周,测试周期1小时;

6)开发3天,测试周期0小时(未测试,直接上线);

7)当天突然知道一个需求,当天就需要你测试,当天上线 ;

8)需求都不知道,让你估算测试时间 ;

...  等等,太多这种奇葩的问题 。

从底层逻辑来说,肯定是项目流程有问题,或者项目经理,关键节点把控的问题;

但,从做事的逻辑,从不背锅的逻辑,从线上质量的逻辑来聊;

如上,种种情况,都可以用一个套路来解决;

记得之前老徐写的文章否 ?

我是IDO老徐

,作为过来人,给大家几个参考思路 :

1、严格来说,一定是从需求阶段,或者立项阶段,就参与到项目,根据最终的需求、开发排期,是估算合理的测试时间(测试时间估算,见文章:“测试时间估算”的现状 及 4点建议 )

2、如果测试时间,已经被其他人定死了,根本不给你时间估算的机会,那么就参考文章 :项目周期已定死,重点把握哪些,保证按期上线?

3、常规来看,3天的测试预留时间,或者1周的预留时间,一定会被开发压缩的(即:在你的测试周期里,还会存在一些开发并行工作),先做冒烟测试,开发阶段就多关注代码实现逻辑、接口情况、测试数据准备、环境准备,可以提前做很多事(别告诉我,说你并行多个项目,没时间提前准备);

4、对于当天收到需求、当天测试、当天上线的,形成习惯,先用脑图梳理可能的测试点,给相关人(产品、开发、项目经理)确认你的点,是否有遗漏,测试报告,附上你的测试点、以及可能性的风险、结论,避免背锅;

5、少抱怨时间不够、多去想想如何更高效的解决问题、以及避免产生当前现状 ;

就算开发一个月、给你同样安排一个月的测试时间,上线后依然一堆Bug(你交付的系统、上线后、存在线上Bug,不是时间不够,本质是能力不够);

6、当时间确实不够,系统会线上问题的容忍度又非常低的情况下,测试报告明确注明风险+结论(不同意上线),且邮件发出来;最终,还是要一意孤行,锅,团队一起背 ;

7、确实很多非核心系统、内部系统、纯底层代码逻辑的底层框架,完全不需要测试,直接跳过测试、上线也是可以的(如果能做到 单元测试、代码检查、线上监控);

参考文章:软件测试从业者终极目标,线上零BUG如何实现 ?,很多同学觉得做不到,很难 ?也许没去试过 ;


本文参考链接:https://blog.csdn.net/weixin_42525428/article/details/119199193
评论关闭
IT序号网

微信公众号号:IT虾米 (左侧二维码扫一扫)欢迎添加!

七年级上册计算机工作总结,七年级上册数学的工作总结范文