测试是什么?这个定义很难,但是测试不是“教条式的、强流程的、体力密集型的、耗时的”,测试不应该成为导致创新和开发过程变慢的阻碍。
Google成功的关键是什么?书中给出的建议是:不要招聘太多的测试。笔者所在的公司测试部门负责公司十几条不同产品线,每个产品线带有不同的项目分支,频繁的新需求、新适配对于笔者而言,测试工作常常是枯燥且重复的。而随着测试人员的增加,我们发现软件质量提升缓慢,测试工作效率没有明显上升,我们正在做事倍功半的测试。
Google测试方式看起来是违背常理的——在整个公司,我们只有非常少的专职测试人员,甚至比我们竞争对手公司的单个产品的测试人员还要少。在通往成功的道路上,Google的测试团队并非雄兵百万,我们更像是小而精的特种部队。
在Google,写代码的开发人员也承担了质量的责任,质量从来就不仅仅是一些测试人员的问题,在Google,每个写代码的开发者本身就是测试者。
质量不等于测试。
质量不是被测试出来的,这句话已经是老生常谈。如果最开始设计就是错误的,那么它永远不会因为测试而变成正确的。
当你把开发过程和测试放到一起,就像在搅拌机里混合搅拌那样,直到不能区分彼此的时候,你就得到了质量。
Google能用很少的专职测试人员的原因就是提升开发对质量的负责,如果一个产品出现了问题,第一个跳出来的是开发人员而不是遗漏这个缺陷的测试人员。测试是是一种预防行为而不是检测。在Google,测试工程师(TE)会把大量的时间花在模拟用户使用场景与自动化脚本编写上,TE是真正的产品专家。软件开发工程师(SWE)负责功能实现与独立模块的质量,而另一个角色,软件测试开发工程师(SET)则是负责编写代码提供给SWE用来更好的测试自己的功能模块,TE需要确认开发人员的测试工作是否到位,任何明显的bug都表明开发人员对于质量的马虎,当明显的bug逐渐收敛,TE就将精力放到用户使用场景中去,去关注安全性、访问速度等性能上。