QA,从1.0到4.0

迄今为止,敏捷开发方法在各个公司都有了长足的发展,曾经的测试人员慢慢的在向QA职能过渡,但依然很多人不了解QA和测试的区别是什么。

敏捷实践不断地演化过程,使项目中各个角色不断弱化,同时,对每个成员的要求也越来越高。“全功能团队”的提出,不单单是对开发的要求,对QA来说,想要在快速变革中具备竞争力,就现在所具备的技能来说,还是远远不够的。

简单聊聊我所经历的“QA发展史”

1-qa4-0

(图片来自ThoughtWorks UX设计师 高媛媛)

QA 1.0 —— 机械化流水线作业

在我实习的那年,软件领域还很少提及QA,伴随着瀑布模型的兴起、软件工程规模的不断扩大以及市场对软件质量要求的提高,催生出了“测试工程师”这样一个角色。那时他们的职能很单一,每天的工作就是在各种测试环境中按照详细设计的文档,编写测试用例,并逐条测试,检查功能完整性,发现软件中可能出现的功能缺陷,并进行追踪。

这个时期是软件测试的原始时期,对测试人员的技能要求不高,只要对文档理解透彻,做事细心,是很容易胜任的。此时的产出和交付物可度量,虽然如此,测试工程师只是执行者,能力和价值都无法最大化,却被每天重复的工作所累。

QA 2.0 —— 过程化带来不同的工作内容和价值体现

我毕业的时候,开始接触敏捷方法,团队规模从百人变成了仅有十人左右,信息平等取代了逐级传递,分散的信息源( 客户的每一封邮件和每一句对话都可能是我们将要做的功能 )取代了几十甚至百页的文档,测试不再仅是提出软件缺陷和编写、执行测试用例,而是成为了团队的数据库和字典。

2-dictionary

当用户提出一个功能的时候,测试人员可以快速的进行需求分析,回顾并确定是否与此前的功能有冲突。当开发人员对某一块业务不了解的时候,测试人员也可以组织会议进行阐明。由于对业务和客户的深入了解,测试人员可以为客户提出建设性意见和功能,有时也会是做出决策的人。

高效、频繁的沟通,大大提升了QA的软技能。此时的测试人员已经过程化,对软件质量的理解,从“发现缺陷”提升到“对软件开发过程的质量控制和风险预估”,我们定义这样的测试工程师为QA。

QA 3.0 —— 自动化技能提高生产力

随着工程实践的日益成熟,QA的角色和工作日益复杂,这使得他们在大量重复、繁杂的工作与更有意义的角色之间频繁切换,这对软件质量也产生了一定影响。

3-transform

QA从开始的手工测试、探索性测试等手段,逐渐发展成为可以利用工具和程序对测试进行快速的回归,对软件性能进行有效监控,无论是前端还是后端、web应用还是移动平台。这使得自己从繁杂的重复性工作中解脱出来,去做更有意义的事情。他们通过项目的积累以及团队成员的帮助,对测试技术有了一定的认识。

QA 4.0 —— 角色向多技能、服务化转型

记得几年前,前公司领导对我说,“不管开发换了什么技术栈,你做的自动化框架都可以继续使用,对你来说没有任何影响。”当时我也赞同,认为框架已经足够好,可以适用于任何场景和业务。

从某个角度来说确实是这样, 测试相对于开发技术的指数级发展,平稳的太多。不论是在互联网还是移动互联网时代,缓慢的发展速度给了我们一种太平盛世的错觉,似乎我们掌握的技术足够坐吃几年。

来到ThoughtWorks之后,我发现了类似的事情,不论是在交付还是咨询的过程中,会有意无意中推一些我们认为的最佳实践,当遭到客户质疑和challenge的时候,我们似乎很沮丧。

