建设网站培训,如何自己做网站站长,网站背景图片自动切换,楚雄做网站建设的公司测试左移的由来
缺陷的修复成本逐步升高
下面是质量领域司空见惯的一张图#xff0c;看图说话#xff0c;容易得出#xff1a;大部分缺陷都是早期引入的#xff0c;同时大部分缺陷都是中晚期发现的#xff0c;而缺陷发现的越晚#xff0c;其修复成本就越高。因此#…测试左移的由来
缺陷的修复成本逐步升高
下面是质量领域司空见惯的一张图看图说话容易得出大部分缺陷都是早期引入的同时大部分缺陷都是中晚期发现的而缺陷发现的越晚其修复成本就越高。因此为了降低缺陷修复成本我们期望在更早的时间发现缺陷。 那么上图是否完全没问题呢不是的这张图来源于1996年的一本书《Applied Software Measurement》这张图画成的时候敏捷宣言还没诞生呢敏捷宣言诞生于2001年。在传统背景下需求是明确且相对固定的需求产生的缺陷可以忽略不计。同时在需求阶段产生的问题可能会引起整体方案的返工因此需求产生的问题不太会以软件缺陷的形式来体现。
需求质量呼唤测试左移
随着软件生态的发展软件需求越来越复杂多变需求的有效性和传递效率也备受挑战。受大环境影响需求阶段引入的缺陷就对软件的研发成本造成了影响。同时软件的研发过程越来越成为一个需要高效协作的整体各角色之间的界限也变得相对模糊。
为了让质量理念更早的介入软件研发过程也为了降低缺陷修复的成本、减少不必要的返工需求的质量变得尤为重要。测试左移因此而生需求分析人员与测试人员需要协同工作共同保证需求的质量。
加上需求阶段重画一下上面的图理想情况下我们容易得出以下结论
缺陷的引入从需求阶段就开始持续到研发阶段达到峰值然后趋于平缓缺陷从需求阶段就开始陆续被发现到测试阶段达到峰值然后趋于平缓从需求阶段到研发初期缺陷修复的成本极低开发后期到上线缺陷修复成本一路攀升至高点缺陷发现的数量少于引入的数量但在上线前后缺陷发现数量大于引入数量 因此为了获得更经济的资源投入产出比我们认为应该在需求阶段和编码初期更多的发现缺陷从而减少修复成本和返工这也正是测试左移的价值所在。
那么该如何保证需求的质量呢我们在不同的时期面临的需求其形态是有差异的所以需要深刻理解这些差异并有针对性的设计质量活动加以验证。
需求的几个层次
一个很现实的例子
一天大老板说“微信小程序不错我们内部OA流程得做一个你们安排一下年内发布就行。” 这就是一个来自大老板的一句话需求。
项目经理拿到这个需求看到“年内发布”需求管理看板上就可以多一张卡只有几个字“OA小程序”排期可能暂时安排在第三季度。
过了俩月送走了一批艰难的需求暂时松口气的项目经理扫到这张卡瞬间头皮发麻这还有一个老板亲生的大坑呢得尽快填上。喊来产品经理快出一版方案再找技术经理大致估一下工作量。
只有一句话显然是没法出方案的产品经理和技术经理各自焦头烂额的研究了两天又花了半天暂时碰出了OA小程序的初版方案。一周后方案通过评审。这时根据既定方案产品经理细化了一些需求用户管理组织管理流程管理表单配置权限配置审批配置微信登录等。
即将进入研发阶段需求又会被再次细化。以用户提交请假单的场景为例需求可被细化如下图。进入研发后开发以一定的优先级顺序来领取需求进行研发。 需求的三种粒度
在上面的故事中为了服务产品规划和不同的管理诉求需求呈现出以下三个粒度
史诗故事 特性故事 用户故事
史诗故事 Epic粗粒度的描述需求通常需要多个迭代才能完成主要用于版本规划时记录和跟踪该功能特性故事 Feature也叫主题故事是一系列相同主题用户故事的集合主要用于迭代规划、优先级排序和整体估算用户故事 Story迭代开发的最小单元是较细粒度的需求描述主要用于迭代交付过程中的估算、跟踪和管理 不同粒度需求的质量保障
史诗故事方案验证 测试设计
在产品演进过程中当面临的需求还是一句话时测试人员能做的事情并不多。当史诗故事即将进入迭代规划进行方案设计时测试人员就可以参与进来了。
方案成型初期测试人员可以参与方案讨论和技术可行性研究贡献既有业务流程或潜在业务逻辑针对有较大质量风险的方案测试人员有责任提出质疑并给出建议。
方案确定后测试人员就可以着手进行测试设计了测试设计包括但不限于针对该功能的质量预期大致的测试规划现有的测试资源评估主要的质量风险及响应方式等。 特性故事需求评审 测试计划
临近迭代需求会以特性的形式体现此时测试人员可以参与需求评审
针对功能需求测试人员先验证需求是否有效包括需求价值确认需求涉及场景是否完备与现有业务逻辑是否有冲突针对功能需求背后的支撑性需求进行澄清确认支撑性需求的范围、验收标准、测试方式等此外还需要考虑用户体验考虑需求的拆分是否合理是否便于估算和迭代管理
质量活动方面测试人员可以落实测试计划了如各种测试活动的安排测试效果的评价测试的重点和难点测试阶段的输入和输出等在这个阶段都可以确认了。
用户故事需求验收 测试执行
故事启动时测试人员需要补充需求验收的用例以及需求影响范围内的回归用例等。在这以后测试人员主要关注在需求验收和测试执行上按照测试设计和计划进行测试确保最终的实现质量。而在此阶段测试人员尤其需要关注投入产出比把有限的精力用在刀刃上。行之有效的做法是在测试计划阶段就明确好各功能的质量标准和资源投入并在测试执行阶段时刻回顾。但计划是死的人是活的万一在测试过程中我们发现计划赶不上变化就需要随时跟团队沟通并进行灵活调整了。
当然质量活动并不是以功能测完上线为结束而是需要完成一个完整的闭环。测试阶段以后的质量活动不在本文讨论的范围内在此就不做过多展开了。 小结
测试左移之所以重要是因为我们要在缺陷引入的最初阶段就发现它把缺陷扼杀在摇篮里而不是等着它像雪球一样越滚越大。而这里的误区在于测试左移要求的测试活动尽早介入而不仅仅是把测试人员进行左移。因此团队里的每个成员都需要有测试左移的思想都可以从一开始就绷紧质量这根弦确保每个人的工件质量。
而在需求的质量保证活动中测试人员也需要时不时换帽子有时可能是终端用户有时可能是产品经理也有时可能是产品负责人。不管戴什么帽子保证各个工件的质量以及各工件的顺畅集成都是测试人员可以关注的事。质量相关我们责无旁贷。 文/Thoughtworks 于晓南 原文链接https://insights.thoughtworks.cn/shift-left-testing/
