51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 764|回复: 0
打印 上一主题 下一主题

[转贴] 基于敏捷模式下的质量研究

[复制链接]
  • TA的每日心情
    擦汗
    昨天 09:05
  • 签到天数: 1048 天

    连续签到: 1 天

    [LV.10]测试总司令

    跳转到指定楼层
    1#
    发表于 2022-5-13 09:34:31 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
    摘要:敏捷开发模式的特点是迭代与增量、快速响应变化。敏捷测试要求质量保证体系做到有成效、有效率地响应变化,敏捷测试要求测试人员 “尽早地和不断地测试软件”。

      敏捷模式
      敏捷模式注重的主要体现在以下五个方面:

      对于增量的检验需要经过验收阶段
      在理想的敏捷开发过程中,每个迭代开发完成后会产出一个可交付的版本。
      根据以往的测试经验,能够交付高质量的版本离不开测试人员的验收。倘若忽视了验收测试阶段,严重的缺陷就不可避免了。
      此时,就需要专业的测试人员来进行功能验证,而且这些测试一般是敏捷开发团队由于考虑不周或者没时间完成或者受限于设施配置而无法实现的。
      测试人员会尽可能地模拟真实用户的操作习惯,九成的情况都是要手动测试完成。所以,手动测试对增量部分的检验是不可或缺的。
      敏捷测试需要一位能够担任测试执行、业务验收、用户感受等多阶段的职责的手工测试人员,他在测试团队里起到举足轻重的作用。

      尽量压缩验收测试的时长
      每个迭代版本的开发时间都不长,验收测试往往没有多少时间去执行,那就要想方设法去压缩验收测试时长。
      要想缩短时间,可从以下两方面思考:
      如果开发代码的质量本身就很高,这样可以节省大量用于修复缺陷的时间;
      从测试角度来看,就要优化测试手段,提高测试效率。
      对于传统的验收测试,测试人员会编写测试用例,模拟用户执行测试用例,查看输出结果,再与预期结果比较,得出测试结果。
      而且编写测试用例花费的时间长,一旦需求变更,维护文档的时间也相应地拉长。

      以人为本
      敏捷发展模式注重个体能动性,测试工作也要尽量发挥测试工程师的灵感。
      如果仅仅按照设定的测试用例,按照测试步骤一步一步地执行,主观能动性就得不到发挥。在敏捷的过程中,没有精确的产品设计作为参考去写符合规范标准的测试用例。

      提高敏捷测试效率
      要保证产品原有功能的质量,就要提高测试效率。最好在每天的产品开发过程中,都能参与进去进行测试,以免出现回退问题。因此,高效的自动化回归测试将为原始功能提供最好的质量保证。

      及时收集用户反馈响应变化
      要及时通知用户软件更新,与团队进有效的沟通,并能够建立机制及时跟踪用户反馈的问题,以免发生遗漏。
      敏捷开发项目的团队结构
      敏捷团队的工作会因为功能互相分隔的小组变得难以开展。敏捷开发注重的是人与人的交流。这需要团队成员紧密合作,不管他们是在虚拟环境中工作还是在同一个地方工作。

      独立的质量保证团队
      许多组织,为了得到客观的产品质量评价,都设立了独立的质量保证团队。希望质量保证团队与开发团队独立开来,其原因有:
      1、拥有独立的检查和审计角色很重要。
      2、对于产品的质量,独立的质量保证团队能够给出客观的评审意见,不带有色眼镜。
      3、测试人员不能和开发人员过分亲近,要不然会被开发人员的思维方式带偏,不能站在客户的角度评价。
      4、测试人员和开发人员不能由同一个上级来管理,因为管理者一般会认为提交开发代码比提交测试代码优先级更高。
      我们提议重组人员结构,即使还有一小部分人认为独立的测试团队是必要的。
      与其让测试人员在编码完成后开始测试,把测试团队分离开来,不如让整个团队都视作质量保证团队,提供学习培训来帮助测试人员职业发展和分享思路。
      如果敏捷开发团队经理由测试质量保证经理来担任,大家可以培训测试人员除测试外的其它技能,从而推动测试人员往更高、更强、更能适应各种环境的方向发展。

      敏捷项目团队
      我们常常认为敏捷项目组是跨职能的,因为每个团队里的成员都带有不相同的职业背景。
      传统的跨职能团队和敏捷团队之间的区别是以整体团队运作努力的方式。成员不止“代表”他们在团队中的职能,只要项目或永久团队存在,他们就是团队的真正成员。
      因为项目的规模不同,项目团队的结构也可能不同。大的项目或许多项目的组织可能同时成功地使用了矩阵类型结构。来自以不同职能区域的人组合形成一个虚拟团队,他们仍然向每个人的组织汇报。
      在大的组织中,一批测试人员可能从一个项目转移到另一个项目。一些专家,例如安全、性能或者质量保证测试人员,可能同时服务于几个团队。
      如果启动一个项目,那么请确认工作需要的所有资源,在开始前确定需要的测试人员数量和技能。测试人员在团队开始时加入,一直工作到项目结束,那时,他们将转移到下一个项目。
      测试人员是团队的一部分,所以他们每天的工作与项目团队的其他成员的工作一起被管理。
      测试人员可以在更大的测试人员社区中发表想法,更大的测试人员社区包含大的组织中不同项目团队的测试人员,所有的测试人员可以分享知识和想法。在执行业绩审核的组织中,质量保证经理可能推动审查并从项目团队获得意见。
      任何新团队都需要时间来构建,如果项目时间较短或者团队是不断变化的,组织需要意识到在每个项目的第一个或第二个迭代中,新的队成员将加入团队并适应互相合作的环境。
      应在需要的时候重构组织,还要记得把客户也纳入组织中。最好的团队是学会一起工作和建立起彼此间信任的团队。

      质量工作角色
      在那些刚刚从传统模式转变为敏捷模式的团队中,人们依旧把敏捷QA(Quality Assurance)的职责等同于测试员的工作,觉得只要开发完项目代码后,QA只要负责执行测试,挖掘出缺陷就行。
      事实上,敏捷QA不仅仅是测试软件,更重要的是确保软件的质量和过程的质量。
      在敏捷项目开发过程中,敏捷QA经常会在不同的开发阶段与敏捷团队中的不同职能担当协作,从需求分析阶段开始介入软件开发过程,这样可以对不同开发阶段进行质量评估并改进开发活动,帮助项目预防缺陷,提高整个团队的质量保证意识。而现在团队中只设定了测试员这个角色,没有质量保证的职能,这样就会导致开发过程的各个环节的质量得不到保障。

    分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
    收藏收藏
    回复

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-11-19 00:49 , Processed in 0.057768 second(s), 24 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表