专栏名称: 51Testing软件测试网
51Testing软件测试网,人气最旺的软件测试技术门户,提供软件测试社区交流,软件测试博客,人才服务,测试沙龙,测试杂志,测试资料下载等全方位信息服务,是国内最专业的软件测试就业培训、企业服务供应商...
目录
相关文章推荐
51好读  ›  专栏  ›  51Testing软件测试网

让敏捷开发宣言来指导你的软件测试!

51Testing软件测试网  · 公众号  · 测试  · 2017-04-06 17:31

正文


  敏捷宣言(Agile Manifesto)是构建敏捷软件开发框架的基础,它总结了传统瀑布模式的思维过程,这是于我们接受敏捷宣言(Agile Manifesto)价值观念,指导进一步的软件测试需要首先了解到的。敏捷宣言(Agile Manifesto)适用于所有和敏捷(Agile)有关的事情:不同的框架,如Scrum,DAD(Disciplined Agile Delivery),SAFe(Scaled Agile Framework)和Crystal,这些都是源自于相同的原则。尽管与敏捷开发有关的框架不尽相同,但其原则和价值观念适用于遵循敏捷思维的所有人员和团队,也包括测试人员。让我们来看看敏捷宣言的四个主要价值观,并了解如何为团队工作服务。

  个体和互动高于流程和工具

  Agile作为开发过程的指导思想,重视的是团队成员及其相互协助,而不仅仅是流程和工具。

  这种价值观念同样也适用于测试人员。敏捷测试是建立在测试人员在整个软件测试的过程中与团队的其他人员进行持续的互动和沟通的基础上的,而不是来自于某一测试人员或业务分析师关于测试项目的具体见解和信息的单向交流。敏捷测试具有让每个人员都参与项目设计、测试与开发的需求,并且与整个团队保持不断的互动。他们是用户故事的共同所有者,他们的共同投入是在测试项目的过程中产生质量,而不是在测试结束时注重结果。例如,像大多数测试团队一样,我所工作的团队已经建立了一个测试管理系统,测试人员将测试用例添加到每个用户故事的中央存储库中。但是在短时间高强度的工作安排中,他们是想希望能够有单独的测试人员来完成这些工作。虽然有一些团队直接在门户网站上添加并编写了他们的测试场景,但是其他团队会发现在共享表单中编写和整合测试用例更容易,就会对它们进行审查,然后把它们全部添加到存储库门户中。虽然在每个sprint阶段中都需要有流程和工具帮助将测试用例储存在通用储存库中,但是让团队协作商讨结果作为最佳方案是我们认为的最好做法。所有流程和工具仅用于帮助敏捷团队的工作生活更轻松,而不是使流程复杂化或过度转型。

  工作的软件高于详尽的文档

  同敏捷开发一样,敏捷测试人员也应该花更多的时间来实践测试系统并寻找新的方法来运行,而不是仅仅做详细的记录来测试案例。不同的测试团队会使用不同的方法来实现测试和文档之间的平衡,例如使用单线方案,探索性测试,软件风险测试和错误检查列表,而不是使用测试用例来覆盖测试,创建和使用足够多的与软件测试或者开发有关的项目文件。利用用户故事和Scrum,我们有从事测试一个敏捷项目产品。其基本流程是,根据用户故事中规定的要求,创建测试场景(使用足够信息执行的一线程序),这些场景都很通俗易懂,连被发送给他们审查的开发人员都能够理解。测试场景的编写和执行都是由同一个人来完成,高级测试人员可以随意测试或审查用户故事,以便于能够在完成测试并将其添加到公共储存库之前能够对输入进行改进和完善。

  客户合作高于合同谈判

  这是敏捷思维价值观念中核心的一条。让客户满意高于一切。敏捷思维重视客户的需求并要求与客户保持沟通,以实现对客户需求的完全掌握。而不是通过僵硬的合同条款去框定客户要求。敏捷测试的核心价值与这点相同,即尽全力通过与客户的沟通来达到完成客户所要求的测试任务。在通过测试人员的审查后,在单个用户故事中或在单个sprint中提供给内部版本的内容将会被传递使用。因为每个要求都没有详细的合同文档标准,敏捷测试人员在测试过程中通常会根据自己的实际情况进行质疑。如果用户在交付结束后不满意,因为没有合同或文件来隐藏,所以他们会不断地用"用户的眼镜"来思考与完善。作为一名敏捷测试人员,当我看到一个功能正常工作时,我会质疑它是否放置在用户能找到的位置。即使用户故事没有提供与性能相关的标准,我们也会讨论在6秒的页面加载时间内是否可以让人接受。在我看到一个应用程序功能正常后,我仍然会思考,发现开放的后台任务没有关闭而导致用户的机器在几个小时操作仍然在线。这些职责都没有被纳入标准的模块中,但它们对用户来说都是有价值的,需要纠正。

  响应变化高于遵循计划

  敏捷思维提倡创新改变,其整体目标是灵活,能够根据实际的变化调整相应的步骤。所以,与传统的软件开发方法不同,敏捷开发测试必须创新,团队能够对项目的整体规划有整体性的改变。

  同样,敏捷测试也是这样。敏捷测试面临着连续回归过载的负担,并且随着需求的频繁变化,返工率还可能会倍增,导致测试工作的反复进行。

  但敏捷测试团队的存在就是为了适应和改善这种情况,他们应当具备提前计划方案应对这种情况的能力。。他们可以按照计划进行白盒测试,持续自动化功能测试,更多是依靠API级测试而不是UI测试,特别是在用户界面可能发生变化的初始阶段这种情况之下。这种方法减轻了测试团队的负担,可以节省他们的时间,提高创新能力,从而寻找更好的用户场景。

  让敏捷宣言指导你的测试工作

  当测试人员陷入困境和实际工作难题时,可以向敏捷宣言寻求帮助。

  改变思维过程和价值观念,也许能够使你测试工作变得大不一样。

 
推荐阅读

点击阅读☞敏捷团队中测试人员的角色

点击阅读☞敏捷脑图测试用例实践之路

点击阅读☞从敏捷工程实践中获益的五种途径

点击阅读☞一个测试者眼中的敏捷和Scrum方法

点击阅读☞敏捷十年,成效几何?



点击左下角“阅读原文”查看更多内容!