工作流程

2017-06-10 本文已影响0人吆_慧

所在公司的流程

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后不会深究去定位问题，停留在表象

以上问题，我们测试或者项目组内都吐槽过或者讨论过，努力改善中~

在简书中看到小伙伴“名字好丑”的一句话特别喜欢：不要抱怨开发多么烂，因为这是你的合作伙伴，不要吐槽需求多么烂，因为在烂你也在测试，需要用自己的方式去引导开发、产品往自己期望的角度改变

工作中少点抱怨，多想想怎么解决问题才会成长