在北京出差的日子,有幸做了一次咨询,虽然只有几天,让我学到一件事,我们认为的最佳实践和方法,并不完全适应于所有场合,尤其是在我们这样的咨询公司,对客户实施怎样的方案,取决于客户的领域、产品/项目特性、用户群、技术水平、政治文化、技术栈以及目标和期望等等。

4-balance

如果对于“最佳实践”过于坚持,也会影响客户关系和咨询效果。之后咨询同事讲的几个故事也似乎让我认识到,虽然我们对现在的工作和技能足够的熟练,但依然不够。

我们似乎还需要具备以下的能力:

1.尝试用不同的方法写“茴”

经验丰富的QA对于测试技术中的关键点都烂熟于心, 除了我们正在使用的方案和技术,尝试用不同的语言、框架去实现关键点和难点。这样的好处在于,我们可以通过深入的学习和使用,对流行方法、过程和框架进行比较,了解各自的优势和劣势,不但可以增强自身的技能,当面对不同客户的时候,也可以给出客观的分析,为客户提供精准服务,同时如果可以对客户现有的技术和方案、流程和方法提供有价值的意见,也可以提高在客户现场的生存率,轻松俘获客户。

2.If you cannot test it, dev it.

软件过程中,QA可以在需求分析和定义阶段介入,为项目提供不可估量的价值,但另一方面,QA技能实践(此处指Tech)是一个相对受限的领域,我们很难绕过未实现的代码和工程去做更多的事情。

你可能会说,“没有做过mobile的项目,如何去学习移动端的测试技能?”如果恰好你对行业的发展具有前瞻性和敏感度,例如你可能认为IoT和VR是一个趋势,你却没有机会去这样的项目中做QA。

那么我们是不是可以像开发一样,提升自己的学习能力和适应力,保持对技术的敏感度和热忱,了解不同技术领域,对该领域的开发、测试、构建和集成部署都有一定的了解?所以,如果你想比其他人走的快那么一点,go dev!

5-golf

3.真正的全功能

QA的领域虽然相对受限,但幸运的是角色相对不受限。在日常的开发过程和项目积累过程中,不但能对业务有深刻的理解、对用户行为有独到的见解,而且对技术也有一定的认识。

在需求分析过程中,QA总是可以从技术和业务结合的角度扮演好一个BA的角色,成为一个优秀的PM,甚至我们可以在客户提出一些需求的时候尝试着从一个UX的角度去设计原型,如果具备前端的能力,也可以自己去Dev、UI,不断拓展自己的技能领域,使自己成为真正的全功能。

总结

真正的全功能,并不是单纯意义上让QA去做Dev,而是最大程度弱化角色的概念,逐步强调和培养技能多元化。如何把对需求的理解能力强化为业务分析能力,把质量控制能力强化为项目管理能力。强化自身的优势,跳出自己的舒适区,使自己能够轻松胜任。这样我们才不会在看到去QA和QA消亡之类的观点后,无所适从。

 


你想看到的洞见,都在这里

wechat

Share

QA Review UT的那些事儿

一个风和日丽的下午,眉清目秀的Dev小乒挺了一下腰,喊了BA、UX还有QA小乓一同SignOff,十几分钟后,场景验收完毕,BA和UX退位,只有QA小乓还定坐在那里,斩钉截铁地说了句:“看下UT吧”,故事也就从这里开始了…

“嗯?还要看UT?” Dev小乒一脸突然。

“嗯,看下吧!” QA小乓谈定的说。

“好吧……”Dev小乒边回话边打开Git翻找,嘴里好像还在嘀咕着什么。

“这部分测了保险单的消息提醒功能” Dev小乒随手打开一个测试文件。

“那理财单的消息提醒测了没?” QA小乓追问道。

“没测,不用测,实现都一样!” Dev小乒顺口答道。

“只测保险单,那理财单的挂了怎么办,它们是不同的业务,难道,还得手动一遍遍测试?” QA小乓皱了皱眉看了一眼Dev小乒。

