在传统开发模式下的敏捷测试团队实践

先来看看敏捷实践之一,Scrum模式的人员结构：

开发工程师，测试工程师，Product Owner，Scrum Master，文档工程师，技术支持人员。

其中文档工程师和技术支持，例如DBA，都不是每个团队的必要成员。

Product Owner - 行业/业务专家。这个角色代表客户的立场，不需要技术背景，只要提客户需求，并确定需求的优先级。他告诉团队他需要什么，但是不干涉工程师们在技术上如何实施。

Scrum Master - 打杂的。他屏蔽所有外界的干扰，提醒工程师们履行预先约定的职责，安排会议，提供团队需要的资源。他不是项目经理，他也不是技术领袖。他是团队中最困难的角色，多数情况下需要背黑锅。

对于传统测试团队来说，这个模式非常适用。

测试工程师是已有的。Product Owner和Scrum Master完全可以由测试经理来兼任。

看起来似乎是换汤不换药。其实不然。

作为Product Owner的测试经理，只需要把测试任务发布在公告板上面。由团队成员自由选择任务。当任务完成之后，也只要把任务卡片挪到相应的区域。这样就节约了大量分配任务，编写任务报告，沟通任务状态的时间。而且在整个Sprint(任务周期)中，测试经理的缺席完全不会导致任务停止。

测试工程师有自己选择任务，和任务执行方式的权力之后，会更有主动性和成就感。对于保持团队的活力和稳定性非常有帮助。

由于敏捷模式中，每个Sprint都是固定期限（一周到两周，一般不超过一个月），完全没有delay的概念。这样就迫使测试经理不得不把有限的资源放到最重要的任务上。事实上，大部分商业软件中，有商业价值的功能仅仅是少部分。次要的功能即使有缺陷，客户也不会在意。

当每个Sprint结束之后，整个团队都要进行retrospective活动。这样可以及时反思不足，同时巩固优势。长此以往，团队的生产率和实用性都将获得极大提高。