在 agile tour Taipei 2014 中， 我们花了很大的篇幅， 安排了两个 Coding Dojo， 让大家了解如何来学习 TDD 的方法. 虽然 coding dojo 是个有效的方法， 但是并不是每个团队能这么幸运， 能够来参加这样的训练.
　　此外， 除了个人技术的问题外， 还有很多非技术性的问题， 象是时程的压力， 老板的期待， 团队成员的素质和自动化的策略等等， 你也必须要能够解决， 单单只改进了个人技术能力， 还是没有办法让整个团队做出成绩来的.
　　在我们的团队中， 一开始他们并没有自动化的经验， 外加公司分工细致， 开发人员不写测试自动化， 测试人员不见得都有能力写， 经理觉得开发人员不需要写. 在这样的有趣的环境下， 我们怎样让测试人员去做自动化呢? 以下是我们一些做法:
　　1. 找到有能力的成员
　　首先， 找到有能力的 team members 是必要的， 如果他没有写程序的能力， 我想可能任何人都很难推行测试自动化. 在台湾测试人员不容易找寻， 除了要能做手动测试外， 还要有能力做自动化测试， 这真的是超大难关.
　　很幸运地， 在花了 2 - 3 年时间， 让大多数的团队成员都具备这两种能力， 或许无法每个面向都很强， 但是只要有工具人的能力， 会让团队的调度容易很多.
　　2. 先求有
　　一开始目标是先设定为有测试自动化， 所以先试着要求对每个功能， 写少数的测试个案， 或者是只针对重要的功能， 撰写较多的自动化. 我们要的是开始做这件事情， 并不是要一开始做到好棒， 因为你需要克服时程的问题， 你要让工程师有时间学习. 更重要的事， 你必须在短时间内让大家看到牛肉在哪里. 这样才能让其他人愿意追随你.
　　3. 先打通技术难关
　　在写自动化测试时， 你要先串通测试程序， 受测程序， 以及测试环境. 这个地方会是困难的. 如果是开发人员直接来操刀， 难度会比较低. 但是如果是测试人员来写， 时间会拖比较久， 甚至会遭遇到一些技术性问题. 因此， 你可以请开发人员， 或者是程序能力较强的测试人员， 先把一些测试 scenario 写出来. 之后其他测试人员可以依样画葫芦， 这样不会让整个进度拖很久.
　　4. 要能天天执行
　　每天执行一次是低要求， 好是有 check-in 程序需要执行， 要在早时间点确认是否会影响大家. 还有一种方式是开发人员有一组 local 的 CI 环境， 在正式 check-in 到正式 CI 环境前， 自己先确认是否有问题.
　　5. 要能立即修复
　　我会跟测试人员说， 一旦出错后， 你需要在 5 - 30 分钟内， 找出错误在哪里. 并不是要威胁他们， 而是让他们知道， 一旦测试没通过， 会有很多人问说原因出哪里， 并且因为天天执行， 你会被烦到不行， 为了你能从这个地狱解脱， 你必须从一开始要好好精心设计， 让你能在短时间找出原因.
　　6. 加速执行时间
　　另外， 如果你要每次修改后能执行， 那执行的时间很重要， 因此你要想方设法， 让你的测试在短时间内完成. 否则上一个还没结束， 下一个 check-in 又进来， 那测试要到何时才能结束， 修改的影响要何时才能知道.
　　后要记住的， 测试自动化的重点在回归测试， 也是他重心并不是在找新的问题， 而是希望原有的测试个案能够全数通过. 但千万不要想说用这个东西去取代手动测试， 两者各有所长， 没有谁取代谁这回事.
　　那执行成果如何呢?
　　今年第一个项目， 一开始只有 12 个 cases， 中途来到 4X 多个， 等到 release 的时候大约有一百多个. 数字并没有很漂亮. 但是， 但是大家觉得这个自动化很棒， 因为在 build 一被建立出来时， 立刻告诉你是否问题， 很及时地让你收到反馈.
　　接着， 执行第二个项目， 我跟大家说， 你看之前那个项目自动化效果不错吧， 有尝到甜头吧! 那我们继续吧， 所以大家没有表示什么异义， 愿意继续尝试下去. 可惜这个项目没做多久， 被老板腰斩!!
　　然后在第三个项目， 我们又继续推行自动化， 这次我们 case 已经到达 6XX 多个， 并且开始分种类来执行， 有分基本功能组， 详细检查组. 此外， 我们还把效能测试也加到每日的自动化执行， 所以你可很快知道， 这样的修改是否对 performance 有影响.
　　明年会怎么演进呢?
　　这可能要明年才写得出来， 但是我们很高兴团队能有这样的进展. 我们可以很骄傲地说， 开发人员做不到的， 我们来帮他们做到. 他们不能挑战自己， 但是我们能 XDDD