所在公司的流程
1、需求评审:产品、开发、测试、UI等相关人员参与,需求会提前发送至邮箱,评审期间提出疑问/建议,产品修改后可能再次评审
2、需求冻结后项目立项:确定工期,以及是否有影响工期的因素等
3、立项后,开发以及测试期间每天组内小例会,每周两次大例会确认进度,是否延期等
4、UI评审:产品、开发、测试、UI等相关人员参与,提出疑问/建议,UI修改后可能再次评审
5、编写测试用例(包括冒烟用例),测试用例的粗细度度自己决定,期间有疑问会再次向产品确认。用例评审,综合开发/产品意见再次修改
6、如果项目涉及到接口,开发期间,接口完成后会进行接口测试
7、开发完成后,要求自测后提测,测试冒烟通过后才算提测成功,否则打回,冒烟测试通过/不通过需要发送报告
8、提测成功后,测试进行测试,每天要发进度日报,bug增长以及修改速度情况、风险预估等
9、测试完成后,发版,需要发送发版报告
10、发版完成后,进行外网回归测试,测试之后需要发送回归报告
在我看来,所在公司的工作流程已经非常完整了,但是在执行上并不是每一步都到位。
1、需求方面:需求不够明确,经常出现一句话需求(可能所在组产品比较随意)
2、需求/UI/测试用例的评审方面:参会人员玩手机的现象非常普遍
3、立项:立项后开发/测试期间经常插入需求(存在市场反馈)
4、用例编写方面:这个是以我个人来看的,花费太多时间在用例上
5、自测方面:虽然要求开发自测,但是执行度不高(存在压工时,工时紧张的原因),有时会导致冒烟多次不通过,花费较多时间冒烟
6、测试方面:1、个人测试感觉,虽然会编写测试用例,但是测试期间基本不会按照用例执行;
2、发版当天总是会出现问题,漏测/之前修改好的或没有的回归时却出现问题等,导致每次发版总是会很晚
3、发现bug后不会深究去定位问题,停留在表象
以上问题,我们测试或者项目组内都吐槽过或者讨论过,努力改善中~
在简书中看到小伙伴“名字好丑”的一句话特别喜欢:不要抱怨开发多么烂,因为这是你的合作伙伴,不要吐槽需求多么烂,因为在烂你也在测试,需要用自己的方式去引导开发、产品往自己期望的角度改变
工作中少点抱怨,多想想怎么解决问题才会成长