《Google 软件测试之道》这本书我已经读完好几天了,并且是读的第三遍了,本来一直想写下读后感,但是一直迟迟不敢下笔。

一个原因是这本书里面的信息太多,可以说 Google 这个测试模式已经是超越了国内大多数公司好几个层级,很多公司完全可以把这个模式作为模版来学习。

另一个原因是,国内环境的现状,决定了我们肯定不会很快达到这个高度,看见摸不见,那感觉真是贼难受。

今天下笔,也仅仅是从自己角度出发,进行浅层次的解读,希望有更多的人一起加入探讨。

本书在一开篇的定位,就打破了「测试」的局限,Google 最开始的测试团队叫「测试服务」,之后演进为「工程生产力」团队,别看仅仅是名称的变化,不同的名称所代表的职责范围和目标却是完全的不同。

国内公司目前大部分团队的称呼还是「测试」,和 Google 的「测试服务」有些类似,工作重点都是表示层的验证,并且随时响应不同项目的测试(验证)需求。

还有一部分团队的称呼是「QA」,相对与「测试」,「QA」的职责会更宽泛一些,可以涵盖流程质量、测试质量和发布质量,以及各环节中所有可以更好保证质量的事,都可以由「QA」来推进。

「工程生产力」是相对「QA」更进一步的职责扩展了,就是除了测试和质量之外,还会跟进生产力提升,比如帮助开发更好的完成测试和质量保证工作,就是把测试和质量保证前置,转移给开发,测试人员给开发提供必要的支持。

听起来是不是很给力?但是要达到这个程度,测试人员就需要兼具开发的技能和测试的思维,需要会编程、能实现工具、平台和测试自动化。

每个新的机遇总是伴随着更大的挑战。

针对本书的阅读人群,我的建议是:
1.开发人员:质量不是某一个角色的事,是整个团队的事,可以了解作为开发角色应该如何更好的为保证质量做贡献。
2.有一定经验的测试开发人员:通过第二章关于 SET 工作的说明,可以对比下自己目前的工作内容,更好的明确自己的目标,更好的为保证质量做贡献。
3.有一定经验的测试人员:通过第三章关于 TE 工作的说明,可以对比下自己目前的工作内容,更好的明确自己的目标,更好的为保证质量做贡献。

不太建议初学者关注,原因最开始我已经讲了,对目前国内环境来说,这本书的内容更多的只是作为我们的愿景和目标,初学者往往会把这个作为现实去比照,然后就会大失所望。

另外,针对各章节的阅读方法,我的建议是:
1.精读:第 1、2、3、5 章,这几个章节分别介绍了 Google 测试的现在和未来,个人觉得非常有借鉴意义,可以尝试把部分内容逐步在一些发展比较好的团队中进行推进。
2.粗读:第 4 章以及附录 C,第四章是访谈,更真实的反映了 Google 真实的项目情况,所以看的时候需要做个提取,吸取自己关注的内容即可,附录 C 里面提供了几个工具,个人觉得挺有用,可以看看目前团队里面是否可借鉴。
3.略读:附录 A、B、D,略读是指不适合大部分人去读,同时这部分内容也不是本书的重点,如果有对这部分特别感兴趣的,可以按需调整即可。

最后,我再叨叨一句,看书最重要的是效果。

以上,不知道你是否看过这部名著?看过的同学有什么想法?你所在测试团队目前处于哪个阶段?欢迎留言和我探讨。

当然,如果你支持我上面的观点,请帮忙转发 + 点赞让更多人来看到,谢谢。


↙↙↙阅读原文可查看相关链接,并与作者交流