Offshore敏捷交付团队QA生存指南

跨地域性的offshore敏捷交付一直以来都是一个充满挑战的工作,对于需要与各种角色进行交互的QA而言更是如此。我在2016年初进ThoughtWorks时就经历了这样一个项目。此间个人也经历了从忐忑不安到得心应手。现在此离岸项目已经交付完成,我也想总结一下这一年来的项目生存实践。

项目背景

客户:澳洲大型电信公司Digital部门,我所在的电商产品部门下有3个交付团队和1个Devops[1]团队,每个交付团队有3-4个开发,1-2个QA,1个IM[2],BA[3]则是按项目分配且全部都在Onshore。

系统与架构:基于AWS部署的Oracle的内容管理和电子商务系统,系统较重,且需要通过中间件从核心系统拿到数据。

QA职责

  1. 参加需求评审和技术评审会议,与BA讨论AC[4],与开发讨论实现方案。根据需求和技术方案制定测试策略。
  2. 准备测试数据,测试数据大多来自于第三方系统,可以自己手动创建,有时需要其他团队帮助。
  3. 对已开发完功能进行测试,即测试故事卡。
  4. 负责新功能上线。QA需组织系统发布启动会议,完成集成测试和回归测试,在上线后对系统进行主要功能的回归测试。

项目困难

Offshore的项目中存在的主要困难来源于三个方面:时间不同,空间不同,文化不同。

  1. 澳洲时间比国内早三个小时,算上各自午饭时间,与onshore团队的工作重合时间可能不到5小时,一旦过了澳洲的下班时间,有问题需要找onshore的团队就会很困难。
  2. 澳洲距离远,国内团队和澳洲团队只能通过视频会议、邮件、即时聊天软件等方式进行远程沟通交流。
  3. 基于国内的网络环境,在与澳洲团队工作的时候,网速、VPN都会对沟通和工作效率产生影响。
  4. 澳洲距离国内坐飞机大概要13个小时,较长的路途决定了不会有很多机会和预算让两地团队频繁的出差、相互交流。
  5. 同时由于不在一个地方工作,几乎没有比如团建活动,茶歇等能够促进团队成员互相了解、建立良好团队关系的机会,这对于敏捷团队的建立是非常不利的。
  6. 澳洲是移民国家,虽然相对于欧洲国家人们的思想更开放,更能接受不同的文化,但中西方文化的截然不同还是会在某些场合带来一些意想不到的问题。而且如果彼此双方对对方的文化完全不了解,交流起来也会缺乏共同话题,难以建立同属感。

生存指南

为了减少时差带来的工作时间重合度不高的问题,国内团队相应会提前上班时间,并且在非工作时间内也会注意澳洲团队是不是有紧急的问题需要解决,时刻保证澳洲团队能通过电话顺利联系上国内团队。

做好每天的工作计划,在有限的共同工作时间里,把需要澳洲团队帮忙解决的问题设置较高的优先级,然后预计会有阻碍或者依赖的工作点要优先提出来。而作为QA,我们应该合理利用共同的工作时间,把需要与onshore团队沟通的任务比如需求澄清, 故事启动,客户展示等工作优先完成,把可以独立完成的测卡工作优先级相对降低,这样就不会因为某些流程必须要两岸团队共同完成而阻碍。

网络环境的不同有时候会给测试工作会带来很多不便。为了最低程度降低网络环境带来的影响,首先我们要依赖于Techops团队搭建稳定可靠的VPN,再者作为QA在测试过程中如果遇到一些奇怪的问题,在分析问题原因的过程中应该考虑到网络的因素,必要的时候可以请onshore团队帮忙测试排除网络因素。

在解决两地团队相隔较远的问题上,我们制定了定期派遣项目人员去客户现场进行知识传递的计划。对于时长6周的现场出差,出差人员一定要提前做好计划,定时追踪知识传递的进度,在客户现场要尽可能的多了解项目的有关知识并和onshore团队建立良好的关系。作为QA,首先,一定要找到客户的质量经理一起安排好自己六周的知识传递计划并定时追踪进度。然后在客户现场需要找到一个onshore 的QA和他一起结对工作,在这个过程中你会很快的了解到一切关于QA的流程和工具,包括测试环境、测试数据、CI工具、Bug管理工具等等。同时,QA也需要找到一个对系统十分了解的开发工程师给你仔细讲解系统的架构和技术实现。最后,在知识传递过程中一定要学会记笔记,快速准确的把有用的信息及时分享给自己off shore团队,以个人带动团队共同成长。出差在客户现场,还有一点很重要的就是要利用面对面的机会与onshore团队建立良好的同事关系。茶歇和下班后的聚会都是很好了解对方的文化背景,兴趣爱好,建立团队认同感的机会。

虽然敏捷团队提倡“工作的软件高于详尽的文档”, 但是对于分隔两地的团队来说,有时候详尽的文档恰恰是提高沟通效率的必要手段。比如一个团队共享的wiki就能够帮助团队在不知道从谁获取知识时高效的查找到所需信息。作为QA,在离岸交付团队中,我们更需要注重测试的文档化。比如我们不仅应该详尽的对每张故事卡的测试案例和测试步骤文档化,而且还要记录测试环境的配置和测试工具使用说明,甚至有时为了使团队知道Bug如何重现,我们需要把重现步骤用截图的方式记录在Bug里。总之,在离岸交付中我们提倡并强调把自己所掌握的知识第一时间文档化分享给大家。

