敏捷项目的软件测试

我们的项目实行敏捷已经近两年了，关于敏捷我相信大家已经比较熟悉了，我今天就先谈谈在敏捷的项目里如何实行测试的工作。

敏捷的项目对测试的影响

• 文档少，因此难以只是依赖文档来设计测试。
• 短迭代，需要更短的时间完成测试的工作。
• 频繁的变化，需要测试更具有探索性和适应性。

敏捷项目的正确测试观念

• 项目是以结果为导向的，所以测试同样是结果导向。
• 不以发现缺陷多少为目标。
• 以不断提高软件质量为目标。
• 测试人员的作用是帮助开发人员不断提高软件的质量，是协助性的。
• 测试人员不是批判性的。
• 测试人员能够尽可能的做能够做的工作，尽可能的早工作。
• “等待”在敏捷开发、敏捷测试范畴里已是一种错误概念。

敏捷测试的管理

• 敏捷项目的测试没有严格的角色。人人都是测试。
• 以测试任务为导向。测试任务即可以是开发来做，也可以是测试人员来做。
• 相同的质量目标。开发和测试有着同一个质量目标，因此也承担着同样的责任。
• 关注质量的提升，测试周期与开发同步。
• 要有全局观，不只是专注于发现缺陷。
• 为回滚做准备，本次迭代发布失败，可安全回滚至旧版本。
• 分享测试知识。
• 建立缺陷库，指导开发人员避免再次发生同样缺陷。

敏捷测试的执行

• 关注和推动单元测试。
• 持续改进自动化测试（因为软件的变化，已经对产品的深入了解）
• 短文档（测试用例可以不写，测试计划列测试点，测试类型，质量标准即可）。
• 对新增的或者引起变化的地方（可询问开发人员协助）采取探索性测试。
• 对稳定的部分添加自动化测试。

我们的项目之前的测试开发比例是1比5，质量基本达到客户的要求，为什么1比5可以，因为我说过，开发人员是可以做测试的工作的。现在觉得唯一有不足的地方是对稳定的地方进行自动化的回归测试。还有，我希望在自动化的探索性测试上有所进步。

最后，我还说一点是，我看到很多项目靠加班，不会休息的团队是不健康的团队。其实，项目往往不是短期行为，通常一个产品的至少需要半年努力和投入，长

时间的超负荷运转会使得工作效率低，身体透支等严重后果。项目中后期往往强度会比前期更大，这个时候，人员倒下和效率低不是一件好事情。所以，如果你的项目还要长期发展，应该帮助团队认识到轻松的团队氛围，张弛有度的工作安排是项目成功的最好方式。

当然，不加班，不代表上班时间不好好干。我们要求就是8小时以内，每周40小时。

最后，打个小广告，招聘软件测试人员，要求：2年以上web软件测试经验，有自动化测试经验更佳，熟悉web service测试者更佳，热爱敏捷过程。有意者发邮件至wangdeshui@gmail.com  msn:jack_wangds@hotmail.com

王德水 写于2010年1月4日23点 北京