故事1
今天的工作,是执行已写好的"回馈"模块用例
每个子模块的用例都有优先级之分
肯定要先进行通过性测试,验证正常流
因此,我优先执行各个子模块优先级最高的那条用例,进行通过性测试
然而,通过性测试,失败概率80%
我请教同事该怎么办
他的意思是,这样很正常,遇到阻碍,先测其他模块,正常流测试完,改完一轮bug,再进行测试
我认为开发的质量太差了,因为在测试正常流时,若遇到了很大的阻碍,那么后续很多用例都无法执行
故事2
策划、开发、测试都在一个群里
我今天测试过程中,遇到好几处和原型不一致的地方,这个需要和策划确认
策划也是没多说什么,只是让把设计相关的bug指派给他,功能相关的bug指给开发
那么我就照做了
后续原因等策划在bug系统中的回复
因为是小程序的开发,肯定是手机来使用
就列表的加载,开发质疑策划设计的合理性
进入列表页,默认加载20条数据,上拉加载更多,每次加载10条
开发说,因为标题图在200~500k,那么20条得加载4~10M
首次加载20条按照500k的网速,得8~20秒
所以,设计的不合理
多么精彩的反驳,有理有据
最终,策划的方案改成
默认加载10条,上拉加载更多,每次加载10条
于是我感受到了策划的不切合实际
他可能凭感觉设计的,而开发的考虑却出于实用性和用户体验
故事3
因为今天执行用例很不顺,通过性都受阻
我带着满腹牢骚的心情,恰巧看到了老徐发的一条分享
当你接到一个[质量非常烂、UI效果非常LOW]的提测版本时,
不太建议疯狂提bug
先测主流程,及明显的bug,然后让开发修复后,再测第二轮
bug提得多,并不代表你的能力,多数是提测质量太烂
线上无漏测,才是能力的体现
共勉