最后,为了提高团队的融洽度,获得彼此的信任。团队成员不仅要在技术等硬技能上体现出专业性,还要提高自己的软技能,学会怎样与有着不同语言,信仰,文化的同事进行无障碍沟通。这就需要首先努力提高自己的英语水平,适应不同的口音,再者要了解对方国家文化习俗,如果能在节日时送上祝福,或者闲时聊聊对方的文化,都能使对方感到亲切,获得认同感。同时,我们也要适时输出自己的文化,创造一个多文化的融洽的工作环境。

短短一年多的离岸交付因为限制很多,无法像在其他项目上一样积累足够多的经验,但在这个过程中,我在不断的突破限制、找到最佳实践的过程中也获得了个人能力的提升。现在我把这些经验总结出来,希望能帮助到现在或以后有相同工作场景的小伙伴们。

注:

  1. Devops: Development&Operations, 负责环境搭建,流水线配置,部署等工作。
  2. IM:Iteration Manager, 敏捷团队中负责管理迭代工作
  3. BA:Business Analyst, 业务分析师
  4. AC: Acceptance Critiaria, 故事或需求的验收标准。

更多精彩洞见,请关注微信公众号:思特沃克

Share

敏捷团队需要专职QA么?

敏捷QA对职业发展的担忧

最近和组内的QA聊起以后的职业发展,发现一个有意思的事情,有说想转BA的,有说想转开发的,有说想转型作PM的,还有想以后往咨询方向发展的。很少有说想在团队里面继续作QA的。QA这个角色难道就这么没有吸引力么?为什么都想转型或者自己出去单干呢?和组里几个QA聊了之后,发现主要因素在于对QA职业发展的担忧,觉得敏捷团队对专职QA的需求并不大。

记得我刚工作的时候还是有独立测试团队的,那个时候分工很明确,我就负责windows mobile(现在叫windows phone)上应用的自动化测试,我的这个职位叫做SDET,说通俗点就是自动化测试工程师。我们这个团队大概有10人,测试完毕后将结果汇报给测试经理。由于产品复杂,需要大量的测试工程师以保证产品能顺利发布。随着更多功能的加入,测试团队的人数也在增加,这段时间是QA最有价值感的时候,产品的发布最终都由你来把关,你可以根据兴趣来选择以后做一个性能测试或者安全测试工程师等等,有明确的发展路线。

但现在越来越多的公司选择了敏捷转型,适应变化和快速交付可工作的软件成为了团队的关注点。从开发和用户的角度看,他们会很乐意接受这个变化,客户可以不断看到新功能,开发可以把精力从繁琐的文档和流程上释放出来,发挥想象和创意来提供更好的解决方案。可对于QA来说,敏捷带来了什么好处呢?之前定期有一个可测的稳定版本,详细的需求文档就是我们参考的对象。现在要对一个不断变化着的对象来进行验证,也没有一大段时间来设计自动化框架。我们怎么来保证质量呢?

敏捷QA的测试职责

在敏捷的团队中,质量是由团队所有人来保证的,我刚开始听到这句话就像听到敏捷宣言一样,知道这有道理,但具体怎么做呢?如果质量是团队的责任,那么专职的QA干什么呢?

首先我们来看在敏捷团队经常用来保证测试用例达到平衡状态的测试金字塔,简单来说我们可以把更多的测试放在单元和服务级别,因为这些用例更易维护和执行,运行效率也更高,可以参照Martin FowlerTestPyramid

在这个框架下,很容易让人产生这样的误解。

1. 开发负责单元测试,不需要QA参与

跟组里的开发讨论过“是否需要QA参与到审查单元测试覆盖率”的问题,开发通常会觉得用处不大,因为有专门的工具比如:Cobertura, Jacoco, Istanbul等。这些工具的检查范围通常包括

  • 行覆盖率(line coverage):是否每一行都执行了?
  • 函数覆盖率(function coverage):是否每个函数都调用了?
  • 分支覆盖率(branch coverage):是否每个if代码块都执行了?
  • 语句覆盖率(statement coverage):是否每个语句都执行了?

而QA的检查可以弥补单纯的代码级别的覆盖。比如异常处理和边界值的情况,代码级别的覆盖会检查语句是否执行了,但是不能检查这段逻辑是不是写了。下面列举出几种常用的检查方法:

  • 等价类:把程序的输入域(所有可能的输入数据)划分成若干部分,然后从每个部分中选取少数有代表性的数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类中其他值。
  • 边界值:边界值分析法是对等价类划分的补充,它是对输入或输出的边界值进行测试的一种测试方法。我们这里所指的“边界值”是相对于“输入等价类”和“输出等价类”而言的,稍高于其边界或低于其边界的一些特殊情况。
  • 决策表:在一些数据处理问题当中,某些操作的实施依赖于多个逻辑条件的组合,即:针对不同逻辑条件的组合值,分别执行不同的操作,判定表很适合于处理这类问题。
  • 因果图:是一种利用图解法分析输入的各种组合情况,从而设计测试用例的方法,它适合于检查程序输入条件的各种组合情况。

有的QA会发现这些通常是用在黑盒测试里的方法,其实把这些覆盖尽可能的在单元或者服务级别来实现是一种既有效率,结果反馈又快,又可以直接作为回归测试的一种很好的途径。