“不用,相信我,我们是TDD,测试驱动开发,再加也驱动不出新代码,再说实现都一样,加了也是重复代码。”

说完这段话后,Dev小乒身子往后一靠、椅子向后一滑,身体转向QA小乓,语重心长地说:“小乓呀!我觉得吧,你不用看UT,对你没啥用,再说都跟实现相关的,也很难给你讲清楚……”

此处的QA小乓仿佛看到了无数只黑乌鸦从眼前飞过……

这就是我们项目在尝试“QA Review UT”实践后出现的一个真实场景,从中可以看到这个新的实践所面临的挑战,那问题来了?对呀,为什么QA要Review UT呢?

为什么要Review UT

1、先从UT的重要性说起

根据测试金字塔,UT处于测试金字塔的最底端。其特点是更贴近于代码,运行速度快,成本相对较低,对问题的反馈也更准确。所以通常情况下,绝大部分的业务代码都会在UT层被覆盖,也就意味着有近70%或更高比例的业务逻辑会由UT来保护。

1-test-pyramid

2、再从”QA对UT”不可见的弊端谈谈

作为把控质量的QA,对于这类在测试策略中占比最大的单元测试(UT)却通常是不可见的。因为UT通常都是由开发人员编写,与实现紧密相关,又纷繁复杂,所以QA通常都不知道在UT中到底测了哪些、没测哪些。这样一来,只能通过手动一遍遍测试或编写更加昂贵的UI回归测试予以保障,不仅耗费了很多精力,而且还可能会与UT测试有很大的重复。

但如果加入了UT Review,使UT对QA可见,可以让QA更好的了解产品的质量情况,制定更加有效的测试策略,就可以在增加整个团队对于产品质量信心的同时,使工作更加高效合理,测试策略更加精简有效。

由于QA对于业务的理解也比较深入,有时还能在Review中发现漏掉的测试场景,在更早期识别风险,避免更大问题的产生。

由此可见,Review UT很必要,可是往往好事多磨,就像一开始的故事,QA小乓就遇到了很多困难。

Review UT过程中的那些困难

2-Review-UT

1、开发人员内心排斥QA Review UT

回想一下一开始的场景,Dev小乒对QA小乓要Review UT表现得有些突然,包括Dev小乒最后语重心长的那句话。从Dev的角度,UT是与实现相关的,与技术架构、工具选型、甚至是底层设计相关,QA又不懂。另外,QA要Review他们写的UT,可能会让Dev觉得这是对他们的不信任。再者,SignOff加入Review UT后,时间变的更长,成本也会相应变高。所以,在刚开始推行Review UT的过程中,会出现双方合作不畅的情况。

【解决方案】:在Review UT这件事上团队内必须先达成共识,通过沟通使团队明白QA Review UT不是因为对Dev不信任,也不是为了挑刺儿;而是为了挖掘前文中为什么要Review UT章节中阐述的QA Review UT能给项目带来的好处。另外,作为QA也需要了解些代码方面的知识,比如:系统架构、Dev用的TDD等,以便于更好的理解UT,最终通过双方的努力,不断的降低Review UT带来的成本,实现利益的最大化。

2、测试结构乱,看不懂

刚开始Review UT就发现,UT结构零散,经常需要在不同代码库、文件、及Commit中跳来跳去,全程Review下来经常会感觉一片混乱,也搞不清哪些测了哪些没测。甚至还会使得双方怨念四起、互相嫌弃,QA嫌弃Dev写的乱、又讲不明白,Dev嫌弃QA看不懂、还嘚吧嘚!

【解决方案】:首先Review UT对QA提出了更高的要求,要对代码架构提前有个了解。而Dev在写UT时,也要尽可能写的结构清淅易读、命名准确。在每张卡SignOff时,开发人员可以先简短介绍清楚UT的结构(也可以简单画一画),再介绍哪部分Test Case放在了哪里,然后去对应的结构里看相应的测试 。这样整个过程才会更加的顺畅,也才能真正的起到预期的作用。

