开发人员与测试人员的划分

     <div id="news_body">     <p> 查看英文原文：<a href="/misc/goto?guid=4958338948709674457">The Developer-Tester Divide</a></p>     <p><strong> 从此以后他们幸福地生活在一起</strong></p>     <p> 关于开发人员和测试人员的关系，人们阐述了很多，讨论了很多，争论了很多。而貌似一旦这两者坐在一起，对峙便开始了，两者间的争论多于相互认同。显然，这不利于实现两者合作的目标——向用户提供价值。</p>     <p> 让我们来分析事情的来龙去脉和现状，思考如何做得更好。</p>     <p> <strong>史前时期</strong></p>     <p> 在最开始，不存在测试人员，只有开发人员。软件开发人员和软件项目的其他人员比起来并没有特别大的不同，除了如下事实：他们是软件项目的主要成本。准确地说这里的成本并不完全是指开发人员自身(虽然那时优秀的开发人员并不好找)，而是开发时间以及运行软件所需的资源（比如巨型计算机）。从经济角度考虑，专门成立测试人员是行不通的：开发软件的时间如此昂贵，为测试人员分配时间显得很浪费。</p>     <p> 没有专门人员检查工作，软件开发人员只好自己做测试。因为开发软件的时间如此昂贵，他们通过检查日志、打印信息以及离线“调试”来确保软件正常运行。那时还没有可用于调试的 IDE，开发时间如此昂贵，可不能在查看成百上千页的打印数据上花费太多的时间。因此检查数据的人都是开发人员，这样大家使用彼此熟悉的术语，对问题心知肚明。这样，尽管速度还不够快，但整个团队能够和谐地前进，。</p>     <p> <strong>开始分裂</strong></p>     <p> 随着软件行业的高速发展以及计算机成本的降低，软件公司在考虑成本的同时也开始关注软件质量。软件使用者开始变得挑剔，他们经常在初次使用时就不满意，要求软件公司修复或改善他们所购买的软件。</p>     <p> 保证软件质量的方案之一就是验收测试：客户在软件系统上执行应用场景。这些场景就像是软件公司和客户之间的契约：软件系统只有通过这些场景测试才能够被客户接受。</p>     <p> 最初，开发人员会自己执行验收测试，或者由客户执行验收测试，然后将问题反馈给开发人员。但软件公司很快就意识到开发人员不擅长于处理和客户的关系，于是隔离客户和开发团队的想法开始萌芽。</p>     <p> 存在的问题不仅仅是客户和开发人员之间的沟通。因为验收测试有时无法达到预期效果，人们越来越意识到应该对开发团队进行更加严格的质量监控。若由其他团队的开发人员进行质量监控，则会导致软件成本增加；而进行质量监控不需要理解错综复杂的软件是如何工作的，因此软件测试人员这个职业便产生了。</p>     <p> 当然，这种组织结构的变化并不是自然而然产生的，组织结构变化需要管理上的支撑和协调。所以经过几年的发展，软件项目中开发人员和测试人员两种角色的界限还是不清晰，</p>     <p> 随着软件测试领域的发展，越来越多的测试人员需要提升自身的技能，于是开始产生了相关的方法论和培训需求。培训和认证机构看到了这个市场机会，开始提供测试人员以及开发人员培训服务。随着方法论的逐渐成熟，测试专家开始涌现。之后开发和测试领域都有各自的专家，开发人员和测试人员的界限清晰起来了。</p>     <p> <strong>双城记</strong></p>     <p> 开发人员和工作人员在思维和工作方式上截然不同。开发人员认为自己是创新家，他们从无到有创建出软件，却常常招测试人员指手画脚。另一方面，测试人员苦苦忍耐开发进度，而当终于从开发人员手里接过软件时却发现软件是个废物。质量始终难以过关，测试人员重复测试出主要应用场景的错误，花费了不少时间。由于时间有限，很多应用程序没能完全通过测试。</p>     <p> 开发人员认为测试人员就是敌人，因此可能会把软件发布抛在脑后，使出浑身解术避开测试人员。测试人员认为开发人员不够专业，产生了很多本可以避免的 bug。软件团队中弥漫者诸多不信任。</p>     <p> 软件公司中的这两个党派之间还存在另一个问题：软件需求以及测试场景的沟通问题。因为思维方式的差异和语言的歧义性，软件需求经过再次表述，接着再次被理解，结果和实际会有很大出入。而这些理解上的出入直到测试阶段才被发现，相互指责随之爆发。</p>     <p> 最后一个会引发两党冲突的问题是时间鸿沟。开发人员说可以测了，测试人员便开始测试，开发人员接着进行新功能的开发以保持生产率。然而，当测试人员报告 bug 时开发人员的开发工作被扰乱了，开发人员开始抱怨测试人员见缝插针，指手画脚。</p>     <p> 开发派和测试派之间的紧张局势显然不利于减少浪费和产生有价值的产品。两派之间的冲突导致了重复工作，相互指责，而软件产品难以有见光的一天。</p>     <p> <strong>敏捷之桥</strong></p>     <p> 敏捷实践一开始就以开发出能良好运转的软件作为目标。这是很重要的一步：敏捷宣言的倡导者来自软件行业的各个领域（开发人员、测试人员和管理人员），他们把业务价值放在第一位，任何事情都应以它为依托。</p>     <p> “完整团队”是其解决方案，这是试图将客户和开发团队捆绑在一起的极限编程实践。敏捷组织也有测试人员的概念。</p>     <p> 因为开发人员与测试人员有了共同点并需要紧密协作，他们恢复了之前抗拒的行为：交流。</p>     <p> 他们开始使用相同的术语交流需求是什么。语言障碍消除了，双方在应该怎样做和哪些事情还未解决上达成一致。</p>     <p> 最重要的是，在一个 sprint 中，功能特性被开发和测试，所有发现的 bug 都被修正。这样，开发人员和测试人员之间的时间鸿沟消失了，因为他们始终在相同的迭代周期中协作。</p>     <p> 当开发人员和测试人员在同一迭代周期中协作时，他们发现了更好的情况：测试人员在流程早期捕获错误和决定怎么处理，这样对开发工作产生正面的推动，开发人员也从迭代中受益：在 sprint 中捕获和修正的 bug 都不算是真正的“bug”，只有逃脱出迭代周期的 bug 才会被当作真正的 bug 记录下来——开发人员可不愿意成天被别人说自己开发的软件是有 bug 的。</p>     <p> <strong>改造</strong></p>     <p> 敏捷团队实践也产生了奇特的社会学副作用：开发人员和测试人员之间的界限不再清晰。敏捷团队中开发人员做着各种各样的事情，他们介于开发人员和测试人员之间。开发人员开始参与测试，而测试人员则学会了怎样开发以及怎样编写代码做自动化测试。没有人能够做所有事情，但每个人都学会了额外的技能。</p>     <p> 另一个边际效应是软件质量的提升。敏捷实践认为每个人都应该关注质量。开发人员肩负起本来的职责：保证他们的代码能够正常运行。软件质量提高了，测试人员则可以在一般性测试之后开始探索式测试，使软件质量更上一层楼。</p>     <p> <strong>美好结局？</strong></p>     <p> 试图获得成功的敏捷团队还一直处于发展变化之中。敏捷软件公司正在尝试创建功能特性团队，这样的团队不仅仅由开发人员和测试人员组成，还包括了其他角色。</p>     <p> 但这样的公司还是少数。大多数公司还没有涉及真正的协同敏捷软件开发。开发人员和测试人员仍然被相互隔离，他们认为从业务角度考量这两种角色就应该被分开。</p>     <p> 敏捷实践已经证实，通过流程以及协作可以打破开发人员和测试人员之间的隔阂。成功的敏捷实践必然包括开发团队和测试团队的融合。没有重新组织以使两者融合，是不可能获得成功的，或者用敏捷的术语：不可能获得良好运转的软件。</p>     <div id="come_from">      来自:      <a id="link_source2" href="/misc/goto?guid=4958338949509587580" target="_blank">InfoQ</a>     </div>    </div>