在项目的实践中我们可以看到QA参与到单元测试的审查有以下好处:

  1. QA可以审查单元测试的覆盖率,来调整单元测试以及后续接口测试和回归测试的覆盖率。之前做的项目都是开发独自写单元测试和接口测试,QA也独自写自动化回归测试,后来发现有很多的重复覆盖,这也是种浪费。如果能结对来做单元测试,是种更高效的方式。
  2. QA可以更清楚代码对各个模块的影响,这样可以有针对性的设计回归测试,比如之前项目有个小的改动,QA没能在很短的时间进行回归测试,导致产品发布后遇到了问题。有人会说自动化覆盖所有回归测试不就行了么?理论上是这样的,但现实中有很多限制,只能通过手动验证来完成回归测试。这种情况下,精确定位回归测试的范围变得尤为重要了。
  3. QA对系统构架、开发语言能有一个学习的过程,这有利于自动化回归测试的搭建。

2. 开发更适合设计自动化测试框架和接口测试,因为他们写代码更有效率

如果说自动化测试和接口测试的目的是比谁写代码的效率更高,那么的确这些事情应该由开发去做,但是作为QA,参与其中的作用在于分析需求以及从客户的角度来设计用例。

敏捷团队越来越多的应用行为驱动开发(BDD)来覆盖基于服务和UI的测试。

1、QA会和PO,BA,DEV,UX一起合作,分析软件的需求,然后将这些需求写成用户故事。开发者负责填充这些故事的内容,测试者负责检验这些故事的结果。通常,会使用一个故事的模板来对故事进行描述。

故事的模板:

  • As a 角色
  • I want 特征
  • so that 利益

比如:

As a mobile App user

I want to recharge the Mobile phone number with credit card

so that I can have fee to give a call

2、每一个story有可能会有不同的场景,可以用下面的模板来描述在什么环境下发生了什么事情,结果如何。

  • Given [上下文]
  • And [更多的上下文]
  • When [事件]
  • Then [结果]
  • And

比如:

Scenario: Recharge with Credit card successfully

Given I logged into the Mobile App

When I go to Recharge page

Then I can see the recharge option listed

And I can see the Mobile phone number input box listed

When I input the phone number

And I select the recharge option as “Credit card”

And I input the Credit card number

And I click the Recharge Button

Then I can see the “Recharge successfully” message shows

3、QA会和DEV一起合作来实现这些story的自动化测试,常用的工具:

  • Cucumber (Ruby framework)
  • SpecFlow (.NET framework)
  • Behave (Python framework)
  • JBehave (Java framework)
  • JBehave Web (Java framework with Selenium integration)
  • Lettuce (Python framework)
  • Concordion (Java framework)

3. 开发交互进行基于UI的测试就行了,不需要专门的QA进行测试

如果说基于UI的测试就是执行测试用例,那么的确不需要专职QA来做,但是在敏捷的团队中基于UI的测试大部分是以探索性测试来完成的。怎么设计好的探索性测试用例才是专职QA的价值所在。

有人说探索性测试就是手动测试,有的说是随机测试,有的说就是把自己当用户来使用软件的测试。

什么是探索性测试?下面是wikipedia上面的定义:

Exploratory testing is an approach to software testing that is concisely described as simultaneous learning, test design and test execution. Cem Kaner, who coined the term in 1984,[1] defines exploratory testing as “a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the quality of his/her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project.

看完这个解释更迷惑了,探索性测试到底是什么东西?

举个简单的例子,我们聚餐的时候有时候会玩猜数字的游戏,主持会写下一个数字,大家轮流猜,主持会提示大了或者小了。那么下一个人会根据这个提示来继续猜,直到有人猜中这个数字。这其实就是探索测试的原理,每次都会根据之前的结果来设计下次的数字,那个被猜数字就是defect,每一次猜测都是测试用例。如果你想用最少的次数来猜中这个数字,就需要有高效的方法,探索测试也是如此。

敏捷QA存在的价值

以上简单的描述了在敏捷团队中,QA在测试中的职责:

  • 审查单元测试的覆盖率
  • 和开发结对搭建基于服务和UI的测试
  • 探索性测试

其实QA还有很多面向客户的职责,比如需求澄清以及产品演示,会在后续的文章去讨论。

随着敏捷的项目越来越多,对QA的需求不是越来越少,而是越来越高,QA需要像一个好的家庭主妇一样,能里能外,在团队内部能更好的平衡测试设计,在外部能更好的体现产品价值。在一个快速变化的时代,在持续快速交付的情况下保证质量是一件很困难的事情,解决这个问题就是QA存在的价值。


更多精彩洞见,请关注微信公众号:思特沃克

Share

为什么QA不喜欢重构?

经常听到开发人员抱怨 ,“这么烂的代码,我来重构一下!”,“这代码怎么能这么写呢?谁来重构一下?”,“这儿有个坏味道,重构吧!”

作为一名QA,每次听到“重构”两个字,既想给追求卓越代码的开发人员点个赞,同时又会感觉非常紧张,为什么又要重构?马上就要上线了,怎么还要改?是不是应该阻止开发人员做重构?

重构几乎是开发人员最喜欢的一项实践了,可QA们却充满了顾虑,那么为什么QA不喜欢重构呢?

老功能被破坏

