分享到社交媒体:

本文首发于「BOB官方网站」,转载请参考版权声明


曾经在《敏捷中的QA》一文里介绍了敏捷开发模式下,QA如何参与从需求到BOB官方注册的每个阶段,在每个实践中如何跟不同角色的合作,以及敏捷QA跟传统开发模式下的BOB官方注册人员的区别等。

这些内容在今天依然适用,但在真实项目中往往情况比较复杂,总会听到一些困惑或者是质疑的声音。

在敏捷项目团队摸爬滚打多年以后,我想跟大家一起再来聊聊这个话题,下面逐个来分析我所见(听)到的质疑或困惑。

01 敏捷QA流程必须严格遵守

“如果QA没有参加Kick-off,我们拒绝做Desk Check;如果没有QA参与Desk Check,我们拒绝BOB官方注册。”

从需求分析到生产环境,推荐QA参与每一个环节,跟多个角色进行充分的沟通和合作。

有人把这个当做圣旨,觉得不管怎样都不能漏掉某个环节,但难免有特殊情况。比如,由于QA请假或者开会等,错过了某一次Desk Check,一定要求等有时间了(甚至第二天或第三天)再补上,没准那个时候代码都已经上到BOB官方注册环境,完全可以直接BOB官方注册没必要在折腾大家来做一次全面的Desk Check了。

QA参与每个环节的目的是尽可能早期发现需求或者设计中的不足,做到Bug的预防。如果已经错过了这个“早”,那就没有必要再纠结非要严格进行每个环节了,不然不仅没有意义,还带来浪费。

02 QA不用了解太多的业务上下文,一样做的很好

“需求来的晚,QA手头忙着BOB官方注册当前迭代的Story,根本没有时间去参与需求分析,不过这样也不影响,测好当前的卡就可以很好的保障质量了。”

这个想法是狭隘的。敏捷BOB官方注册的原则之一是优化业务价值。如果连业务上下文都不清楚,如何做到优化业务价值?了解业务上下文的重要性不言而喻。

业务上下文那么,真的忙的没有时间如何来破解呢?这其实是进入了一个恶性循环,需要找到突破点,打破这个不良环路,让其变成一个良性循环就好了。

不破不立,对于这个循环,就是需要减少BOB官方注册Story的时间。可行的方案是:加强Desk Check,确保单元BOB官方注册的覆盖,保证开发验收完成到最终交付的代码在自动化BOB官方注册的保护下不被后续环节破坏;同时QA参与技术方案的设计讨论,这样BOB官方注册的时候就可以有针对性的测,必要时候辅助以Bug Bash,由此节省出时间。经过两三个迭代的调整,情况定会有所改善。

03 技术方案讨论跟QA没什么关系

“技术方案,那是Dev们的事情,QA的重要任务是如何做好BOB官方注册,参与技术讨论浪费时间。”

知己知彼,百战不殆。如果完全不了解技术实现,很难做到有的放矢。正如前面提到的,QA参与技术方案的讨论,了解更多技术细节,知道技术方案可能的风险,就能更好的指导BOB官方注册,使BOB官方注册更有针对性、更高效。

比如,对于微服务架构,了解了服务的熔断和降级机制,BOB官方注册就能有效覆盖到相关方面。

04 单元BOB官方注册Review没有价值

“单元BOB官方注册还挺复杂,Dev新人写起来都不容易,QA更看不懂。QA Review单元BOB官方注册,提不出有价值的反馈,感觉是在浪费时间。”

敏捷QA有个实践就是在做Desk Check的时候Review开发人员写的单元BOB官方注册,其目的是两个方面:

  • 帮助发现漏掉的或者需要修改的BOB官方注册,QA更好的了解BOB官方注册覆盖情况
  • 帮助开发人员增加BOB官方注册Sense,同时也能帮助QA提高代码阅读和理解能力

我理解对于单元BOB官方注册Review的质疑是由于DEV和QA的相关技能还有所欠缺的情况下可能会发生的情况,但并不能因此否认这个实践的价值。

