已经五年没写代码了，并且在过去的这五年里，一直拒绝写代码，因为自己从中感受不到快乐，换句话说，写代码对于我来说简直是一件苦差，所以我特别佩服那些代码高手。 不过，因为项目的自动化测试没有像我预期那样，遭遇了多方的挑战，于是，我自己去反思，是什么原因会导致自动化测试的恶评。

　　反观过去，大的问题，是自己的参与程度太低，不光如此，因为工作量的关系我也不要求TEAM中的测试人员去负责自动化测试用例，而是由相关的开发来实现。这样的做法，在团队比较小，测试资源不足的情况下的确是很不错，但是，当团队不断扩大，测试人员也不断增多的情况下，还是由开发来写测试用例是不恰当了。一方面，开发人员太多，并不是每个开发人员在写测试代码的时候都严格遵循规则，导致一些测试代码的可维护性过低；另一方面，开发同事对测试不感兴趣，写测试用例缺乏像写代码那样高度的责任感和激情，测试代码的质量通常不高。而且，只有自己参与了，才知道哪些做得好哪些做得不好，才可以持续改进。

　　对测试团队来说，写自动化测试用例，对于他们的价值来说，也会更高，大家成长得更快。当然，在现实中使用测试人员写开发代码也的确有些困难，项目的开发步伐太快，而1：8测试开发比例，的确很难让一个测试人员完成所有的测试代码开发。但是，如果将自动化测试当作一个TASK，测试人员挑选其中的一些自动化测试TASK来实现，的确又可以做到。

　　测试用例大部分人都可以写，但测试框架不一定了，应该需要有一个对业务熟悉、对系统具有全局观并且有一定的代码能力的人来搭建测试框架，并且每种类型的测试用例都提供一个例子，这样其他人写测试用例的门槛低了。于是，我重新回归原点，尝试着去写一个自动化测试框架。当自己真的去写的时候，发觉写代码并没有想像中的那么难，慢慢地，发觉写代码其实也很有乐趣。特别是测试代码，并不需要非常高深的技术，有基础的人都可以写。 这个教训应该吸取，作为TL，要参与到实际的工作，而自动化测试，测试人员应该要参与，当competence不足的时候，应该去build up，而不是避免。