敏捷测试人员的十条法则

发表于:2011-9-08 14:58

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:未知    来源:51Testing软件测试网采编

  (5)简单化

  Kent Beck的Extreme Programming Explained (《极限编程解析》)建议我们尽可能做最简单的、有用的事情。这并不意味着你最先尝试的事情必须有用,但应该是最简单的。

  敏捷测试人员和他们的团队面临的挑战不仅是生产最简单的有效软件而且还需要采取简单的方法以确保软件符合客户需求。这并不意味着团队不应该花时间分析主题和故事、思考合适的架构和设计。而是说,当业务部门的需求比较复杂的时候,团队可能需要将方案退回给他们,更简单的解决方案也会产生同样的价值。

  我们中的某些人在软件公司以测试人员和质量保证人员的身份工作时,曾经被要求制定质量标准。我们认为这是一种倒退,因为应该由客户团队来决定他们想要的质量水平。测试人员和其他团队成员应该向客户提供信息并帮助他们全面考虑质量问题,包括非功能性需求,如性能和安全。最终决定由客户拍板。团队能够通过简单、逐步的方法帮助客户做出高质量的决定。敏捷测试意味着通过最简单的测试验证某项功能存在或者已经达到客户的质量标准(如性能)。

  简单并不意味着容易。对于测试人员来说,这意味着采用能够找到的最轻量级的工具和技术恰到好处地测试。工具可以简单到只是一张电子表格或者清单。需要自动化回归测试,但是应该把它们分解到最底层以获取快速反馈。甚至简单的冒烟测试也可能满足面向业务的测试自动化。

  探索性测试能够用来了解应用程序和发现深藏的缺陷,但是应该从基本的、时间可控的测试开始,然后根据边界测试评估进展。简单性帮助我们关注风险、投资回报和改善最痛苦的问题。

  (6)持续改进

  想办法把工作做得更出色是敏捷测试人员应牢记的。当然,整个团队都应该具有这样的想法,因为敏捷的核心价值就是团队总是尝试更出色地工作。测试人员应参加团队总结会,评估做得好的方面和需要加强和改变的方面。测试人员把测试问题摆到整个团队中解决。团队通过采取过程改进实践(如总结回顾和阻碍代办事项等)最大程度地改善测试和所有其他领域。对于更严重的问题,团队一次只关注一到两个问题,以确保彻底解决了实际问题,而不只是做做表面文章。

  敏捷测试人员和他们的团队总是在寻找工具、技能或者实践以帮助他们增加更多价值或者得到更好的客户投资回报。敏捷开发的短期迭代更易于尝试新事物,以验证是否值得长期采用。

  学习新技能和提高专业技能水平对敏捷测试人员非常重要。可利用各种免费的资源提高专业技能,如探索性测试。可参加各种会议,加入邮件列表,阅读文章、博客和书籍以获取新思想。还要想办法自动化(或者从其他同事中获得帮助)平淡的或者重复性的工作,以此获得更多时间投入到宝贵的专业技能提升中。

  Weyerhaeuser公司iLevel部门的软件质量保证负责人Pierre Veragren指出了敏捷团队中经常见到的一种特点:“AADD(Agile Attention Deficit Disorder),即敏捷注意力缺乏症”。任何无法快速学习的事物都可能被视为无用的。敏捷团队成员讲究投资回报率,如果他们无法快速理解,他们就会转移目标。当你每两周或者更短时间就要发布一个产品级的软件时,这个特点并不是缺陷。

  总结回顾是一种重要的敏捷实践,让团队利用过去的经验把未来的工作做得更好。敏捷测试人员利用这种机会提出与测试相关的问题并要求团队集思广益地去解决它。这种方式使团队通过自我反馈来得到持续改进。

----------------------------------------------------------------------------------------------------------------------------------------------------

  Lisa的故事

  我们的团队曾经利用总结回顾会议获得了巨大的好处,但是我们认为需要一些新事物来帮助我们把工作做得更好。我建议维护一份“阻碍待办事项”,记录下影响生产力的各种条目。我写的第一条就是测试环境的响应时间缓慢。系统管理员找来两台便宜的计算机,把它们变成快速的新服务器。数据库管理员分析了测试数据库性能,发现单硬盘系统是个障碍,经理开了绿灯,安装了一个RAID以获取更好的硬盘访问性能。很快,我们就能够快速地部署构建和进行探索性测试了。

  ——  Lisa

----------------------------------------------------------------------------------------------------------------------------------------------------

  (7)响应变化

  在瀑布开发模式中工作时,我们习惯说:“抱歉,我们现在不能更改。需求被冻结了。我们将在下一个补丁包里做更改”。客户对此非常失望,因为他们意识到无法实现当前所有的需求。

  在为期两周的敏捷迭代中,我们可能会说:“好的,先在卡片上记录下来,我们将在下一个迭代或者版本中实现”,但是客户知道他们可以获得想要的变化,因为他们可以控制优先级。

64/6<123456>
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号