3、根据现有实现,不需要再加

开发人员有时会说:“根据现有实现不需要加,这个业务和另一个业务实现代码是一样的。再比如,这方法的实现是用数组,你提到的两种业务场景在这里就是数组里的1和2,处理上没区别”。

【解决方案】:测试验证的应该是业务价值,而不是具体的实现方式。而在业务价值不变的前提下,实现代码却可能会发生变化,比如:代码可能被重构。所以测试也不该根据代码实现来设计CASE,更应该从业务价值来设计。当然实际情况中会有一些特殊情况,但总体原则不变,即我们应该更多的通过测试来保障我们交付价值而不是具体实现。

收获

经过一段时间的实践QA Review UT,我们发现在不同程度上,都有了很大的收获。

1、及时发现了UT上的一些问题并改进

Review UT以后,SignOff时发现了不少漏掉的测试场景,让一些Defect提前被识别出来,避免了更大的损失和风险。

2、QA越来越熟悉Code&Test结构

要想Review好UT,QA要大致了解系统的技术架构,而且每次Review UT前,开发人员还会给介绍或画一下测试结构,时间久了,对于代码和测试的结构就会越来越熟悉,从而让整个Review过程变得越来越有效率。

3、QA和开发人员更近了

在Review UT的过程中,QA和开发人员之间更多的交流,介绍测试结构时,会提到实现架构与实现等,渐渐QA对DEV的术语也懂的多了,也更了解了开发人员的测试思维,沟通合作起来更顺了,Review UT过程中遇到双方争异也更易解决了。

4、开发人员测试sense提高

QA更多地从业务角度以及从测试专业角度思考问题、交流,在QA潜移默化地影响下,开发人员对于测试和质量的Sense也有了提升,UT的质量也有了明显的提升。

5、团队对质量更有信心

QA参与和开发人员一同严格把控了重要的UT环节,也清楚了哪些业务价值已经在UT中被覆盖,所以在设计更高层次的测试时就会更加有针对性,减少了重复测试带来的浪费,同时团队对产品质量也更有信心了。

6、QA做更多有价值的事儿

被UT覆盖的业务价值对于QA来讲不需要做完整的细枝末节的手动回归测试了,只需要做一些针对性的探索性测试,这样QA就有了更多的时间做更有价值的事情。比如:更早参与需求分析、Review Story,写Regression测试,实施內建安全&性能, 以及生产环境下QA的事儿等等!

Share

敏捷QA,从入门到放弃

做敏捷QA五年多,看到了很多人加入,也看到了很多人放弃。其中有经验丰富的测试人员,也有刚刚步入职场的新人。虽然“从入门到精通”是大多数人选择进入这个行业的初衷,但是敏捷QA一些特有的工作方式和要求,会让很多人不适应或者不喜欢,所以很多时候我们看到的是一个个“从入门到放弃”的过程。

那么什么样的人应该不要选择或者尽早放弃敏捷QA这条路呢?本文试图给大家提供一些参考。

敏捷QA入门

QA(Quality Assurance)通常指的是质量保障,也有一种说法是质量分析(Quality Analysis),在敏捷软件开发团队中,我们强调所有成员(业务分析师、开发人员、专职QA)为质量负责,所有人参与跟质量相关的活动,所以从宏观意义上来说,人人都是QA,很多文章都有相关的介绍,这儿不再继续探讨。本文提到的敏捷QA,指的是敏捷团队中专职的QA角色,他们的主要职责是主导并促使跟质量相关的活动在团队内发生,包括但不仅限于测试。

敏捷QA的入门阶段除了要有基本的测试知识外,必须要熟悉一些敏捷相关的基本概念以及实践,比如用户故事、迭代、迭代计划、回顾会议等等。敏捷QA几乎会参与整个用户故事的生命周期,从分析,启动,开发,验收,测试到最后的展示,尤其在启动,验收和测试这三个环节发挥着非常重要的作用。

