2.1 本案例研究的背景
这个案例研究描述了我（指Henri）在一个快速成长的新公司里的经历：刚开始的时候，大约有50个员工，但仅仅过了五六个月，员工数量就增加到超过100人。由于人员数量增加太迅速，导致后来加入的很多开发人员和测试人员缺乏对产品的基本了解。知识的交流被极大地忽视了。结果，产品和测试的质量都很差。
办公室里有大约50 ~ 60个开发人员及20个专用测试人员，分别分布在同一办公大楼的各个楼层。测试人员报告产品中存在的问题，但由于测试质量差以及缺乏对产品的充分了解，以致这些问题往往被忽视。通过改善开发人员和测试人员两个群体间的交流，开发和测试工作都从中受益并且质量都得到了提高。所以，良好的交流是开始考虑自动化测试的先决条件。
【真知灼见】
不要尝试对设计很差的测试实施自动化，先完善测试，再进行自动化。
一个包含大约30 ~ 40个测试的典型的发布测试只在一个平台上运行，这就可能需要15 ~ 20个测试人员花费3 ~ 4周的时间。同时，由于发布测试中有更多的bug修复周期和测试周期（一般是4 ~ 6个周期），因此，在可以发布一个产品的新版本之前，过去需要大量的时间。由此可见，将以上过程实现自动化的需求是非常显著的：周期必须缩短，人力资源必须减少，并且测试人员必须在多个平台上运行测试。
一开始，我们使用Java语言开发了一个能够满足以上需求的内部工具，随后再将更多的新功能逐渐添加进去。到目前为止，这个工具的一个更新的版本也已经开发出来了，且又增加了一些新功能。测试也是用Java语言开发的。虽然自动化测试是从GUI自动化开始的，但是基于命令行界面的测试也变得日益重要，因为它可以使团队更方便地通过已安排的分工协作进行自动化。
虽然当时有一些现成的测试套件可用于测试数据库，但是我们并不知道使用什么自动化工具来进行数据库的测试。另外，我们的数据库有当时市场上还没出现的一些特殊功能，而这是现有的测试工具无法测试的。虽然当时已经开发出了一款内部测试工具，但是它根本没法满足我们的需求。那时，我们突然有一些可用资源来开始这样的一个项目，基于这些原因，我们进一步开始测试工具的开发。
