在我的潜意识里，以前总有种不知从何而来的误解，认为QA（测试人员）只是在开发完的软件或者网页上点点鼠标，初步看看程序有没有错。有错的话，会把RD（开发人员）喊过来，用鼠标复现一次错误，然后让RD去改代码；没有错的话，算是大功告成了。

　　工作了才发现，事实并不是这样的。在一个同事身上发生过这样一件事情：他本来在QA部门实习，等到转正面试的时候，面试官对他说，你的能力大概还不能胜任QA，你可以考虑去做RD！这件事让我着实有些震惊。不过在公司工作了一段时间，发现身边的QA的确不比RD弱，无论是技术方面，还是工作态度方面。刚来公司实习的一个QA mm，什么Shell、Python都很熟，写test case，找bug也不在话下。有时候会一起和RD看代码、调bug，有次甚至一直到晚上十点半才下班，真是令人钦佩。还听说公司的好多中高层，都是QA出身，看来其中必定是有原因的。

　　RD常常会有一种莫名的优越感，认为是我把这个程序从无到有写出来的，大部分的功劳应该归我。代码写出来了，至于测试这种“小事”，让QA来做吧。如果有了这种“优越感”，那么思维会有局限，在这种思维里，下意识把开始写代码看作是起点，把程序可以运行起来并且貌似没什么问题看作是终点，其他部分，都不怎么关心。

　　QA同学则不然，QA更多时间是用来考虑代码写完之后的事情，他们不但会把整个软件当作是一个黑盒，去设计各种test case，之后还会进行压力测试，以检验代码在不同场景下的性能。有时发现了bug，还会自己去看RD的代码，进行静态的走查……所以说，QA应该是了解需求的，无论是功能上的，还是性能上的，因为这些需求是他们进行测试的依据。而RD通常都是听到一个需求之后，感觉自己懂了，然后开始码代码了，这样往往容易考虑的过于细节，而把宏观的Big Picture抛在脑后。

　　可能RD的确要比QA思考的更细节一些，比如这个数据结构是用数组还是用链表，应该调用哪个API等等，但是RD也应该像QA一样思考，时时不忘功能的需求，以及性能上的指标。一个合格的RD，写出代码应该只是开发的第一步，后续还应该写一个测试用例、性能测试程序等等，对于自己写出的代码要负责到底。既然QA会走查RD写出的代码，那么RD为什么不能和QA一起测试呢？： ）  另外，在编码阶段或者在编码完成立刻发现的bug，比过了一段时间再测试时发现的bug，所处理的成本要低得多。

　　不妨向QA同学多取取经，问问他们是怎么设计测试用例的，用了哪些自动化测试的框架，有了哪些代码静态检查、压力测试的工具。关键的，是要学习QA是如何确认软件是符合当初分析时的种种需求和规范的。这些如果都能学好，对RD应该大有裨益。