另外,敏捷QA会同时工作在多个迭代当中,在进行当前迭代用户故事的测试验收等活动的同时,也经常需要做前一个迭代的收尾工作以及下一个迭代的准备计划等。

敏捷QA放弃

了解了基本的敏捷QA知识后,我们来看看放弃敏捷QA的四个理由。

  • 不爱说话?别做敏捷QA了

如果你之前是安安静静专心找软件缺陷的工作模式,那么进入敏捷团队你可能会经历很长时间的不适应。

因为敏捷QA不能被动地等待软件完成交到你手里再做测试,不能发现缺陷后不管不顾等着开发人员自发地去修复。你需要从软件的源头开始介入,在软件的整个生命周期中全程参与。

敏捷软件开发强调质量内建,在用户故事的生命周期中,作为质量保障的主要负责人,你需要在每个阶段跟不同的角色反复确认和验证,确保团队对需求理解一致,还要保证跟质量相关的活动发生,比如确保开发人员添加了相关的自动化测试等,所以你需要和团队的每一个成员以及客户有非常多的交流,而最直接有效的方式就是说话,沉默寡言是行不通的。

所以,如果你不喜欢说话,那么Tester也许比敏捷QA更适合你。

1-QA-talkative

  • 心态不好?趁早放弃

不知道你是否经历过这样的场景,在某些小餐厅等位严重的情况下,你需要站在某个快要结束用餐的客人边上等空位,而有些人却可以在用餐结束后无视旁边焦急等待的人群一直占着座位专注地聊天。

虽然这种行为不是很好但也无可厚非,换个角度想,这种人的心理是非常强大的,因为很少有人能够不顾及别人而我行我素。而这种“能力”对敏捷QA是非常有用的,比如在故事验收环节,这个阶段就是业务分析师、开发人员和QA三种角色一起在开发人员的机器上验证用户故事是否被正确地实现。当然任何角色都可以主导这个环节,但效果最好的是由QA来主导,因为可以提前发现缺陷并快速修复。

但是因为这个阶段所有角色都会参与,大家关注点又有所不同,所以心态不好难免就会有各种顾虑,比如,自己会不会太慢了?会不会耽误太多人的时间了?别人会不会很着急?

太多顾虑就会影响你做验收测试,尤其验收阶段的探索性测试。从而使你不能充分发挥QA的作用,而这个环节对于敏捷开发模式下的质量保障来说非常重要,这时候如果具备前面提到的强大的心理素质,就能专注地按照你的想法测试你的场景,当然可以配合一些解释让别的角色了解你的思路,而不是左顾右盼思前想后影响这个阶段的发挥。

所以,如果没有强大的心理素质,也许应该考虑趁早放弃做敏捷QA。

2-strong-heart

  • 对业务、代码没兴趣?敏捷QA不适合你

相信很多人进入测试这个行业,是因为对测试领域的技术和方法论有浓厚的兴趣,但是对于敏捷QA来说,仅仅对测试感兴趣是不够的。

敏捷QA需要对整个系统以及业务足够熟悉,这样才能从QA的视角帮助业务分析师和团队发现业务不合理或者缺失的部分(可以在故事审查或者启动阶段帮团队澄清需求)。

另外如果可以具备一些编码能力,对于做敏捷QA也是非常有帮助的。当然,术业有专攻,并不要求每个QA都会写代码,但是要对代码有一定的兴趣,愿意听开发人员讲解他们的逻辑和实现,并通过提问题了解他们的思路,至少了解他们编写的测试代码。因为在验收阶段,敏捷QA会通过审查开发人员的自动化测试是否合理和全面,来帮助团队建立对自动化的信心。

所以如果对业务、代码没有丝毫兴趣,那么也许敏捷QA不太适合你。

