我们是极限编程(XP)的早期实践者,在完全不了解测试人员应该如何工作的XP团队中从事测试工作.那时候,敏捷(当时还没有这个称谓)资料中对验收测试和专业测试人员的工作方式介绍得很少.我们通过自身的经验和小规模敏捷社区这两方面来学习.在2002年,Lisa和Tip House合著了《测试极限编程》,该书的出版得到了Janet的大力帮助.从那时起,敏捷开发模式开始演变,敏捷测试社区不断繁荣.在众人的群策群力下,我们对敏捷测试的学习更加深入.
我们凭借个人和合作的力量帮助团队过渡到敏捷模式中,帮助测试人员了解如何在敏捷团队中贡献自己的力量,并与敏捷社区的其他成员紧密协作寻找让敏捷团队在测试方面更加成功的方法.我们两人的经历各异.Lisa作为一名敏捷测试人员在稳定的团队中工作了若干年,针对零售,电信和金融行业的Web应用.Janet则在软件公司中开发各个行业的企业系统.这些敏捷项目包括开发消息处理系统,环境跟踪系统,远程数据管理系统(包括嵌入式应用和交互网络),石油天然气产品统计应用和飞机运输应用.她扮演过很多角色—— 有时是测试人员,有时是指导—— 但是她一直在努力使测试人员与团队的其他人更融洽.她参与团队的时间从六个月到一年半不等.
因为存在不同的视角,我们学会了合作和互补各自的知识库,并一起做了许多演讲和共同编写了许多教材.
本书的由来
目前,市面上已经出版了一些有关面向敏捷开发中的测试和测试模式的优秀书籍(见参考书目).这些书一般关注于如何帮助开发人员.本书的目的是在帮助敏捷团队通过业务人员能够理解的测试来更加有效地创造业务价值.我们想帮助测试人员和质量保证(QA)人员从传统的开发模式过渡到敏捷开发.
在本书中,我们将讲述如何通过实用,逐步的方式应用我们在不同团队中的经验成果和来自其他敏捷先驱的思想,帮助测试人员,质量保证经理,开发人员,开发经理,产品负责人和其他任何致力于敏捷项目高效测试的人员,交付客户所需的软件.但是,我们更关注测试人员这个角色,因为很多专业人员都会担当此任.
敏捷测试实践不局限于敏捷团队成员.它们也可以用于传统开发模式项目的测试.我们希望能够帮助在任何开发模式下的测试人员.
敏捷开发不是成功交付软件的唯一方式.但是,我们参与过的所有成功团队,不论是敏捷模式还是瀑布模式,都存在一些共性.其中包括,程序员编写和自动化单元测试和集成测试(覆盖多数代码),严格使用源代码控制和代码集成系统.测试人员从开发周期一开始就参与工作,并拥有足够的时间和资源来完成所有类型测试的任务.定期运行和检查自动化的回归测试集(在高层次覆盖系统功能).开发团队理解客户的工作和需求,与业务专家紧密合作.
人是促使项目成功的关键,而不是开发模式或者工具.我们喜欢敏捷开发,因为它的价值,准则和核心实践能够让人出色地工作,测试和质量是敏捷开发的中心.本书将讲述如何将敏捷价值和准则应用到自己的具体测试工作中,并使团队取得成功.第1章和第2章将详细讨论这个问题.
编写本书的方式
因为体会到敏捷开发的益处,所以我们采用敏捷实践来编写本书.在开始动工的时候,我们与世界各地的敏捷测试人员和团队讨论了他们遇到的问题和解决办法.然后,我们计划如何在本书中包含这些内容.
我们制订了一个两周一迭代的发布计划.每两周在我们的图书网站上发布两章草稿.因为我俩身处异地,所以要使用工具交流,并对各章实施"源代码控制",向读者发布书稿,并获得反馈.我们无法实时地"结对工作",但是各章会经过反复的审阅和修订,并通过即时消息进行非正式的"站立会议".
我们的"客户"就是敏捷社区中志愿审阅草稿的好心人.他们通过电子邮件或者亲自提供反馈.我们在随后的编写和修订中利用反馈作为指导.在所有草稿完成之后,我们针对修订做了新计划,其中包括了来自"客户"的所有积极的建议.
最重要的工具是思维导图.首先创建了一张思维导图描述全书的构思.然后对每一章创建思维导图.在编写各章之前,我们基于思维导图展开头脑风暴.在修订的时候,重新查看思维导图,帮助我们发现可能遗失的想法.
因为我们认为思维导图存在很大作用,所以在每章的开始部分包含了相应的思维导图.希望它们能够帮助你总览本章包含的所有信息,并鼓励你尝试使用思维导图.
读者对象
如果你曾经问过以下某个问题(我们已经听到过许多次),那么本书将对你有所帮助:
如果开发人员编写测试,那么测试人员做什么
我是一名质量保证经理,公司正在实施敏捷开发(Scrum,XP,DSDM等),我的职责是什么
我曾经在传统的瀑布式团队中做过测试人员,并且对敏捷非常感兴趣.我应该需要哪些知识来适应敏捷团队

下一页