不止一次遇到这样的场景,某一天一个老功能突然被破坏了,QA们感到奇怪,产品这块儿的功能已经很稳定了,也没有在这部分开发什么新功能,为什么突然出问题了呢?

追查下去发现是近期做了重构。再追问下去,对于老代码,已经几乎看不懂老的测试了,可是开发人员看到代码的坏味道就想重构,于是功能破坏了。

在快速迭代的开发模式下,QA们主要关注用户故事的生命周期,重点测试新的特性功能,所以对于老功能回归测试的投入是非常有限的,如果开发人员突然对老功能进行了重构又没有告知团队,这样的问题很可能就会进入生产环境,这样是非常有风险的。即便很多开发人员重构老功能时会告知QA,以提前发现和修复导致的问题,但无疑会大大增加QA做回归测试的负担。

新功能推迟/重复测试

按照用户故事的开发流程,开发人员完成功能后,多方角色会首先在开发人员的机器上进行用户故事的快速验收以及探索性测试,然后开发人员会提交代码,由QA拿到包之后部署到测试环境进行测试。

但有的时候QA在开发机器上快速验收之后,开发人员又进行重构,曾经经历过“故事验收的时候功能都是正常的,拿到包部署之后好多功能不工作了”的事情,跟开发人员确认,又是重构导致的。

有时候开发人员会在用户故事验收之后告知QA还会继续重构,QA可以等到重构完成后再拿新的版本做测试,这样就会导致用户故事的测试时间推迟。或者开发人员会先重构再做验收,而这样又会导致QA在开发机器上进行重复的验收测试。

无计划不可见

开发人员的重构时机对我们来说是无规律的。有的时候一边开发用户故事一边重构,有的时候会在故事完成后、QA在开发机器上验证结束后才做重构,有的是代码评审后大家指出问题后做重构,有的甚至得等到项目组来了有经验的开发人员才开始重构。对QA来说,重构的时机是无计划的。

另外重构也是不可见的。我们总谈可视化,日常的开发工作由用户故事和缺陷来可视化,而重构经常是幕后进行的,不被跟踪、不被记录、不可见,有经验的开发人员会在进行“大”的重构之前口头告知团队,如果没有告知,就在不知不觉中发生了,只有功能被破坏了才能意识到。

总结

以上列出了QA不喜欢重构的三个理由,归根结底其实都是重构不当导致的。代码重构(Code refactoring)指对软件代码做任何更动以增加可读性或者简化结构而不影响输出结果。而不当的重构往往只关注了前半部分却忽略了对输出结果的影响。

个人认为,如果能够注意以下几个方面,也许可以很大程度减少QA对重构的顾虑:

  • 充足的自动化测试是保障输出结果的一个有效途径。不管对于历史代码还是新代码,进行重构的前提应该是确保这部分功能已经被足够的自动化测试覆盖,有的开发人员认为这是一个不可行的建议,因为“充足”对于每个人每个角色的标准可能是不一样的,QA也许永远都不会觉得测试足够,但是其实可以借助测试覆盖率等度量工具,甚至直接针对功能特性由QA来定义需要哪些自动化测试,在补齐这些自动化测试的基础上再做重构。
  • 对于新功能的重构,应该融入到正常开发过程中,在故事验收之前已经完成相应的重构,因为自动化测试不是万能的,也不可能达到100%的覆盖率,所以还是需要QA验证的。这么做就意味着客户要为我们的重构买单,所以作为软件领域专家的我们,如何让业务领域专家的客户理解重构的价值,这就变的至关重要了。
  • 小步前进,尽量避免或者减少大的重构,这样可以减少突然增多的回归测试工作量,也会减少功能被破坏的风险。如果发生了大的重构,反思一下是哪里出了问题?是我们积攒了太多的技术债?还是业务领域模型发生了大的改变?然后采取措施避免类似的事情再度发生。
  • 对于一些核心功能或者组件,进行重构之前尽早告知团队QA,如果能够给QA讲解一下重构的目的以及本次重构可能会影响到的业务区域会对QA有很大的帮助。这样做一方面可以让QA把重心放在最容易受到影响的功能上加强回归测试,另一方面也能帮助QA更合理地安排测试计划。
  • 尽量避免在产品上线前进行重构,不仅可以减轻QA回归测试的负担,也会降低功能破坏后来不及修复的风险。

重构的目标是为了改善代码质量,长远来看应该是可以减少软件缺陷的,从这个角度来说QA和开发人员的目标是一致的,我们相信,如果重构恰当,必定对项目是有利无害的。

Share

神圣的QA——写给应届毕业生们

你有没有过下面的经历:

  • 在谷歌浏览器输入一个网址,出来一个错误提示:“不支持当前浏览器,请用IE访问”…
  • 换成IE,重新打开该网站,输入用户信息注册一个新用户,随后收到一封注册成功邮件,里边直接包含刚刚注册的密码…
  • 用注册的用户名、密码登录进去,又不知道所需要的功能入口在哪里…
  • 翻遍了一层又一层的菜单,终于找到了入口,进去打开的是一个列表,足足等了2分钟才加载完成…
  • 从列表中找到自己需要的那个信息,点击“查看详情”,却显示一堆乱码…

1-face-problems

