职业经验 测试团队的痛点

K米测试 · 2016年10月02日 · 最后由 zhangbb1991 回复于 2019年12月09日 · 5115 次阅读

痛点:

  1. 测试流程不清晰,没有很好的规范来引导产品测试
  2. 测试要点设计薄弱,团队成员用例设计能力参差不齐

测试人员的个人能力竟然会决定产品的质量!!!---非链接,请勿点击

在你们的团队中是否有这样的问题?你们是怎么解决的,希望和大家一起交流。

天天在谈测试技术,回过头来发现,技术背后的基础是测试最本质的内容:测试用例。
做了将近 5 年的产品测试,一直都在研究测试技术,突然有一天(就在最近)产品质量发生雪崩,让我开始思考原因:
为什么:产品出现 BUG;因为:测试发布了带 BUG 的线上产品

为什么:测试发布了带 BUG 的线上产品; 因为:测试用例不完善

为什么:测试用例不完善; 因为:?????

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

项目流程是否合理

  1. 需求阶段:段是否讨论的充分
  2. 开发阶段:是否有设计,设计是否被评审
  3. 测试阶段:测试用例是否被评审
  4. 预发布阶段:上线前除了本次改动的功能,产品上下游功能是否有回归测试 5.可以考虑灰度发布 6.缺陷总结:对于线上 Bug 或者事故的 review 及经验分享,优化流程,改进工具等避免同样的问题再次发生

人员能力是否能胜任当前的工作

  1. 执行力&态度问题?
  2. 能力问题?对自己负责产品的架构及实现细节是否了解?有没有能力 review 开发设计?。。。

我们说的测试技术,未必就是做做自动化&&性能测试。一个了解被测系统架构,懂代码的测试同学,在深入了解产品需求的情况下,可以指出开发设计是否合理,除了功能外,还能从性能,安全等角度评估出项目的风险,这些最终都能在测试用例中体现出来。

套用 monkey 在新书中的话,“测试不是比技术精深,不是比谁代码写得好,最终要提升项目,团队的效率,解决问题才是真的。”

测试用例不完善?因为():
A.产品上线时间紧迫,没有充足的时间去分析需求、功能。
B.产品和开发侧提供的原型、需求和详细设计等有缺陷,无法有效地供测试人员进行参考分析。
C.测试人员本身不重视/分析设计能力不足。
D.以上都是

跟踢后卫一样,不能犯致命的错误;再怎么防守,也有牛逼的前锋踢进门。

警告 @aizaimenghuangu 一次,下次再有广告植入,直接删账号了。

#4 楼 @Lihuazhang 抱歉 真心没有广告植入的想法,只是想突出这句话,而链接可以,就随便给了一个链接,无心的还请见谅。

为什么:产品出现 BUG;因为:测试发布了带 BUG 的线上产品
### 测试背锅???Bug 是谁生产的?

为什么:测试发布了带 BUG 的线上产品; 因为:测试用例不完善
### 测试背锅???

为什么:测试用例不完善; 因为:?????
### 测试用例完善了就没有 bug 了吗?

业务和技术不是对立的 是个层次关系 作为一个 qa 团队 职责的核心是保证业务质量 业务质量是目的 而达到这个目的 你可以堆人可以堆技术也可以堆资金 (购买咨询和服务) 这只是方式不同 不能因为人做不到就认为人的能力不行 技术没达到目标就坏技术无用 商业服务没达到效果就怪商业模式不行 你得找到你们的核心问题 举个简单的例子 如果你们漏测 可能是你们的用例不充分 这个时候你可以堆人加强用例覆盖申请更多人力和时间 也可以堆技术分析代码覆盖率业务建模加强问题分析规则 也可以堆资金加强灰度联调找众测云测和咨询 公司不可能给你足够的资源 剩下的问题就是找最低的成本最短的路径去解决问题

#5 楼 @ycwdaaaa 非常认同你的观点,测试策略不一样,我们公司你说的这两种产品都存在,而我负责的是线上产品,能够实现快速修复,不过有一点 APP 却介于这两者之间,明显是 ToC,却存在 ToB 的问题,更新迭代不会这么快,及时解决了现有问题,用户的更新速度没有想象的这么快,特别是 iOS 的版本。

回过头来还是策略的问题,针对 APP 应该有一个更好的测试策略

@ycwdaaaa 认同你的观点,现在我们也面临同样的窘境,每次都是到上线前发现严重的问题导致加班到天亮进行修复,有可能上线后还有 bug,甚至延期一个工作日,产品设计开发变更频繁,自动化接入的时机靠后,前期只能依靠大量的人工去覆盖...不知道有没有好的建议,接口也做了一些,但是没有什么明确的体系化的东西形成

按照我之前的工作流程是这样的,上线由测试提交上线申请 (并且说明存在的问题情况),产品确认后开发才打包提交给运维。产品确认的标准是没有不能容忍的 bug,测试漏 bug 在所难免,但是致命的肯定不能有吧,要说要背锅三者都要背...

#8 楼 @seveniruby 非常认同你得观点,我们现在基本就是按这个套路走的

这个痛点大概都经历过,质量是个系统性的问题,测试部门只是这个系统的最后环节,往往成为背黑锅的。提高质量的策略就是全民皆兵,这个是制度设计的问题了,好的管理制度可以迫使每个环节每个角色都会很自觉的注重质量问题,也只有这样才可以最大限度的消灭 bug

#8 楼 @seveniruby 线上产品出现问题,站在测试的角度,难道不是测试漏测?

#14 楼 @aizaimenghuangu 如果出现之前的测试和研发模式未曾覆盖的点, 那么就不应该算是测试漏测, 也不需要质量背锅. 共同改进即可. 比如在人力资源紧张的情况下, 明确只测试主流的平台, 如果某个偏门的浏览器, 或者偏门的改造版 rom 或者浏览器爆出问题, 就针对性的解决即可. 不需要非要拉人背锅.

杯水车薪,看前面大佬们已经说得很多了。其实我个人觉得质量这个问题 谁背锅都不对,我们的目的是解决问题,而不是让谁背锅。

Boxer 回复

版本上线前才发现严重的问题,那是不是项目管理有问题,导致测试滞后?
如果项目管理合理的话,研发按时交付经过自测的产品,那么测试进展会不会顺利一点?
从你的描述来看,首先应该在项目管理和研发质量问题,其次才是测试侧的问题。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册