QA只须找到Bug，扔给SE就完了么？

QA真的只需要做黑盒测试，找到错误就扔给SE，就完了么？

QA帮助SE定位错误，到底要定位到多深的程度？我想，最深的程度就是，SE放假了，QA也能行驶SE的职能，把错误给改了。

目前我们公司把SE和QA截然分成两派，SE做好后，就交由QA来测。是否有更好的安排方式？比如SE当一段时间QA，QA当一段时间SE。敏捷不是提倡全功能团队么？既有某方面的专家，每个人也乐于、有能力承担其它方面的工作，至少能够通过有效的结对与任何角色一起完成特定的工作。这样，对个人发展的广度也是有帮助的。

这样的话，QA与SE的座位布局可能需要经常变换，重排了。因为物理上阻隔了沟通，便不利于敏捷的实行。

我的想法主要受到文章（http://www.infoq.com/cn/news/2011/03/Ensuring-Product-Quality-Google）的启发。此文讲到：Google保证产品质量的方法和很多公司是不一样的。Google没有一个庞大的测试部门，相反，部分测试工作委派给了开发人员。

在传统的业务导向的软件公司（如穆迪），开发的软件主要是为了满足客户的业务需求。如果业务逻辑十分复杂，涉及到的行业知识很丰富，这时开发人员（SE）可能没有足够时间来进行需求分析，那么QA则可以更多地承担这种需求分析工作，进而成为业务专家。而对于37signals、google、facebook这样的公司，他们的软件开发其实是由工程师主导的。尤其是37signals公司，他们主要开发程序员使用的软件，开发者本身就是客户，他自己知道所要开发的软件是什么样，自然也是其软件质量的拍板者。这样的开发团队更强调测试的自动化，因而也只需要保留较少的专业测试人员。

我说的QA越殂代庖去改bug，是一种夸张的说法。QA有改bug的知识与技术，但不一定要QA亲自改嘛。正如有的同学所说的，QA更有生产力的工作是测试，SE更有生产力的工作是修改代码。比如架构师有能力去完成每一行代码的编写，但他更重要、更有生产力的工作是切分好系统，然后把任务分配给下面的开发者来完成。所以，我想强调的是，作为“全功能团队”的一员，你的头衔是QA，但同时也有修改代码的权利与能力，这不是很好么。这也是代码全体所有权的一个重要体现。

有一次，我们team的QA见SE很闲，就拉她去做了一天的QA。结果，这位SE测出了很多BUG。其中不少BUG都是与界面使用起来顺不顺有有关，或者是某些界面组件的行为不一致。但不得不说，这些bugs都是值得去改进的。QA Team的同学也同意这一点。这里我想提问的是，为什么QA没有把这些BUG提出来呢？一个主要的原因是，QA主要从业务的视角（远离代码、是否匹配业务需求）看问题，而SE则更多从更佳的操作流程、软件精简和一致性（接近代码、是否符合程序员的直觉）来看问题。

由此，我妄作推断：更加了解代码，不仅有利于重现BUG，也有利于发现更多的改进软件的建议。这条建议对SE和QA都适用。