一次性碰到上面的各种当然属于极端现象,但我敢说,你一定不止一次的碰到过其中的某一问题,而且碰到了一定很郁闷。这些都是软件缺陷,分别是兼容性、安全性、易用性、性能和功能方面的缺陷,一旦出现将会给企业和用户带来不同严重程度的影响。

这种糟糕的体验有没有使你产生想去优化的冲动?你是否想知道如何帮助软件开发团队开发出缺陷更少的软件产品?如果你的回答是肯定的,那么请跟我一起来做QA吧:)

QA是什么?

狭义的理解就是软件测试,软件测试工程师常被称为QA;

广义上,QA就是在软件开发过程中做好软件质量分析和保证的人员。

QA的职责有哪些?

下面结合一个简单的例子说明QA的职责:生产杯子。

2-qa

1. 理解和澄清业务需求

需求是软件开发的源头,需求的正确性、合理性对软件开发的质量有着至关重要的作用。QA的一个很重要的职责就是澄清需求、验证需求合理性,并且帮助团队一致理解需求。

需求包括功能需求,也包括各种非功能需求:性能、安全、易用性、兼容性等。所谓理解和澄清业务需求,就是需要把业务相关的功能和非功能需求都搞清楚了。

对于生产杯子的例子,QA需要搞清楚杯子的功能有哪些:普通的盛水、加热、保温、带吸管等等。杯子的功能可能还远不止这些,这就需要发散性思维,去挖掘可能的用途并进行确认、测试。除了功能需求以外,还有要考虑的非功能需求可能有:材质耐热性、耐摔性、跟各种液体的兼容性、安全性(是否有毒?是否可以砸伤人?)……

3-bottle

注意:

需求的澄清是个过程,并不是在开始开发和测试之前要搞清楚所有的需求(这也是不可能的),同时可以在开发和测试过程中不断去澄清需求、优化业务流程。

2. 制定策略并设计测试

澄清了需求,还得知道怎么去验证软件产品是否满足了需求,这就需要制定测试策略,并根据策略设计测试。大概说来,需要确定测试范围、测试阶段,覆盖要求的测试范围都需要什么类型的测试(功能与非功能等),在每个阶段采用什么测试方法,手动测试和自动化测试的分配比例,如何设计手动和自动化测试的测试用例,用什么工具实现功能、性能和安全测试的自动化等。

对于杯子来说,确定需求之后,针对每一项需求指标需要确认可能采取的不同测试方法,需要考虑如何测试盛水和加热功能、如何测试耐摔性(直接摔吗?)、以及如何测试安全性等等。

可以参考测试四象限测试金字塔等模型来制定测试策略,并根据产品发布周期制定具体的测试计划、设计测试内容。

注意

设计测试,不仅是指设计测试用例。
四象限和金字塔只是个参考,不可以生搬硬套,而且有些内容稍有争议,但参考价值还是很大的。

3. 执行和实现测试

根据制定的测试策略和测试计划、设计好的测试用例,执行手动的验收测试和探索式测试等,实现和执行功能和非功能的自动化测试,统计和生成测试结果报告。

对于生产的杯子,根据设计的测试方案对产品(半成品)进行测试,可能的方式有:往里加水,直接摔到地板上,加热至100摄氏度,往里注入硫酸等。测试之后,统计和生成杯子的测试结果报告,内容包括但不限于测试样品集、测试方法、测试结果、成功率等。

4. 缺陷管理

测试之后,必然会发现很多的缺陷,对这些缺陷进行有效的管理是QA们一个非常重要的职责之一。缺陷管理包括以下内容:

  • 记录缺陷
    发现缺陷以后,QA需要尽自己所能去调查缺陷,收集所有跟缺陷相关的信息,包括不限于出现的环境(操作系统、浏览器和不同的测试环境等)、重现步骤、屏幕截图、日志等,并将这些信息简单清晰的记录下来。
  • 确定严重性和优先级
    严重性是指缺陷发生对用户所产生影响的严重程度,优先级是指需要修复的紧急程度,通常需要结合严重性和发布计划等来确定。新QA往往比较容易混淆这两个概念,注意它们是有区别的,优先级高的严重性不一定高,而严重性高的往往优先级比较高。具体需要根据产品和项目实际情况来确定。
  • 分析和跟踪缺陷
    开发人员修复缺陷之后,QA需要测试和验证缺陷,很多时候缺陷被验证之后就没人管了,但缺陷的生命周期并没有结束,后面还有非常重要的分析和跟踪阶段。在这个阶段,QA要分析缺陷产生的原因,影响的功能模块,过去一段时间以来的发展趋势等,根据这些分析结果制定下一阶段避免和减少同样缺陷产生所需要采取的行动措施,并且跟踪行动执行的详细情况。
注意

缺陷分析是非常重要的一个环节,但却很容易被忽略。关于缺陷管理的更多详细内容请参考我的另一篇文章《软件缺陷的有效管理》

再来看看“杯子”的例子,执行一番测试之后,可能发现如下缺陷:

  1. 容积为100毫升的量杯只能盛水80毫升
  2. 杯子表面不够光滑但不影响使用
  3. 清水倒进去水变成酸的了

第一个是严重的功能缺陷,第二个属于UI问题,第三个可能是一个非常严重的安全性问题。QA需要将这些缺陷报告,并根据严重性和产品流程等来安排优先级,督促开发人员及时修复高优先级的缺陷。缺陷修复并重新测试没问题之后,要分析统计,找出产生缺陷的环节,并采取措施防止下一批杯子出现同样的问题。

