Work smartly or 偷懒

在我发表了Code Review+Debugging的文章之后，看到了一个很典型的comment，我想简单回应一下。

很赞同你的看法，但是目前绝大多数的test都是第一种模式（包括Microsoft的大部分team），因为tester要负责automation，test case。

如果我没有理解错的话，意思是tester要负责automation, test cases, 因此没有时间去搞code review和debugging。不巧的是，我的工作也主要在test cases和automation上，甚至很多manual tests, 但是我还是有时间去搞code review和debugging。那是为什么？

其实我也面对类似的问题。在我要往下一阶段发展的情况下，领导对我的要求是要proactively地工作，要看到别人看不到的，别人没想到的，要做一些创造性地工作，要做一些对整个team有帮助的工作。而具体做什么？怎么做？则完全要靠自己。我就问了类似的问题，我说工作太忙，没那么多时间去想这些问题。领导的回答是要work smartly。是的，我后来分析自己可能一直也算是work smartly, 只是自己形容自己的行为是“偷懒”。虽然我对于自己下一阶段的发展也还处于摸索阶段，但是我想我还是可以回答这个comment, 因为我已经通过work smartly or 偷懒经过了这个阶段。

首先我想说一下公司的工作和个人的发展很多情况下是互相矛盾的。很多人总是想依赖公司去发展，我觉得这是个误区，真正地，起决定性作用的还是要靠自己。比如comments里的这个问题：tester要搞test cases, automation, 怎么去搞code review和debugging呢？那么我的答案就是偷懒，有原则地偷懒。

对于测试来说，我们的目的是用户使用产品的过程中不会遇到问题，而实现这个目的的手段就是找bug，而具体怎么找bug确是非常灵活的，这就是测试工作最大的魅力之一。你从事测试的工作千万不要拘泥于什么测试理论，测试方法等等，一定要有自己的主张和特点。比如有些人的工作是黑盒测试，他就认定了自己不能用白盒测试方法。有些人是手工测试，就认定了不能采用自动化。非得要跳槽找一个白盒，或者自动化的工作才能够开始从事。这是不对的，对于你所负责的模块，只要能找到bug，你应该可以采取任何的测试方法，而即使是专门的白盒测试人员也不能拒绝使用黑盒测试方法，专门从事自动化测试的人员也不能排斥使用手工测试的方法。因为，每种方法自然有它的特点，优势和擅长的地方。只有最适合的测试方法，并不存在最好的测试方法。

由于测试工作是如此地灵活，因此我就可以进行偷懒了，当然我是有bottom line的，那就是一定要保证自己负责的模块不出大问题，就算出大问题一定要有一个合理的理由。而我偷懒也不是真正的偷懒，我是要用省出的时间去进行自我提升以及从事更高技术含量的工作。比如，我在test cases和automation上省出来的时间可以进行code review和debugging, 以及pentest等等。这样的话就发生了很多有趣的现象。有的人追求100% automation, 而我只实现60-70%; 有的人test tool 要写的perfect, 连help都写进去，而我只写最核心的代码；有的人test code 写的很fancy，好像水平很高，而我则认为他是把简单东西搞复杂了，而我更喜欢把复杂的东西简单化。总而言之，在他们尽心尽力做好本职工作的时候，我却把一些精力放在了其他地方。这样长期下来，大家的差别可能就会显现出来。

以上只是个人理解，也许这不是领导所指的work smartly，只是给大家点建议，以及回应这个comment。最后说一下，code review+debugging刚开始是需要花些额外的时间，因为毕竟有learning curve在里边，但是以后的话，这种模式以我自己的经验来看并不比传统的模式更花时间，甚至可能更省时间。这个我可以以后再谈。