软件测试培训

400-111-8989

热门课程:

软件测试培训 > 软件测试职场

如果把公司的测试都开除了，结果会怎样？

发布：软件测试培训
来源：软件测试职场
时间：2017-09-26 14:59

对任何一个专业岗位，我们都应该保持一些敬畏，反智主义只适合开玩笑的时候，不能成为做事态度。

若干年前，我在知乎上看到一个很有趣的问题：

为什么互联网公司不开除测试，转而让大众来测，找到一个Bug给100元?

答：大家的讨论很有意思，不少都是围绕100块够不够、给不给、怎么给来说的。我的角度是，测试是产品团队里一个重要的角色(团队早期可能由产品经理来兼任这个角色)，没了他们还真的不行。

默认前提是，开发已经做了单元测试和冒烟测试(原则上冒烟测试应该测试来做，但人家都被你们开除了啊，只好让开发来做了，至少要保证交给大众的是一个能跑起来的产品)，这两项总不至于期望大众来帮忙做吧。

很多Bug其实并不是非黑即白，也许产品就是这么设计的。这些内部的测试知道，但外部的大众不知道，他们用起来觉得不爽，当Bug提了，这钱是给还是不给?哪怕公司内部，当测试发现此类问题(比如为了安全考虑，第二次输入密码的确认框不允许复制粘贴)，开发说这是一个需求/特性，还得再把产品经理叫过来一起讨论，外部可做不到。

专业的测试需要测试用例(TestCase)，但常见的测试用例(临界值相关、内存会不会泄露、特殊字符等……专业测试人员玩起来一套一套的，分分钟把开发认为没问题的程序挂掉)在大众那里可做不到，更不要说TC评审了。或者说，大众永远是知其然不知其所以然，所以只能做黑盒测试，没有办法做白盒测试。

专业测试提的Bug是分级的(成熟的产品应该有Bug分级标准和规范)。研发流程里应该有相应规定，几级以上的Bug必须全部close才能发布;开发也会按照级别来确定修复顺序，并不是所有的Bug都需要马上修复。而大众提交上来的Bug，还得额外安排人去做分级Review。

专业测试会把Bug指定给特定的开发或产品经理，背后的逻辑是这些特定人员知道技术角度的模块划分，以及对应的负责人，只有这样才能方便流程向下执行。而大众提交上来的Bug，还得安排人去做assignto这个动作。

专业测试懂得用开发明白的语言描述Bug，能说清楚是什么机器、什么系统、什么版本，特别是能说清楚“如何重现”。而大众提上来的Bug，出错环境不明确，Bug重现不了，急死你。

内部经常有针对Bug的讨论，部分Bug可以defer或reject。那么问题来了，谁来牵头组织讨论，以确定Bug状态的流转与控制?可不要指望大众会“跟进”自己提交的Bug。

如果开发比较牛，能理解大众提的Bug，但改完后谁来确认是否修复，谁来close这个Bug，整体的回归测试谁来做?

以上还只说了狭义的功能测试，性能测试、压力测试怎么办?大众没法帮你模拟10万人同时做某个操作。还有，自动化测试谁来做?

QA——质量控制相关的事情还没说呢。

其实，这个做法接近于UAT(用户接受度测试)，也有人叫验收测试。经常由产品经理代表用户做(当然，有资源最好让用户亲自来)，不是找Bug，而是看产品是否满足用户需求、设计是否符合用户认知，等等。

这事儿很好，有条件都做吧。但更多的目的是找个理由和用户互动，而不是找Bug。

所以，测试还是很重要的吧，虽然在早期团队中，经常“全民测试”，但这个角色与产品经理截然不同的思维方式(产品抓大放小，测试关注特例)，对团队是个很有必要的补充。