5. 质量反馈和风险意识

软件产品的质量不是QA这一个角色能保证的,而是需要整个开发团队所有人员齐心协力,共同为质量负责。QA作为质量分析保证的主力军,对产品质量需要有更清晰的认识,及时识别质量风险,并反馈给整个团队。

SONY DSC

将质量相关因素可视化出来,是反馈给团队的较为有效的方式。质量可视化包括但不限于cycle time、自动化测试覆盖率、缺陷分析报告、错误日志分析、网站分析工具统计报告、性能监控数据、安全扫描结果、用户反馈、产品环境下的缺陷统计等,可以根据项目和产品具体情况具体定义。

定期或者不定期的把这些可视化结果反馈给团队,有助于形成团队对质量的统一认识,发挥团队每个成员对于质量保证的主观能动性,从而一起制定和调整下一阶段的质量保证策略。

测试了一批杯子之后,将杯子的质量相关情况反馈给团队,内容可能是:

  • 最近这批杯子出现的缺陷明显比上一批少,可以鼓励团队再接再厉;
  • 这批杯子出现了很多严重缺陷,那么就需要组织团队一起讨论问题根源,考虑采取措施防止问题重复出现;
  • 某一批杯子等待很久才可测,需要分析原因,采取改进行动;
  • 这一批杯子生产效率明显比以前有提高,同样可以确认效率提高的原因,后续可以以此为参考持续改进和提高。

QA的必备技能要求

硬技能之扎实的计算机基础

软件测试的概念虽然已经出现多年,但QA或者软件测试工程师还是被很多人误认为就是简单的点击应用程序进行测试,是一项没有技术含量的工作。其实,从前面对QA职责的描述,大家可以看到,QA的技能要求还是蛮高的,其中非常关键的一项就是具备扎实的计算机基础,具备基本的编码能力和数据库操作能力。

只有了解系统的工作原理,才能更好的去验证系统的完备性,发现问题才能更快更有效的初步定位。因此,下次有人问你为啥选择软件测试行业,千万别说是因为自己技术不行,那样会被鄙视的。

5-i-cant

各项软技能

从QA的职责要求可以看出,做好QA还需要多方面的软技能:

  • 快速理解业务的能力:通常丰富的领域知识和快速学习新事物的能力可以帮助快速理解业务。
  • 分析能力和定位问题的能力:执行测试和定位缺陷的过程中,这种能力非常重要。
  • 良好的沟通表达能力,包括口头和书面沟通:QA需要跟客户、需求人员、开发人员等不同角色沟通以更好的完成工作,良好的沟通将会事半功倍。
  • 踏实、认真、细心:每一个测试、每一个缺陷都需要认真的对待,容不得半点浮躁,这些技能无需细说。

当然,除此之外,能在QA职业道路上有良好的发展,极其重要的一点是对软件质量相关工作有浓厚的兴趣。

写在最后

QA在一个软件开发团队,能与需求人员一起分析需求,能与开发人员一起编写测试,能给团队和客户详细展示系统功能,还能更新整个产品/项目的质量状态,是比PM更为了解产品、项目的人,听起来就很厉害,对不对?

是的,QA就是这么神圣的工作!你心动了吗?

Share

产品环境下的QA

2015年11月ThoughtWorks发布的技术雷达提到一个新的主题——产品环境下的QA(QA in Production),2016年4月再次提到。这个主题第一次出现在技术雷达,就深深的吸引了我,当时我就给测试团队成员转发了这个内容,但同时脑子里也产生了这样一系列的疑问:

  • 产品环境下的QA可以做什么呢?有什么挑战,又有哪些好处?
  • 它跟类产品环境的QA有何区别,是否就是类产品环境QA方法的延伸?
  • 产品环境有运维支持团队(Ops),产品环境下的QA跟Ops所做的事情又有什么区别与联系?

带着这些疑问,结合项目上的一系列实践,于是有了本文。

产品环境的特点

为了尽量避免产品环境出现Bug,通常采取的措施是从“类产品环境”考虑,一步步做好质量控制。其实,如果能从产品环境做些QA工作,对于产品质量的提高也是有很大帮助的。想要做产品环境下的QA,首先得了解产品环境有哪些特点:

1. 真实、不可破坏

产品环境都是真实用户在使用,是真正支持企业业务运转的系统,不可以随意在这个环境中做测试,尤其是破坏性的测试。

2. 基础设施差异

产品环境往往有着比类产品环境更复杂和健全的基础设施,可能会出现类产品环境不能预测到的缺陷和异常。

3. 系统复杂度

产品环境需要与多个不同的系统集成,系统复杂度会比类产品环境高很多,这种复杂的系统集成很有可能导致一些意外的情况出现。

4. 数据复杂度

产品环境的数据量和数据复杂度也是类产品环境无法比拟的,通常都不是一个数量级的数据,容易引发性能问题、或者一些复杂的数据组合导致的问题。

5. 用户行为千奇百怪

产品环境中用户分布广泛,使用习惯各种各样,导致用户行为千奇百怪,某些使用行为可能就会产生意想不到的问题。

6. 访问受限

产品环境由于是真实业务线上的系统,对安全性和稳定性要求更高,服务器通常不是所有QA可以随便访问的,这种访问受限的情况对于产品环境的一些缺陷排查带来了很大的不便。

