此问题,来自“软件测试圈”中某测试从业者的提问 。
提取出来,统一解答。
如果想实时深度讨论、每日主题交流,欢迎进圈子。
/
关于需求未确定,测试同学该如何做的问题 。
首先,
这是一个普遍存在的情况,除非是一个非常成熟的团队,流程非常完善,否则经常会存在需求迟迟未定,或者频繁变更,开发已经在撸代码了,测试这个时候应该是要写测试用例了 ?
这个时候,很多测试同学就苦恼了。“正常流程,不是跟着需求文档、拆解需求,然后再参照原型以及UI写用例么 ?”
如果这些都没有,该怎么写用例呢 ?
老徐给几个思路 :
1. 有个词叫“测试点”
需求未定,或者需求频繁变更的团队,明显不适合写测试用例,写了也是浪费时间(你写的速度,还没有变更的速度快,每天都是在做无用功。或者说,需求未定,很多细节,你也写不了) 。
2. 测试点到底该怎么写呢 ? 侧重点是什么 ?
重点关注业务逻辑、业务场景、异常测试等,至于具体UI细节,简单带过即可(因为此时,需求未定,后续确定后,做简单补充即可,因为UI层面的问题,视觉就可直观的看出来,不需要大篇幅的测试用例,浪费时间,产出并不高)
OK ,总结来看,就是 写更大颗粒度的测试点来代替测试用例。
由此减少需求变更带来的用例维护成本,又可测试前置,且还可以保证核心流程、功能、场景化、异常情况充分覆盖 。
/
End ,就是这么简单,此问题解决结束,还有问题,底部直接留言,老徐解答。
/
补充一个话题,
关于需求频繁变更,本身就是不合理的,特别是版本发布临界点,是不建议临时插播需求的。
此处,项目负责人,研发负责人应严格把关,整个团队一起来把控质量。
而不是,任由需求变更,最后出问题找测试。
源头没控制,最后出问题属正常现象,问题看本质,方是一个成熟的职场人。
By IDO老徐
2017-08-30
注:老徐所有原创文章,禁止任何形式转载,转发、分享随意。
此文适合产品、研发、测试、项目负责人、研发总监 等技术管理者阅读,希望对大家有点参考作用。
很多团队存在的问题,追溯本源,其实就是这么简单。很多团队,喜欢把简单问题复杂化,不去承认问题本质。
曾经老徐写过管理方面的文章:
最后 ,
文章,如果有帮助,欢迎转发 。
写自己认为有价值的文章,每天分享一点点 。
邀请你一起加入。
最后,推荐几篇有价值的文章:
福利,
后台回复"11D",领取老徐送的圈子免费码
圈子内老徐正在发起 linux SQL 的每日一成长,计划发起持续集成方向的深度探讨,有兴趣者加入
<End>
我是IDO老徐,Tester,十年测试职业老鸟,分享原创职业观点,经验,答疑解惑。希望通过自己的文字分享能改变测试职业现状,让测试从业者整体水平提升一个Level 。
老徐所有原创文章
第一时间发布至此公众号
长按二维码/微信扫码 关注老徐
老徐私人微信isTester
有问题,可留言
老徐所有的文章,只在此公众号更新 。
文章如有用,欢迎 转发 、 分享 。
让更多测试从业者受益 。
喜欢请告诉老徐,并推荐给朋友,相识为缘