聊聊「测试分工和测试时间」

注:作为测试从业人员的一点建议与思考,虽然阅读量不是很大,但是清菡个人觉得对大家能有点价值;
-- 清菡

关于「测试分工」和「测试时间」的关系,这个分2种情况:

第一种,研发技术水平高,项目业务场景相对来说比较简单。那么,这种情况下,如果管理人员安排一个人写用例,协助开发做冒烟测试,另一个人开始测试,这样做,相对来说问题不大。

但,这就多了时间的成本,接手过来测试的人需要重新了解这块的需求,效率会低一些。

第二种,项目场景复杂,研发水平比较低,一旦上线会出比较大风险的项目(例如涉及优惠券、订单之类)。如果管理人员安排一个人写用例,协助开发做冒烟测试,另一个人开始测试,就会出现比较大的问题:

导致测试进度缓慢,甚至无法上线。

这个也涉及团队协作,研发人员的责任心以及其它客观外部因素的影响。

怎么做?

如下,供参考

1.首先管理人员需对业务熟悉,考虑到风险范围以及风险点在哪。此外,还需考虑到研发人员的技术能力水平及责任心。以此,来做到合理的分工,出了问题也知道出现这样问题的原因。

2.管理人员需要有足够的技术水平支持,能认知到项目风险的前提是清楚明白会有什么样的风险出现,风险点在哪(这个需要清楚前后端技术是怎么实现的)。

3.当管理人员清楚知道了项目的复杂度,影响范围,风险点就可以预估出合理的测试时间,不会存在评估测试时间不合理的情况。或者说出现了这类的问题,管理人员自身清楚是怎么回事。

4.bug的出现肯定有原因 ,一个是从操作上分析,看看是不是什么操作自己没想到 ,随便瞎点点出来的,一个是代码上分析 ,看懂代码 ,做路径覆盖 。

5.测试是为了尽可能的避免出现问题,没办法保证一定不出问题 ,关键看出的问题是特定场景确实大家都没考虑到 。还是说没经验, 确实考虑不到这种操作才知道会出现这样的问题。

6.测试估算的时间,只需考虑测试的执行时间。如果中途,由于开发延期提测,或者开发修改Bug时间过长,等待新版本测试。在时间评估的时候,需考虑这个时间,把此块时间加上(或者,发版时间,顺延) 。

7.自己估算的时间,如果后续发现时间不够,自己加班,想办法消化 。另外,版本结束后,吸取经验,总结下,是哪个点消耗时间过多,是否可加速(自己总结的经验,终身受益) 。如果确实不可加速,说明整个团队的效能比较低。下次估算,不满足三分之一评估大法,在之前评估时间的基础上,再加上20%的时间 。

8.项目过程中,不接受临时新增需求的测试,如果有临时需求,需要增加对应的测试时间(这块,理论上是这样,实际情况是,很多同学,经常被强塞任务,时间却没有增加)。

9.用例写全。不是凭空想象 ,例如涉及优惠券的项目,一定把优惠卷的影响因子列出来。然后用正交实验大法抽取用例。

10.如果测试用例场景写的不够全,交接用例过来测试的人需要把问题都列出来,总结好发给领导,让领导去判断,避免背锅。

11.开发对业务不熟悉以及技术水平低, 这个不是咱们关注的, 有开发leader去把控。

12. 现实情况是,估算好的测试时间,已确定的上线时间,往往由于一些外部因素,提前上线,这个时候,测试同学,需列出已知风险,并做好本职工作,避免背锅 。

最后。

关于测试分工和测试时间的估算,此文的观点是一些非常主观的做法(仅供:不知道如何给测试分工及如何估算测试时间的测试从业者,一些参考)。
每个人的做法,多少会有些不一样。肯定会有更好、更优的做法。欢迎参与评论,或者,进知识星球「清菡软件测试」。点击链接:
https://t.zsxq.com/ZjQf2RV 即可免费加入!探讨交流。

加油。

清菡软件测试 提了一个问题
关于测试分工和测试时间,您有没有好的意见?欢迎来答。
参与讨论

想微信单独找清菡的,公众对话框回复「清菡」(注:文章写过的重复性的问题别问;欢迎问没写过的、高质量的问题)。

清菡
2020.10.17 Beijing

推荐文章

放假整理的四个知识,附带小工具
Appium之「元素定位和UiAutomator表达式」
更新“Appium运行原理”讲解!
Python+Appium运行简单的demo,你需要理解Appium运行原理!
举个华为计算器的栗子「Appium环境配置与调试」

希望清菡的每篇文章都对你有那么点价值。
如果有用,点个在看吧。

posted @ 2020-10-18 11:19  清菡  阅读(135)  评论(0编辑  收藏  举报