
书摘:敏捷测试
本书面向敏捷团队的测试人员、过渡到敏捷开发模式的测试和质量保证管理人员以及学习如何处理测试的敏捷团队。
本书介绍了敏捷测试、敏捷测试与传统团队测试的区别、敏捷测试人员的转变,包含了几十个测试相关的问题和解决办法。

本书面向敏捷团队的测试人员、过渡到敏捷开发模式的测试和质量保证管理人员以及学习如何处理测试的敏捷团队。
本书介绍了敏捷测试、敏捷测试与传统团队测试的区别、敏捷测试人员的转变,包含了几十个测试相关的问题和解决办法。
Jaibeer Malik最近发布了一个关于如何在团队中评估和引入代码质量的系列文章。如果你现在需要学习关于代码质量的知识,或者要给其他人介绍相关想法的话,这些文章你可能会很感兴趣。文中提供了关于这个主题的简要介绍,并为进一步研究代码质量给出了指南。
Selenium是一款开源Web自动化测试工具,最近发布了1.0版,标志着Web自动化测试领域正式加入了一名新成员。在其新版本中,除了修正了若干Bug,最引人瞩目的就是Selenium RC增加了对Google Chrome浏览器的支持,同时Selenium官方网站上提供了完整的用户指南。
质量是否就意味着没有缺陷拉项目后腿?Mike Bria、Lisa Crispin、James Bach以及 JB Rainsberger 展开了一场辩论,不仅讨论了质量的含义,而且讨论了质量的现有定义对我们工作的限制。
Elisabeth Hendrickson,“testObsessed”的作者,谈到了在敏捷项目中给bug分门别类的想法,用做抛砖引玉。她的想法是,在迭代中发现的问题不能算是bug,只有产品负责人才有权利把某个东西叫做“bug”,在健康的敏捷团队中,理应不需要任何bug跟踪系统。
过去几周中,Joel Spolsky和Robert C Martin(又称Bob大叔)之间就测试驱动开发和OO设计的SOLID原则有一场公开论战。这里是对论战的总结和简单回顾。
软件开发世界里有这样一个长期存在的问题:测试人员和开发人员的比例多少才合理?Scrum开发列表中最近有一个帖子,询问敏捷对这个比例有什么影响。对第一个问题,答案应该“视情况而定”。对第二个问题,Elisabeth Hendrickson认为,敏捷团队能够用更少的测试人员,但是做更多的测试。
显然,.NET 4.0中最重要的特性是以契约框架来支持独立于语言的设计。如果正确使用,通过契约来设计能够显著地减少软件中的潜在缺陷,与此同时还可以减少需要生成的单元测试的数量。