如果您已经阅读过敏捷测试系列文章的第一篇,敏捷的实质,您应该已经了解敏捷的定义,了解什么样的团队是敏捷的团队了。而您也可能早已开始思考,什么是敏捷测试的实质?敏捷的测试团队又是如何形成自我管理、自我发展的组织呢?测试团队又是如何安排日常工作呢?敏捷测试活动与传统测试活动有很大差异吗?为了进一步让您了解如何将敏捷原则运用到活生生的日常测试活动中,我们为您推荐敏捷测试系列文章的第二篇——敏捷测试的实践。
在敏捷活动如火如荼的推广运动中,我们显然无法预知如何在您的特定的复杂环境中您能否最后达成所愿,也无法为您预测出前进道路的分岔口可能唯一的正确的线路,我们却可以为您点起一盏明亮“街灯”,在这迷雾中驱除黑暗。我们将为您提供一个可以借鉴和可供参考的成功的敏捷测试实践案例。我们将逐一向您介绍、分析这个案例中的敏捷团队的组织结构,主要的敏捷测试行为,迭代的测试模型和一套以四周为周期的敏捷测试活动时间表。
请您运用您已具备的敏捷实质、敏捷原则的知识,并结合您的独特项目环境、带着您的问题,与笔者一起再度分析这个案例,希望您最终也能得到满意的答案,并随后开始实施部署敏捷测试。
测试不仅仅是测试软件本身,还包括软件测试的过程和模式。产品发布后才发现很多问题,很可能是软件开发过程出了问题。因此测试除了需要确保软件的质量,即软件做了正确的事情,以及软件做了应该做的事情以外,敏捷的测试团队还要保证整个软件开发过程是正确的。
敏捷开发的最大特点是高度迭代,有周期性,并且能够及时、持续的响应客户的频繁反馈。敏捷测试即是不断修正质量指标,正确建立测试策略,确认客户的有效需求得以圆满实现和确保整个生产的过程安全的、及时的发布最终产品。敏捷测试人员因而需要在活动中关注产品需求,产品设计,解读源代码;在独立完成各项测试计划、测试执行工作的同时,敏捷测试人员需要参与几乎所有的团队讨论,团队决策。作为一名优秀的敏捷测试人员,他(她)需要在有限的时间内完成更多的测试的准备和执行,并富有极强的责任心和领导力。更重要的是,优秀的测试人员需要能够扩展开来做更多的与测试或许无关,但与团队共同目标直接相关的工作。他(她)将帮助团队其他成员解决困难、帮助实现其预期目标,发扬高度协作精神以帮助团队的最终获取成功。需要指出的是,团队的高度协作既需要团队成员的勇敢,更需要团队成员的主动配合和帮助。对于测试人员如此,对于开发、设计人员,其他成员也是如此。
是的,敏捷测试也需要高度迭代工作、频繁得到 STAKEHOLDER、客户的反馈,需要动态调整测试计划、测试的执行。并且,敏捷测试人员参与到了更多的敏捷生产活动中,积极的影响了团队做出的决定和计划。
是的,“人”才是敏捷的实体,敏捷测试也是以人为本的。不难理解,“敏捷”的一切都围绕着人展开,如敏捷鼓励直接,平行的沟通;敏捷需要持续的客户反馈以及敏捷活动的设计,方案和决策需要团队协同制定等等,敏捷测试需要一支非同寻常的团队,不同于以往传统开发模式下的团队结构。关于敏捷团队、敏捷测试团队的组成和介绍,将是我们讲述敏捷测试实践的第一步。
“人”是重心,方法、策略是辅。为了适应不同的团队结构,不同的项目环境,敏捷项目和敏捷活动的实践也应该因“人”而异,但是,并不是说可以天马行空,我行我素。一旦脱离了正确的敏捷方法、和敏捷原则的指导,我们的敏捷活动就好比摸黑前行了。
这正是我们需要学习前辈和敏捷主义大师们的经验意义所在了,笔者在过去的实践中受益颇多的也正是前人的实践经验和方法。因此,学习前人的经验和方法,并运用这些最佳实践来帮助敏捷开发团队,甚至是传统团队来解决时下重要的问题是十分有意义的事情。笔者不敢妄自尊大将自己的一般实践纳入经典方法范畴,但经历了两年的研究和改进,笔者提出的敏捷测试的原则也得到了业内同僚和“大师”的普遍认可。经过多次和其他项目团队的经验交流,我们也不断的改进着我们的原则、方法。因此,笔者要非常感谢参与讨论的同僚们,没有你们的热情参与,也不会有今天的笔者信心百倍的执笔了。正如笔者在借鉴了前人的成功案例中的经验和方法之后定制了符合项目需求的测试原则一样,相信,读者们在阅读了笔者的敏捷测试原则和方法后,同样也会有所收获。而对笔者经历的敏捷实践活动中的方法和测试模型的讲解将成为我们讲述敏捷实践的第二步,也是本文的重点。
综上所述,笔者将运用本文的主要篇幅为大家讲解这个敏捷实践。它们是:
然而,敏捷测试不是一蹴而就的,做到真正的敏捷,无论是从传统测试模式向敏捷测试的过渡,还是组建全新的团队都是需要循序渐进的,同时也需要团队成员的通力合作和不断的实践来完善敏捷测试的实践原则和方法。