已经五年没写代码了,并且在过去的这五年里,一直拒绝写代码,因为自己从中感受不到快乐,换句话说,写代码对于我来说简直就是一件苦差,所以我特别佩服那些代码高手。 不过,因为项目的自动化测试没有像我预期那样,遭遇了多方的挑战,于是,我自己去反思,是什么原因会导致自动化测试的恶评。反观过去,最大的问题,就是自己的参与程度太低,不光如此,因为工作量的关系我也不要求TEAM中的测试人员去负责自动化测试用例,而是由相关的开发来实现。这样的做法,在团队比较小,测试资源不足的情况下的确是很不错,但是,当团队不断扩大,测试人员也不断增多的情况下,还是由开发来写测试用例就是不恰当了。一方面,开发人员太多,并不是每个开发人员在写测试代码的时候都严格遵循规则,导致一些测试代码的可维护性过低;另一方面,开发同事对测试不感兴趣,写测试用例缺乏像写代码那样高度的责任感和激情,测试代码的质量通常不高。而且,只有自己参与了,才知道哪些做得好哪些做得不好,才可以持续改进。对测试团队来说,写自动化测试用例,对于他们的价值来说,也会更高,大家成长得更快。 当然,在现实中使用测试人员写开发代码也的确有些困难,项目的开发步伐太快,而1:8测试开发比例,的确很难让一个测试人员完成所有的测试代码开发。但是,如果将自动化测试当作一个TASK,测试人员挑选其中的一些自动化测试TASK来实现,的确又可以做到。 测试用例大部分人都可以写,但测试框架就不一定了,应该需要有一个对业务熟悉、对系统具有全局观并且有一定的代码能力的人来搭建测试框架,并且每种类型的测试用例都提供一个例子,这样其他人写测试用例的门槛就低了。 于是,我重新回归原点,尝试着去写一个自动化测试框架。当自己真的去写的时候,发觉写代码并没有想像中的那么难,慢慢地,发觉写代码其实也很有乐趣。特别是测试代码,并不需要非常高深的技术,有基础的人都可以写。 这个教训应该吸取,作为TL,要参与到实际的工作,而自动化测试,测试人员应该要参与,当competence不足的时候,应该去build up,而不是避免。