3-QA-content

  • 不会管理工作的优先级?做敏捷QA很难

敏捷QA最大的挑战是,每时每刻都同时工作在很多事情上,我们可以细数一下敏捷QA的活动:当前迭代的故事审查、故事启动、故事验收、故事测试用例准备、部署、缺陷管理、缺陷分析,前一个迭代的故事收尾,后一个迭代的测试计划、故事审查、故事启动等等。

另外敏捷QA希望可以做的更多,比如日志分析、性能监控、安全测试等等。

可以看到,敏捷QA的工作是非常杂乱琐碎的,而且大多活动是和团队中不同成员一起进行的,我听过很多刚刚加入敏捷QA的新人抱怨没有自己思考的时间,忙乱没有目标;也见过很多优秀的测试人员转做敏捷QA后因为不适应这种多线程的工作选择了放弃。确实,在这样一种工作模式下,如果QA不能清晰定义自己工作的优先级,就会被各种杂事牵着鼻子走。

不擅长管理自己的工作任务、不会划分优先级,做敏捷QA会非常难。

4-priority

总结

敏捷QA,不管性格还是心态,都需要足够强大,否则在整个工作过程会非常艰辛;另外仅仅掌握专业的测试技能是不够的,还需要更多地了解业务甚至代码;最后必须能够管理自己工作的优先级,否则会事倍功半。

5-summary

了解了这些方面后,可以认真思考一下,自己是不是真的适合做敏捷QA。如果依然坚持步入这个领域,那么希望我们可以一起从入门到精通。

Share

敏捷QA实践-Bug Bash

什么是Bug Bash?

Bug Bash <http://en.wikipedia.org/wiki/Bug_bash>,也称为Bug大扫除,是软件测试的一个很重要的实践,是对日常测试的有效补充,它在很多互联网公司(比如微软,淘宝等)都是一项重要的测试实践。简单的说,Bug Bash就是对产品找茬;具体来说,就是在产品稳定的阶段,选取一个特定时间段邀请一组不同角色和背景的人员在会议室里对被测产品找Bug。一旦发现问题后可以请熟知产品的观察员确定是否是Bug,对发现最多或者最严重Bug的人员给予一些奖励。项目组成员在搜集好所有Bug和潜在Bug的清单之后,全员进行Bug分析,制定出解决的方案并实施。

为什么在测试中我们会引入Bug Bash呢?

由于参与Bug Bash的人员有着不同的角色和背景,甚至来自不同的项目和领域,所以每个人都会通过自己的观察,结合自己的经验,给我们的测试工作带来更多的视角,帮助我们发现那些被我们忽视了的问题。因此通过Bug Bash,我们可以:

  1. 发现尽可能多的问题。对于确定是Bug的问题,项目组成员可以通过分析Bug产生的原因,避免类似的Bug再次出现。而有些发现的问题不一定就是Bug,可能是一些潜在的需求,我们同样可以分析这些来优化我们的产品。
  2. 了解不在预期之内的用户行为。通过了解这些用户行为,我们能分析出哪些用户旅程User Journey是需要添加进我们的测试场景中,甚至需要加入自动化测试的。
  3. 对于并发的测试,尤其是多用户同时执行不同的场景。大部分时间我们在测试产品时都是单人在操作,即使我们有性能测试来覆盖这些场景,但是通过Bug Bash,我们可以更好地接近用户真实使用产品的并发场景。
  4. 进行更多的用户测试User Testing。一般来说我们在开发中会不断地进行用户测试,来验证产品是符合用户习惯,以及开发方向是正确的。鉴于产品可能需要保密,并且使用Bug Bash可以用更小的代价,进行更多的用户测试,所以我们会不时进行Bug Bash。

