职业经验 不想让测试人员的能力决定产品质量

K米测试 · 2017年03月15日 · 1763 次阅读

背景

  • 我们有 12 个人的测试团队
  • 分成 3 个小的测试模块
  • 每个测试团队负责不同的产品测试项目

团队特点

  • A 测试 leader:在代码方面有突出的能力,由于比较少参与测试,少有进行测试用例设计, @monkey 经常吐槽的角色;
  • B 测试模块负责人:在测试用例设计方面有独到之处,学习能力强,具备的能力:测试工具开发、接口测试、性能测试,积极主动,做事认真负责;
  • C 测试模块负责人:从其他部门转岗而来,靠自己的努力快速进行测试相关的学习,代码能力较弱,但是细致认真,积极主动,具有较强的沟通能力;
  • D 测试模块负责人:测试团队建立之前的第二个成员,具有较强的责任心,设计的测试用例偏冗余,很强的上进心;
  • C 测试开发人员:做过 2 年的开发,在测试岗位上很长一段时间在做测试开发工作,具有较强的代码能力,擅长接口测试,具备的能力:性能测试、测试工具开;
  • 其他人员

问题

  • 项目团队中的人员职责不够明确
  • 每个人都可以设计测试用例,但是无法保证测试用例的质量
  • 用例质量无法保证,产品质量也就无法保证
  • 测试不够聚焦,需求上来就开干,然后由做不完的需求
  • 功能测试、接口测试、自动化测试、性能测试穿插其中
  • 互联网项目,迭代速度过快,平时少有文档沉淀

核心问题

  • 团队模块化划分后,出现业务相互隔离,无法很好的进行人员调度

针对以上问题的思考

  • 模块化划分必然出现人员隔离问题
  • 测试用例无法评审,产品质量必然和个人能力强相关

针对问题的初步解决方案

  • 统一需求入口,完善完整的测试流程
  • 角色分工和流程:
    • 测试 leader 接收需求,根据产品内容和需要,通知测试代表参与项目需求讨论;
    • 测试代表参与最终需求评审和讨论,进行测试用例设计,测试用例评审:向测试人员介绍产品需求,和用例设计思路;制定初步的测试计划,评估产品上线时间;
    • 测试 leader 评估测试计划,并根据市场等想因素进行调整;
    • 测试 leader 评估自动化验收测试、性能测试方案;
    • 测试人员根据结合需求、测试用例、测试计划完成测试的执行部分,提交 BUG 和测试报告;
    • 测试代表验收产品,交付产品;
    • 测试 leader 组织测试相关干系人进行测试总结和 BUG 分析;

写在最后

不希望让产品的质量让一个测试人员的能力在决定,甚至是这个测试人员的心情,这是一件很可怕的事情,希望通过完善的测试流程,明确的人员分工来保证产品的质量,明天准备和小组成员讨论这个思路,希望能碰撞出一些火花来,同时也希望大家说说自己的想法。

一个从从技术走向管理的测试从业者目前还在坑里面

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 18 条回复 时间 点赞

产品质量不是一个人能决定的,而是从产品-->开发-->测试-->运营整个过程中,其中一节掉链子产品就会出问题。

要相信你们的测试 leader 一定向上级反馈或者争取了,只是暂时没有成功。

冰薄荷 回复

和我之前头像一样 灵主

0x88 回复

赞同,上头看来出问题了第一时间想的是这个是不是一个 bug。出问题机会几乎是==出 bug。

0x88 回复

产品质量就应该是测试决定的呀,产品发布市场,市场或者商家反馈有异常,难道不是产品质量不过关导致?

从我以前经历过的部门(大公司,个人是螺丝钉那种),一个测试部门分不同的测试组,自动化组,case 组(专门写 case 和维护 case),流程组(审核测试提交的 bug 样式,制定流程和维护,KPI),并有不同测试项目负责人(负责该项目,下面有测试人员)。
工作内容大致如下:
1,测试项目负责人需要 测试性能与自动化测试,提交任务给自动化组。自动化执行邮件反馈起结果
2,测试人员执行 case,遇到 case 有问题,及时向 case 组反馈 ,case 组确定该 case 问题,kpi+ 分。
3,遇到工作过程中,流程有问题或者需要优化,向流程组反馈,kpi + 分。
4,测试项目负责人向 pm,sqa 等发送工作汇总,召开 bug 评审会议(测试,开发,sqa)。
5,漏测 (重大问题) 扣 kpi,确定责任人,写 5why,部门通报

K米测试 回复

举个栗子:当开发延期你剩一天的测试时间,明天就要发布产品,你如何保证质量?你能决定这个产品高质量?此时,你只能评估此产品的风险,无法保证质量。
一个高质量的产品就是从整个开发流程下来保证其质量,包括开发时间安排,技术、需求的合理性、测试用例的设计的覆盖度等等。作为一个测试更应该去改变测试决定产品质量这个观念。
如果你还是停留在目前测试决定产品质量的话,我就静静的看着你背锅。

产品的质量不是测出来的😁

钱到位,流程比人重要。
钱不到位,人比流程重要。

0x88 回复
  1. 可能理解上有误区,一个产品经过认真测试和简单测试的效果是完全不一样的,测试端务必要保证:测试用例设计、测试用例评审。
  2. 针对你说的这个问题可能比较极端了,应该不会到了只剩下一天的测试时间,相关干系人才知道,在我们团队,研发一旦延期提交版本,测试会立即发送邮件通知明确测试时间对应顺延,通知相关干系人做好风险评估,例如通知市场一线做好安抚等类似的措施;
  3. 如果你不能推动整个开发流程的优化来保证质量,那站在测试的角度你应该让尽可能多的问题在测试过程中暴露,而不是等着市场反馈。
  4. 测试可能会不决定产品的质量,但是测试人员的能力却会决定产品质量。

再牛逼的测试遇到能力不行的团队质量也是一样上不去 所以质量是整个团队人员的体现

想问这个 leader 我觉得他的角色没什么问题,需要经常吐槽什么呢?不深入业务?

匿名 #13 · 2017年03月17日
K米测试 回复

为什么在无法推动流程优化的情况下,第四条不能改成:
4.开发可能不会决定产品质量,但是开发人员的能力却会决定产品质量?

匿名 #14 · 2017年03月17日
K米测试 回复

另外即便是同类产品,由不同的产品来设计也是会有不同的结果的,
为什么不能是
产品可能会不决定产品的质量,但是产品人员的能力却会决定产品质量?
(除非你认为交互设计用户体验易用性等等不算产品质量)

wuyu 回复

哈哈 缘分

在实际的项目过程中,遇到了同样的问题:
我觉得核心问题不在分工的模式,而在于岗位的内容跟职责有没有沟通清楚。
一个团队测试的产品,接二连三出现问题,线上 bug。显然大家心知肚明有问题。
但是是否有问责,压力是否有传递到具体的人,才是关键。

在团队达成共识之后,再去研究是测试用例的问题,还是产品开发不给力,彼此协作不到位。再去找相应的解决方案更好。

你说的都对,但是在公司层面,你的这个说法属于扯皮,因为没有什么卵用,你说呢?作为一个测试人,我永远先在测试上面找问题

匿名 #18 · 2017年03月20日
K米测试 回复

出了问题先从自己身上找原因是对的;
某些公司里,对规范质量等理解的不到位导致混乱,在这样的公司可能确实我说的是没卵用的;
但是,
软件质量,一定不是单测试能决定的。

这句话和以上是没有冲突的。

需要 登录 後方可回應,如果你還沒有帳號按這裡 注册