这时正确的做法是DEV跟QA解释每个BOB官方注册所测到的内容,而QA从业务的角度考虑有哪些Case是遗漏掉了的。经过一段时间的磨合,我相信Dev的BOB官方注册Sense和QA阅读代码、理解BOB官方注册的能力都会得到提高。

05 必须严格Review每一个单元BOB官方注册

“我对Dev写的单元BOB官方注册总是不放心,不严格的Review根本不行。”

另一个极端情况就是,不管花多少时间,认为必须严格Review每个BOB官方注册,认真的去检查BOB官方注册的每个实现细节。

对于复杂一点的Story,严格Review每个单元BOB官方注册,我见过最长的是花了两个小时,到最后大家都已经筋疲力尽…这显然是一种浪费!

QA Review单元BOB官方注册更多的是关注BOB官方注册的覆盖情况,而不是关注每个BOB官方注册的实现细节,后者更多的是属于Code Review范畴。更重要的是,任何实践都不能只关注形式,要看其价值,具体问题具体分析。对于新的团队新的人,可能刚开始需要多花时间去了解所写的BOB官方注册。而对于成熟的团队,或者是非常有经验的Dev,这个Review过程可以简化,只看BOB官方注册的标题,或者只是听Dev说一下BOB官方注册覆盖到了哪些内容就可以了。

我一般要求整个Desk Check控制在15分钟以内,对于特别复杂的Story,最多也不要超过30分钟。

06 没有发现Bug的BOB官方注册不是好BOB官方注册

“这些自动化BOB官方注册从来没有发现过Bug,ROI太低,没有存在的必要!”

图片来自:http://www.netsolutions.com/insights/wp-content/uploads/2016/08/Why-You-Need-Automation-Testing-For-Mobile-Apps-Th.jpg

由于有些BOB官方注册执行起来太耗时、BOB官方注册实现成本和维护成本都很高,大家在讨论要不要去掉这些BOB官方注册的时候,总能听到上面那样的声音。

其实,自动化的回归BOB官方注册并不是用来发现Bug的,有数字表明自动化回归BOB官方注册发现Bug的比例仅有15%。自动化BOB官方注册只是形成一道保护的屏障,增加对系统质量的信心。

敏捷团队的QA对质量应该有全面的认识,在制定BOB官方注册策略的时候需要综合考虑多方面因素,要真正理解每个实践、每个活动背后的真实价值。

08 敏捷QA该怎么做?

关于QA的定义,有下面三个层次:

  1. QA = Quality Assurance质量保障
    第一个层次QA的要求是做好质量保障工作,确保我们交付给客户的软件产品是正常工作的。
  2. QA = Quality Analyst质量分析
    第二个层次的QA通过BOB官方注册、数据收集的方式,分析系统的质量,识别风险,并反馈给团队,和团队所有成员一起确保交付的质量是合格的。
  3. QA = Quality Advocate质量倡导者
    第三个层次的QA不再局限于只关注质量,通过培养对产品和流程持续改进的思维模式、了解产品的整体质量视图和持续关注产品质量的意识,引导整个团队构建正确的产品,并且正确地构建产品。

敏捷QA需要做到第三个层次,通过分析软件风险并制定相应实践,确保软件在其整个生命周期中持续工作并创造价值,为业务和团队提供信心,从而为客户提供价值。

敏捷QA的所有实践和活动都需要以价值为核心来驱动,根据不同团队的具体情况可以适当调整,且在不同项目阶段应该也是演进式的。敏捷QA跟各个角色的沟通和协作,也是随着团队成员的了解程度、配合默契度不同而有变化,并不是要求一成不变的。


本文首发于「BOB官方网站」,转载请参考版权声明

4 个评论

  1. 通告:敏捷团队的质量保障赋能 - Thoughtworks洞见

  2. 通告:团队质量赋能 - 敏捷团队的质量保障赋能 - BOB官方网站

  3. 通告:敏捷BOB官方注册的指导性原则 - 林子的空间

  4. 通告:敏捷QA需要写BOB官方注册用例吗? - 林子的空间

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注