<script type="text/javascript"><!--
google_ad_client = "pub-1926348199765453";
/* 336x280, 创建于 09-3-10 */
google_ad_slot = "2470758040";
google_ad_width = 336;
google_ad_height = 280;
// --></script><script src="http://pagead2.googlesyndication.com/pagead/show_ads.js" type="text/javascript"></script>
我——作为一名测试人员——有一个与众不同的习惯:每当要加入一个新项目的时候,我总会找到项目中的同伴,真诚而亲切地说:“为了更好地合作,我有5个约定,希望大家能尽量遵守”。
约定1. 业务分析师们,我们其实是同一个角色的两种面孔,请叫上我们参加客户需求会议
我们的团队需要让客户频繁的得到可用的软件,客户的不断反馈会给软件的未来做出最正确的方向指引。
如果我们交付的软件有很多质量的问题,存在大量的缺陷,客户会被这些缺陷的奇怪行为干扰,没有办法把注意力放在软件本身的价值是否符合他们的真正需
求上, 不能给出最有价值的反馈。所以,我们只有频繁的做测试,在每次交付之前都把质量问题找出来告诉我们的团队,问题才能及时的得到改正。
而我坚信“prevention is better than cure”(预防胜于治疗),我会要把工作的重点放在预防缺陷上,这样可以节省Dev们很多修复缺陷的时间与精力。
为了达到这个目的,我需要跟你一起参加客户需求会议,尽早的了解客户需求与使用软件的惯常行为。那么在你完成需求的验收条件的定义的时候,我也基本完成了测试用例的准备。
我们可以赶在开发人员们写代码之前就告诉他们我要测什么,让他们减少因为过于乐观而漏掉的一些重要的有破坏性的情况,减少缺陷的发生。这是我测试的一项重要任务。
如果你们在大部分需求都整理好了再交给我们,我会浪费掉等待的时间。更重要的是,开发好的软件里面已经有很多本来可以不存在的缺陷在里面了,开发人员们可能需要加班加点来保证在项目最终交付时间之前把它们改好。这样很容易产生新的缺陷的。
所以,请让我尽早了解需求,请不要让我到项目后期才能开始测试。
约定2. 开发人员们,虽然你们是编写自动化测试的专家,但请听听我们意见
我知道,对于你们,自动化测试不过是利用junit, rspec, selenium,watir,uiautomation等等写出的“另一段程序”而已。而对于80%的QA来说,编写自动化测试并不是一件简单的事情。
不过我仍然相信,有测试人员介入的自动化测试更有价值。
你们用单元测试,集成测试来保证代码的质量。然而你们的这些日常测试离代码更近,离最终用户还点远。很多测试都不是在测软件功能。
你们可以把功能测试写的又快又多,而我们可以指出什么功能测试最有必要加到自动化测试中。
你们平时大部分精力都在编码上,没有太多时间去查都有什么缺陷。而我们可以指出什么地方缺陷可能会出现的比较频繁,建议在这些脆弱的地方加自动化测试。
所以请听听我们的意见,我们可以给你们提供这些信息。
约定3. 项目经理们,请不要要求我们测试软件的所有路径
软件测试是一个永无止尽的任务。基本上没有什么软件简单到我们能够尝试完它的每一个可能的路径的。就连一个看似简单的微软计算器都有无穷尽的路径,无止尽的输入,更何况比这个更复杂的商用软件。
如果你们担心没有尝试过全部的路径不可靠,疑惑我们怎么敢说这个软件质量是好的还是坏,都有什么风险。请你们先注意,我们是跟业务分析师一样,都了解软件的价值的。价值可以帮我们做出判断,什么时候可以停止测试并对客户说我们的软件已经满足您的要求了,请放心使用。
因为我们了解价值,我们可以肯定的说哪些软件的使用方式是至关重要的,哪些是不太可能出现的。我们会在全面测试了软件以后,把主要精力放在价值高的功能点上。合理的利用项目有限的时间。
因为我们了解价值,我们可以正确的把发现的问题分类。我们可以帮助dev们把精力放在重要的缺陷上,避免把时间放在对于客户微不足道却不得不花费大量精力才能修正的问题上。
所以,请不要要求我们无止尽的测试一个软件。我们了解价值,请相信我们的判断。
约定4. 迭代经理们,如果对于交付风险有任何疑问,请来询问我
BA和Dev们都是关注一个软件在什么情况是可以良好的工作。而我们除了验证这些情况以外,大量的时候都用在寻找什么样的情况软件不能正常的运行。
所以除
了针对定义好的软件行为进行测试,我们还会做很多探索性测试。我们通常可以通过这样的测试发现一些没有定义的、不曾预期的行为。这些行为往往将会构成软件
交付的风险。
我们会告诉你们现在都发生了什么问题,分别分布在哪里。
我们会告诉你们,在什么情况下软件可能会有异常行为,是不是会牵连到其他的部分,是否可以绕过去。
我们会告诉你们,哪些部分功能比较不稳定,需要更多的留意。
约定5. 测试人员们,那些敏捷实践对于我们也是有用的。
结对不是dev们的专利。我不希望总见到你们独自坐在自己的位置上冥思苦想。走出去,跟其他队友多多交流!
多跟测试队友交流,pair看看设计的测试用例是不是够全面,独自一个人想到的未必足够好。他们会给你诚恳的意见的。对他们,也请一样认真对待。
如果你发现开发人员们做出的架构决定使测试工作变得更困难。那么请大声地告诉他们,design for testability(提高你们设计的可测性)。
如果你发现业务分析师写的需求无法验证,定义的客户行为不够具体,一个用户故事中包含太多了功能点,等等,那么也请大声地告诉他,INVEST(独立,可协商,价值,可估算,短小,可测)。
也请你们多跟开发人员结对写自动化测试,既可以帮助你们学习怎样更好的编写自动化测试,也能帮助开发人员们结对更多的了解用户行为。
这就是我的五个约定,它们是我在团队中顺利展开工作的基础。
作者:覃其慧,ThoughtWorks敏捷咨询师。她参与了大量的敏捷软件开发的实践和敏捷咨询。目前主要关注以价值为驱动的敏捷测试。
分享到:
相关推荐
简单:遵循最佳做法,标准和约定的最简单方法。没有插件:Jekyll网站必须保持由GitHub Pages构建(和托管)的能力(没有禁用的插件)。快速:在最流行的网络速度测试中,它必须得分尽可能高。合规:必须遵守国际和...
大多数项目是使用高度自动化的devops管道交付的,该管道需要开发人员根据一些非常特定的约定编写代码。 下表列出了所有方法论注释及其适用的团队角色。 笔记标题开发者经理顾客必读必读应该读必读必读应该读必读...
本书是智捷iOS课堂团队编写iOS系列丛书中的一本,目的是使一个有Objective-C基础的程序员通过本书的学习,能够从零基础到在App Store发布一款应用。全书分为4篇: 第一部分基础篇,介绍了iOS一些基础的知识。 第1...
ADO.NET 2.0 大批量数据操作和多个动态的结果集 ADO.NET 2.0 异步处理 在ASP.NET中使用WINDOWS验证方式连接SQL SERVER数据库 改进ADO.Net数据库访问方式 ASP.NET 2.0 绑定高级技巧 简单实用的DataSet更新数据库的类+...
团队合作 敏捷软件开发价值 我们需要约定 配对编程和提取请求 记录您的知识 发现未知 关注您的新闻 技术能力 它们并不总是更新 抽象,混凝土,层和依赖关系 期末课程 组成重于继承 职能 他们应该很小 掌握Git 最好...
1. 用标准文档代替口头约定和笔记文档,让开发、测试、运维、协作有迹可循; 2. 快速用测试结果推动开发进度,让团队沟通更充分、管理有事实依据,实现敏捷开发。
进行Sprint回顾,以反映您的工作流程和团队动态。 随时都有暴民/配对计划! 有效利用git和GitHub。 频繁提交。 利用良好的提交消息来描述对队友的提交。 利用功能分支。 使用TDD创建一套单元测试和集成测试。...
“ Rocket-API”基于spring boot的API敏捷开发框架,服务端50%以上的功能只需要写SQL或mongodb原始执行脚本即可完成开发,另外30%同时不停的完善公共组件,此类文件上传,下载,生成,预览,分页等等通过一二行...
作为团队,不仅仅是告诉人们如何做事,我们还负责与客户共同创造创新产品。 我们重视长期合作伙伴关系,并通过大量产品分销给经济带来影响,并被客户推向市场。 此仓库是我们的剧本,其中包含我们在软件开发中的...