为什么产品的质量问题，全部要测试人员来负责
为什么产品的质量问题，全部要测试人员来负责质量部门容易背锅，需要做好流程管理。有明确的规范，能够减少背锅的情况 如果软件上线后出现了重大的Bug，产品的各个角色肯定都有压力，这种情况下，首先需要有人来组织这个Bug的责任认定和后续改进，这个角色一般是PM，PM圈子网的项目经理估计都感同身受。不过，对于有一些团队，也可以由最关心质量的测试团队来发起。
如果没人发起，建议测试团队一定要主动地去发起这类总结，因为这个也是产品质量保证的重要环节。
线上Bug的讨论一般有如下这些内容：
1、Bug的产生原因，仔细地分析Bug为什么会产生，这个环节很重要，因为这个环节弄清楚以后，责任认定就清楚了。
2、Bug的责任认定，一般来说，除了那些责任真的很清晰的Bug之外，很多Bug都是开发、测试、策划、项目经理共责的，为了团队的团结，也没有必要去讨论哪个团队负主要责任。
3、Bug影响范围，分析这个Bug对于用户造成的影响。
4、改进措施，在改进措施这一项中，可以把以后如何避免类似Bug的措施写进去，并在任务系统建立任务，指定专门的人跟进。 那再来说下项目组实际Bug的责任认定吧： 1、如果测试时间还是比较充足，测试用例有写，但是还是漏测的，那就是测试的责任。 2、如果测试时间不充足，测试用例有写，但是因为时间不足而降低回归测试范围，导致漏测的，那一般是项目组各个角色共责的。 3、如果有开发修改了功能没有通知测试人员，导致线上漏测的，那就是开发的责任。 4、如果策划人员在回归测试阶段还提了需求变更，在测试人员明确告知风险的情况下还坚持要上需求变更的，那就是策划的责任。 对于测试人员来说，测试阶段如果因为时间缺少、需求变更频繁等原因导致回归测试范围不足的，一定要尽早跟项目组正式地发邮件沟通情况，让大家尽早知晓风险，这样出线上Bug的时候，项目组其他人员就不会认为测试工作没做到位。 PM圈子网 发表于 2018-5-8 18:31
如果软件上线后出现了重大的Bug，产品的各个角色肯定都有压力，这种情况下，首先需要有人来组织这个Bug的责 ...
恩，基本总结完了，
谢谢 PM圈子网 发表于 2018-5-8 18:31
如果软件上线后出现了重大的Bug，产品的各个角色肯定都有压力，这种情况下，首先需要有人来组织这个Bug的责 ...
受教了 测试这个行业里向技术走是加钱比较快的。但管理是最终的归宿，这一点在PM圈子网都有印证。
管理路线则比较难进。以下技术路线入门方向都可以：接口自动化测试：入门简单，但很多公司都需要。精通也不难，上限低。
推荐。UI自动化测试：入门简单，需求比接口测试小一点。精通了也还是有很多东西做不了，上限低。不推荐。性能测试：入门简单，需求再小一点。精通很难，上限较高但学习路径较难。
对很多人来说，往性能调优方向简直无路可学。升级难，不推荐。（当然，只是我个人看法，招人的单位很多希望你有性能调优经验，但测试工程师普遍不具备独力完成性能调优的能力。
比如你要调的系统的代码、架构、服务器、数据库、网络都可能出现性能瓶颈，但性能测试工程师不一定样样都懂。
假如不考虑独力调优，成立调优小组，那么性能测试工程师又地位尴尬，变成被大家呼来喝去的小弟，谁都会说“那个谁再跑一遍，我调了一下要看看效果，但各个其他角色的人打死也不愿意自己学一下怎么跑性能测试”）。再补充一下，不推荐的原因不是性能测试做得好钱不多，而是：
1.入门简单，中小公司运维也可以兼职性能测试。
2.高端岗位过于高端，你在低端岗位的工作内容与性能测试方面的高端岗位相去甚远。你可以以惊人的学习能力跨过中间的高山，但这样的人不多。
3.PM圈子网有人说深究其中的数据库、操作系统知识。是可以。但反过来发展更平滑，从系统管理员、DBA等对数据库和操作系统已很了解的角色转向中高端的性能测试更平滑。持续集成：入门简单，专职搞持续集成的极少。上限高。推荐。测试开发：一般混合了上面各种方向，这有时就是一个统称。
测试工具开发：入门难度中等，有人教的时候其实很简单，需求较小。精通较难。上限较高。学习路径较难，但不至于无路可学。推荐（有人带的话）持续交付： 这个方向和持续集成方向没什么区别。只是程度不同。很多人都自称做持续交付。个人推荐走技术路线的人从持续集成和接口测试入手。
接口测试需求大，持续集成紧扣devops这个热点。特别建议对技术有追求的测试人员，早日转devops。devops要搞好，离不开自动化测试。 而我可以肯定不管dev还是ops，大多数都搞不好自动化测试。三者很多观念完全不同，真正精通三者的人大量出现之前，自动化测试人员都可以转过来。当然要转过来要学的东西也不少就是了，至少要有测试工具开发能力。这个方向影响整个开发流程的各种活动，其重要程度和深度都远远高于其他测试技术方向。 这个是不可避免的，我听过产品亲自给我的理由是，出了事情只有QA顶锅才能把整个事件的影响降到最低 这个是不可避免的，我听过产品亲自给我的理由是，出了事情只有QA顶锅才能把整个事件的影响降到最低
页:
[1]