Bug Bash除了给我们带来上述4点主要益处,还可以为我们带来一些附加的价值:

  1. 帮助QA更深入了解系统。在测试过程中QA进行测试,会不断加深对于产品的理解;不过由于在Bug Bash中QA需要向其他人员描述产品,并规划不同的测试场景和目标,所以会对自己已有的产品知识进行更深入的梳理,而且通过Bug Bash最后的分析阶段,加深对于产品远景、目标和原则更进一步的理解。不同的QA之间也可以相互进行学习和交流。
  2. 宣传项目。通过Bug Bash,我们可以邀请不同部门,不同角色,不同背景的人员参与,所以无形中就向更多受众宣传了自己,对于项目获得更多资源,以及通过受众进一步影响更多的人。
  3. 引发更多关于产品的思考。根据Bug Bash搜集的问题列表,项目组成员会对这些问题进行集中讨论,并详细解释如何处理以及为什么这么处理,让项目组所有成员对于产品都各抒己见,而且通过这些讨论,引发更多的思考。

既然有如此多的益处,那我们如何组织Bug Bash,还有哪些细节需要注意的呢?

1.    活动准备

首先确保被测产品功能基本稳定。如果被测产品还处于不断出现Bug的开发早期或者中期,就不适合进行Bug Bash。因为如果进行Bug Bash,发现的大部分问题都是已知问题,并不能带来很大的价值。所以我们最好确保被测产品功能基本稳定,并且进行过性能测试和并发性的测试(至少可以支持并发操作)。

其次准备对应的测试设备。例如对于Web和桌面产品进行Bug Bash,我们需要准备足够的显示器和键盘,甚至椅子,来保证Bug Bash可以顺利进行;自然,对于测试移动App,我们也需要准备不同型号和操作系统的移动设备。

除此之外,我们需要准备产品的特性列表并且准备Bug Bash中参与人员需要完成的任务列表。这份任务列表一般会基于不同浏览器,不同平台,不同语言,不同功能模块,设计出针对每组参与人员需要完成的不同任务列表(具体实例见图1)。对于参与人员的分组,具体根据参与人数和特性列表来确定,可以一个人一个组,两个人结对,或者两个测试人员和组内一个QA结对(这么做是因为这样可以及时确定发现的Bug是否有效)。当然如果组内QA有限,可以让QA充当全场的观察员动态协调。

BugBash

图1 - 根据产品的特性列表制定的Bug Bash任务列表

同时,我们还需要准备好测试环境和测试账号(如果涉及角色权限等功能的任务),把这些测试环境信息通过邮件告知参与人员,或者张贴在Bug Bash活动场地附近,以便Bug Bash中所有人可以随时获取这些信息。

还需要设计一个Bug报告模版并告知参与人员。这么做的目的在于方便参与人员及时记录发现的Bug,也便于我们在Bug Bash后重现和分析bug。因此Bug报告模版格式尽量简单清晰,最好能有截图来帮助说明Bug。Bug报告可以是电子的也可以是纸质的,需要注意的是,尽量保证Bug Bash参与人员可以方便地访问模版,从而进行Bug记录。

重中之重的是确定参与Bug Bash的人员。这些成员既可以包括组内各种角色,比如开发人员,业务分析人员设计人员,项目经理,还可以包括产品经理,客户;当然,邀请一些对产品不太了解的人员也是很重要的,因为他们更能从一个新鲜的视角来测试产品,比如公司销售,前台或者其他组的开发和测试人员。在Bug Bash举办前,我们需要确保有足够数量的人员参加,尽可能地提高举办Bug Bash的投入产出比。

们还需要确定进行Bug Bash的时间和时长。在项目中后期,我们通常会以两周或者一个月的频率进行Bug Bash,比如利用午休时间进行1~1.5小时的Bug Bash。当然不同的项目Bug Bash时长和举行时间各自不同,但是原则上,选择尽量适合所有参与人员的时间段和时长。

