转载 测试工程经理的工作

测试工程经理的工作

Google的测试项目不仅仅依赖于本书前面已经提到过的测试工程师 TE和测试开发工程师 SET完成他们的工作，还依赖于测试工程经理 TEM这个角色的领导力和协调能力。测试工程师和测试开发工程师都汇报给测试工程经理。测试工程经理通常直接汇报给测试总监（译注：写作本书时， Google拥有六位测试总监。向每位总监直接汇报的测试工程经理用一只手就能数过来。独立贡献者一般向测试工程经理汇报，而资深工程师和技术负责人一般直接汇报给他们的总监。这种扁平的结构是为了能更好地协同工作，并降低沉重的管理负担。绝大多数总监也都会分出一部分时间，让自己作为独立贡献者工作）。所有的测试总监都汇报给 Patrick Copeland。测试工程经理需要拥有技术能力、领导能力和协调能力。他们通常都是成长于 Google的内部团队，而不是从外部空降的。空降的员工通常（但不是全部）都作为独立贡献者。即便是 James Whittaker受聘为测试总监，也有将近三个月的时间完全没有任何员工直接向他汇报。目前的测试工程经理中，有超过半数之前都曾做过 TE的角色。这并不奇怪，因为 TE本来就关注测试项目的各个方面，进而管理整个项目的人员也只是向前迈进了一步。 TE对于其测试的应用程序的功能特性了解得非常全面，而且在项目中与一般的 SET相比会更多地接触各种工程师。然而，成功的 TE或 SET并不一定就是成功的测试工程经理。在 Google，成功需要多方面的因素，我们努力选择合适的经理人选，并努力帮助他们成功。

想成为优秀的测试工程经理，第一条建议就是去了解你的产品。对于与被测产品相关的任何使用问题，测试工程经理都应该是专家。假如你是 Chrome浏览器的测试工程经理，你应该知道如何安装扩展程序、更换浏览器的外观、设置同步关系、更改代理服务器设置、查看 DOM、查找 cookie的存放位置、如何以及何时进行版本更新等。这些问题的答案，测试工程经理都应该能脱口而出。从用户界面到后台数据中心实现，测试工程经理都应该对自己负责的产品做到了如指掌。我记得我曾经问 Gmail的测试工程经理，为什么我的邮件的读取速度很慢。他向我解释了 Gmail服务器是如何工作的，以及远程数据中心在那个周末发生的一个问题所带来的后果。我本来没想要了解这么多细节。但是很明显那家伙知道 Gmail是如何工作的，而且了解影响其性能的最新信息。在 Google，这就是我们对测试工程经理的期望：相关项目中最强的产品专家。

与之相关的第二条建议是知人善用。在 Google，测试工程经理是产品专家并理解要有哪些工作需要完成，不过他作为经理，在实际完成这些工作的过程中仅起到少量的作用。真正完成工作的人是向他汇报的 TE和 SET。了解这些人以及他们的能力，这对能否快速高效地完成工作至关重要。 Google的工程师都很聪明，但是数量上并不充裕。我们从 Google之外招来的测试工程经理都反映他们项目缺少人手。我们的回应只是报以微笑。我们知道这不是问题。如果能够知人善用，经理可以让一个小团队发挥出像大团队一样的作用。资源紧缺能够促使项目的参与者职责明确。想象一下一大群人带小孩的情形：一个人喂奶，一个人换尿布，一个人逗孩子乐，等等。这些人中没有一个能和操劳的单亲家长相比更投入地照顾孩子。正是由于孩子的养育资源的不足，这才使得照看孩子的过程更明确有效。资源不足的时候，你只能被迫做得更好。你能更快地发现流程中的缺陷从而避免重复犯错。你会制定一个喂奶时间表并按时执行，你会把纸尿裤放在各种随手可得的地方。这种方式也会用在 Google的软件测试项目中。问题不能简单地通过增加人手来解决，就需要使用工具并使其流水线化。没用的自动化测试会被弃用。不能发现回归问题的测试根本不会被编写。如果是开发人员要求测试人员做这样的事，他们自己也必须要参与其中。不允许不必要的工作存在，也不需要不产生价值的改进。测试工程经理有职责优化整个过程。测试工程经理如果对产品有深入的理解，就能清楚地找到最高优先级的工作，对相关模块进行合理的覆盖。测试工程经理如果对他的团队成员足够了解，就能根据具体的测试问题安排具有最适合测试技能的员工。很显然，有些工作可能由于资源问题而无法完成。但是，如果测试工程经理处理得当，这些工作会是那那些最低优先级的部分，或者可以直接外包出去或交给众包用户和内部试用用户完成。当然，测试工程经理很可能犯错误，但是由于他的角色太重要了，这些错误可能代价很大。好在测试工程经理一般都相互认识而且关系密切（资源紧缺的另一个好处，就是人数少到他们不但能相互认识，还可以定期交流一下），经常相互交流经验共同提高。