7. 真实的用户反馈

用户在产品环境中使用,能够提出一些真实而重要的反馈,但是开发团队往往不能直接接触终端用户,QA也就没有办法获得第一手的用户反馈,这些反馈常常需要通过支持团队来转述。

产品环境的这些特点决定了QA在产品环境不是想做什么就能做什么的。原来类产品环境那套质量保证理论和方法都行不通了。那么,产品环境下的QA又有哪些特点呢?

产品环境下的QA的特点

一、不同于类产品环境的QA

产品环境的特点决定了产品环境下的QA是跟类产品环境的QA不同的,前者不能主动的去测试产品环境的系统,但是可以做到下面这些:

产品环境下的QA

  1. 引入产品系统的监控,制定监控预警标准,找出产品环境下使用的质量度量。比如,分析产品环境日志,收集系统运行的错误、异常和失败等信息;或者利用网站分析工具收集用户使用应用程序的数据,分析数据量需求、产品的性能趋势、用户的地域特征、用户的行为习惯和产品在同类型产品市场的占有率等。
  2. 收集产品环境下最终用户的反馈,对反馈进行分类分析。用户反馈通常有缺陷、抱怨和建议,针对不同类型需要采取不同的处理方式,利用用户反馈,改进系统功能,提高产品质量,同时优化业务价值,扩大产品的市场影响力,提高企业竞争力。

因此,产品环境下的QA并不是类产品环境QA活动的简单后延,它有着自己独特的特点。

二、不能独立存在

产品环境下的QA所设置的监控标准是根据系统的行为特点和在类产品环境下的表现来定义的,产品环境下各项反馈的分析结果反过来又影响着类产品环境的QA过程,而且这两者是相辅相成的,只有形成了良性环路,才能把产品环境下的QA做好。

三、有别于Ops

产品环境设置监控预警和收集用户反馈不都是Ops团队可以做的事情吗?还要QA参与干什么?是因为QA有着独特的思维模式和视角,QA的参与能够帮助更好的分析产品环境下收集到的各种反馈,并且基于对于系统的了解,将这些反馈更好的应用到日常的开发工作中。QA在整个监控预警、收集和分析用户反馈的过程中主要充当分析者和协调者的角色,对产品环境下的质量保证工作起到至关重要的作用。

这时候的QA带着QA和Ops的帽子,兼具QA和Ops的部分职责,类似于QAOps,不过现在都提倡不要有独立的DevOps,我们也不要独立的QAOps角色,只是让QA这个角色可做的事情得到了延伸和扩展而已,本质上还是QA。

四、跟APM的侧重点不同

可能有人会觉得产品环境下的QA跟APM有相似之处,那么这两者是不是一回事呢?

维基百科这样解释APM

“In the fields of information technology and systems management, application performance management (APM) is the monitoring and management of performance and availability of software applications. (在信息科技和系统管理领域,APM对软件应用程序的性能和可用性的监控和管理。)”

APM更多的是从性能角度出发去管理和优化应用,可以发生在各个阶段,不一定是产品环境。产品环境下的QA是指在产品环境进行一系列的监控和数据收集,从系统功能、性能、易用性等多个方面进行优化,从而最终优化业务价值。因此,两者是不同的。

产品环境下的QA在项目上的实践

我所在的项目是一个离岸交付项目,采用敏捷开发模式,四周一次发布到产品环境,开发的系统包括一个内部员工使用系统和一个外部用户使用的网站,用户遍及全球,整个项目已经持续了七年有余。产品环境具备前面所描述的所有特点,并且产品环境每日的错误日志达到几千条。正是由于错误日志的数量到了一个不能忍的程度,产品环境才引起了各方的关注,也使得产品环境下的QA迎来了试点的最佳时机。产品环境下的QA在我们项目上的实践主要是三部分内容:日志分析和优化、Google Analytics数据分析、用户反馈的收集和分析。下面逐个介绍。

一、日志分析和优化

既然错误日志那么多,首先就是从这些错误日志下手。项目使用的日志分析工具是Splunk,这个工具功能强大、使用方便,关于工具的详细信息可以参考官网。下图所示为使用Splunk通过指定条件搜索日志文件得到的结果页面,结果集里四条类似乱码的东西就是代表有四种类型的错误日志,每种错误出现的数量和百分比都有统计,点击每条结果可以查看详细的错误日志信息。

关于日志的分析和优化,我们在项目上做了如下工作:

1. 分析产品环境的错误日志

专人负责产品环境错误日志的分析,挑出优先级高的进行修复处理;对新功能进行日志监控,确保上线后能够运行正常。

2. 监控测试环境的错误日志

把产品环境错误日志的分析方法应用于测试环境,让bug发现提前到测试阶段。据不完全统计,最近两三个月通过这种方式发现并修复了好几个潜在的Bug。

3. 利用日志监控不同功能的性能

Splunk里设有专门的统计和监控系统性能的Dashboard,QA会定期从里边拿出高优先级的给开发人员进行性能调优。

4. 日志记录标准化