除此之外,确定举行Bug Bash的活动场地。可以选择会议室,来帮助参与人员专注于发现产品Bug,而且由于远离常规工作的场所,有助于为参与人员提供一种新鲜的视角。当然,如果基于宣传的考虑,我们也可以选择公共区域作为活动场地

在确定了Bug Bash的参与人员时间和地点之后,尽早向所有参与人员发出邀请,确保参与人员都有时间参与。

最后,在Bug   Bash开始之前我们准备一些小(比如酸奶,巧克力和小礼品),等Bug Bash后发放给每位参与者,以感谢他们对于活动的支持。

2.    活动中

在Bug Bash正式开始前,我们首先欢迎并感谢所有参与人员,说明本次测试目的、时间、流程、规范和奖励规则等,使所有人都明确Bug Bash会如何进行,以及他们在活动中需要如何测试和记录Bug。随后我们向每个测试组分发需要测试的任务列表、测试环境和账号,以及纸质或者电子Bug报告模版

当正式开始Bug Bash后,每个测试组中的两位参与人员需要共用一个显示器和键盘(或者移动设备)进行结对测试。于确定的Bug测试组需要记录其重现步骤,并且记录在Bug报告上如果条件允许,需要测试组在测试报告中添加对应的截图。对于不确定的问题,作为观察员的QA可以适参与确,减少测试组在一个Bug上花费时间。

与此同QA作为观察员,除了在测试组中进行协助并帮助确认发现的Bug是否有效之外,还需要观察每个测试组的行为,必要时还需要了解他们这么做的原因。如果条件允许,我们还可以通过录制视频来记录每个测试组的操作过程,以便后续的Bug分析和用户测试分析。如果测试组在完成某项特定的任务时有不能解决的争议时,如果QA作为观察员也没有办法说服双方,那可以停并切换到别的任务。此时我们也需要记录任务切换的原因和相应的细节信息。

最后,作为观察员的QA可以记录测试组完成特定任务所用的时间,以便在Bug Bash后对用户测试进行分析时,了解对应功能的可用性和易用性。

3.    活动总结

准时结束Bug Bash,并对参与者赠送一些小礼物(比如酸奶,巧克力等)感谢大家参与测试。我们还需要对发现最多Bug或者发现最严重Bug的参与人员给予特殊的物质奖励,例如具有团队Logo的徽章或者T恤等。

当然作为组织者,我们还要负责搜集并整理所有发现的Bug。具体来,首先合并重复的Bug,并且验证它们的重现步骤,尽可能附上对应的截图。最后,组织项目组所有成员就是否需要修复Bug,Bug优先级成一致意这样便尽早解决高优先级的Bug

对于那些需要解决的Bug,我们还要考虑是否需要把它们添加到手动测试用例集和自动化测试中。考虑是否需要把新添加的自动化测试用例/场景和已有的自动化测试用例/场景进行合并,以保证所有的测试都是分层的,而且是符合测试金字塔的。

所有确定的Bug要分析产生的原因,制定相应的计划避免再次产生类似的Bug。

在制定了对于Bug的解决方案和计划之后,我们可以通过邮件或者其他方式,如故事卡墙或者缺陷墙,告之所有参与人员。这样不仅可以让参与人员更有参与感,更重要的是使更多人监督我们执行这些计划。

最后,我们还可以整理Bug Bash中收集到的数据测试时长制的操作视频等),检查是否功能设计不合理,导致用户需要很长时间才能完成操作,从而做出产品改进。

千里之行,始于足下

也许你觉得在项目中实践Bug Bash很耗时间和精力,而且不一定会得到领导的支持。其实我们可以在更小的范围内,例如只是项目组的测试人员中开展Bug Bash,成果展示一点一点地得到各方面的支持。

虽然以上是我在敏捷软件测试中总结Bug Bash,但是Bug Bash的形式并不局限于特定的开发方式,所以我们可以在自己的项目中采用这个实践,来帮助我们产品日臻完善。

Share