组织结构-借调测试
大部分情况下,开发与测试会向同一个产品管理者汇报,彼此是一个团队,照理说会平等相处、患难与共,但是实际情况是测试始终在向研发妥协。即使如笔者所在公司,测试与研发为独立部门,且测试直接向总经理汇报,这样的组织架构下,测试给研发让路也是家常便饭。遇到的理由诸如:设计如此、技术难点时间不足、项目时间不够先上线、客户催得紧先发布、代码不规范缺陷反复出现、质量不行就不断的发补丁包......测试疲于奔命导致漏测多,测试没有时间专注于复杂环境测试、性能测试中,在功能测试、黑盒测试中反复打转,更重要的是发号施令的领导们并不站在测试一边,验收至上。
不断产出的有缺陷的、早产的产品仿佛让这个行业变成一个巨大的草台班子。(代码就这样神奇的运行起来了......)
在Google,测试是独立存在的部门,他们被称之为工程生产力团队,测试人员也不会专职在一个产品上,他们依据不同产品团队的优先级、复杂度,然后用类似于租借的方式分配测试人员给产品团队。测试人员可以独立决定优先级,也绝不会在可靠性与安全性等问题上妥协。这种借调模式可以让SET与TE始终保持新鲜感,而新鲜感可以更好的暴露产品问题。这种模式使得测试人员可以更好的提升自己专业能力,在不同领域自由穿梭。
开发模式
Google经常在最初的版本里只包含最基本的可用功能,然后在后继的快速迭代的过程中得到内部和外部用户的反馈,在每次迭代时都非常注重质量。
敏捷开发是行业内很多公司的现状,在Google,产品在发布之前,要经历金丝雀版本、开发版本、测试版本、发布版本。
金丝雀版本:每日都要构建的版本,用来排除明显不正确的版本;
开发版本:开发人员使用的版本,具备一定的功能并经过一些测试;
测试版本:通过了持续性测试的版本,一般是最近一段时间内的最优版本,可是看做内部试用版本;
发布版本:从十分稳定的测试版本演变而来,,经历了内部使用与质量考核,可对外发布。
在Google,上述模式称为爬、走、跑模式,由慢变快,由简便繁,循序渐进。
测试类型
与常规的单元测试、集中测试、系统测试不同,Google用小型测试、中型测试、大型测试来命名测试类型,这表示Google注重测试规模范畴还不是形式。
小型测试:自动化实现,用于验证单独函数或功能模块的代码是否按照预期工作,注重功能问题、数据损坏、边界值错误、条件错误等。小型测试由SWE来进行,SET少量参与,TE几乎不参与。
中型测试:自动化实现,用于验证模块间交互、彼此调用的正确性。由SET实现并执行中型测试,SWE深度参与并分析,TE手动执行一些非自动化的用例。
大型测试:自动化&探索式测试,关注所有模块的集成,使用真实用户使用场景和实际用户数据进行测试,验证是否符合用户的需求,需要消耗较长的时间来执行用例。大型测试由TE主导,所有工程师均需参与其中。