现有的产品环境日志记录中存在一些问题,给分析工作带来不便。团队为此进行讨论并达成共识:

  • 将日志输出到各个服务器的同一个路径;
  • 统一日志记录格式,并且尽量记录更全面的信息以便进行后期的日志分析;
  • 清晰定义各个日志级别(Debug,Info,Warning,Error,Critical,Fatal),将已有的误记成错误的日志降低到正确的级别,对于新功能则严格按照所定义级别记录日志;
  • QA在用户故事(Story)的开发机验收(Dev-box Testing or Desk Check)阶段负责跟开发人员确认相关日志记录是否符合标准,并且通过测试环境的日志监控可以及时验证新功能的日志记录情况。

二、Google Analytics数据分析

Google Analytics(以下简称GA)是项目用来统计网站使用情况的工具,从GA上可以获取很多有价值的信息,对这些信息进行分析是我们实践的产品环境下QA的另一块内容,具体做了下面几项工作:

1. 操作系统和浏览器使用情况分析

根据产品环境操作系统和浏览器使用比例去调整测试环境所使用的系统,比如从重点关注IE9调整到IE11。

2. 分析QA测试跟用户真实行为的差异,及时调整测试

根据GA上用户访问的路径可以发现我们QA的测试跟一些真实用户使用习惯的差异,这样如果按照我们通常的路径去测试,可能有些问题难以在测试阶段被发现。比如,QA在测试环境通常打开“工作记录”的方式是这样的:

而我们从GA上发现真实用户使用过程中,打开“工作记录”最多的路径是这样的:

发现了这种差异,QA就要在测试时候做相应的调整,让测试更接近用户的行为习惯。

3. 提炼关键业务场景,增加测试覆盖

利用GA的数据结合客户业务人员对系统各功能使用情况的介绍,我们提炼出系统最为关键的业务场景,并且尽量分层(参考测试金字塔)实现自动化测试覆盖,以减轻QA回归测试的压力。

4. 发现用户较少使用的功能,优化业务流程

类似的,我们还可以通过GA发现一些用户较少使用的功能,QA的测试基本不需要太多去关注这些功能,同时可以跟业务分析人员一起分析功能不被使用的原因,在后续的功能开发过程中可以作为借鉴,从而优化业务流程。

5. 分析用户地区分布和使用时间段分布,合理安排定时任务运行时间

通过GA上的数据,统计出哪个时间段是相对空闲的,在不影响真实业务的前提下,把一些资源消耗较大的任务安排在那个时候执行,合理分配资源以减轻服务器的负担,尽量减少对用户的影响。

6. 监控系统性能变化趋势,规避性能风险

QA定期查看网站平均访问时间,监控性能趋势,同时要重点关注那些访问非常慢的页面或功能,必要的时候创建性能缺陷卡,由开发人员来调查分析并修复或优化。

7. 确保GA能够统计到所有需要统计的功能

GA数据虽然很有用,但前提是正确记录了所需要统计的数据,所以在开发过程中要确保GA嵌入到了各个需要统计的功能或页面,QA在类产品环境测试的时候需要验证这一点。

下图为从GA拿到的浏览器分布情况和页面平均加载时间的一些数据:

GA数据分析

三、用户反馈的收集和分析

作为开发团队的我们基本是不能直接接触到系统终端用户的,直接接受反馈的是客户的Ops团队,QA主要通过下面几个途径去协助分析和梳理用户反馈:

1. 跟Ops和业务的定期沟通会议

QA会定期跟客户的Ops和业务人员沟通,了解用户对于现有系统的反馈,找出在测试中需要重视的功能特性,对类产品环境的测试关注点做出相应的调整。

2. 培训Ops人员

指导和协助客户Ops人员利用鱼骨图(Fishbone Diagram)的方法对收集到的用户反馈进行分析和分类,将分析结果跟现有的测试覆盖情况进行对比,找出测试过程的薄弱环节,并做出改进。比如,如果某个浏览器出现的bug比较多,我们的测试就要加强该浏览器的关注;或者在发现不同用户权限导致的问题出现频率高,那就得在测试中注意覆盖不同用户角色的测试,反之则减弱不同用户的覆盖,主要测最常用的那类角色即可。

3. 调查和跟踪产品环境Bug

帮助重现和调查用户反馈过来的产品环境Bug,并负责跟踪修复和验证;对于难以重现的问题,则添加日志监控,通过分析收集到的日志信息找出问题根源,从而进行修复。

4. 协助梳理业务需求

系统要增加某个新功能的时候,客户Product Owner(以下简称PO)或其他业务人员跟用户会一起沟通该功能相关业务现有的使用习惯、使用场景,QA也会尽量参与这种会议,收集用户第一手需求信息,这些信息对于后期该业务功能开发时候的QA过程将非常有帮助。而还有些功能,PO可能一时也拿不定主意要做成什么样子,我们会发布MVP的版本给用户使用,QA协助业务人员分析用户使用后的反馈,梳理更具体的用户需求。

总结

  1. 产品环境下的QA将工作范围从需求扩大到了产品环境,增加了更多的反馈来源,跟持续交付结合,可以帮助持续提高产品质量、优化业务价值。
  2. 产品环境下的QA给的工具箱添加了更多的工具,提供了更多评估和提高系统质量的选项,是QA们值得深入研究的话题。
  3. 产品环境下的QA不能走的太远,必须先做好类产品环境的质量保证,并且仅适用于持续交付实践的比较好的组织。如果连类产品环境的质量保证都做不好,就想着去做产品环境下的QA,那只能是舍本逐末、事倍功半。
Share