您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件测试技术 > 其他相关 > 正文

在一个“去QA化”的项目中,QA能做什么?

发表于:2022-04-27 作者:Thoughtworks洞见 来源: Thoughtworks洞见

第一次在某篇文章里看到“去QA化”这个概念,我当时也就是随随便便翻看了一下,并未多加关注。第二次是在QA社区群里看见更资深的同事在谈论“去QA化”,当时我小小的脑袋里,单纯觉得“去QA化”离我还是很有一些距离的。

万万没想到!没过多久,当我上到一个项目之后,TL跟我说,我们有些项目确实是没有QA的,隔壁项目组有一个QA,但是在整个开发流程中也没有专门的测试阶段。听完之后,我眼睛瞪得像铜铃(夸张修辞):那谁来做测试策略呢?在什么阶段测卡了?什么时候做探索式测试呢?TL顾及我作为QA的尊严,立马跟我强调:“我觉得QA还是非常重要的,我是反对他们那样做的!太危险啦!”。但是,她善良的劝慰并没有抚平我的震惊,打消我的思考。这次我知道,“去QA化”可能真的来了。

那在“去QA化”的项目中,我能做什么来为团队提供价值呢?我带着这样的思考来到了项目上,并得出了一些自己的思考。

测试策略

因地制宜地制定测试策略,这个是QA到了新项目必须要做的一个事情。在了解项目的上下文之后,我们需要及时去做这个事情,它的优先级是非常高的。测试策略是一个非常重要的指导,它涵盖了功能,性能,Accessibility,兼容性,安全等方面都需要测什么,也明确了如何去测试的问题。在敏捷开发流程下,推荐大家可以参考“敏捷测试四象限”去思考设计自己的测试策略。

如果这个项目不是一个全新的项目,已经有了现成的测试策略,我们需要在加入项目时去理解现在的测试策略,并在后续对项目背景、技术架构、软件功能有了更深入的了解之后,看是否需要去改进当前测试策略。每个项目的测试策略,其实都应该跟随项目变化不断演进。

质量内建

QA为什么要在项目上推进质量内建?首先,我们想想缺陷是被测试出来的吗?不,它是在生产过程中产生的,所以我们需要在生产的过程中去提升产品的质量,减少缺陷。

在敏捷开发的流程中,我们有需求分析、架构设计、Kick off、Desk Check、In QA这一系列的环节,质量内建其实就是要求我们做好每个环节的质量保障,努力避免缺陷,尽早发现缺陷,而不是期望在测试环节发现所有缺陷,然后再修复。缺陷发现得越晚,修复得成本就越高。并且,缺陷发现越多,就越可能存在更多的缺陷。

我们在每一个阶段都需要有质量保障策略,团队的每个人都需要为质量负责。比如:

  • 在需求分析阶段,写卡需要遵守INVEST原则,团队需要对需求的理解达成一致;
  • 在开发阶段,可以通过Pair、TDD、QA和Dev pair写单元测试、及时需求澄清等保障开发阶段的质量;
  • 在测试阶段,可以通过充分的测试设计、探索性测试、更完善的自动化测试覆盖等去及时发现缺陷。

除此以外,质量内建还包括其它的方面,需求管理,风险管理,提高团队的质量意识等。

自动化测试

制定自动化测试策略,并跟团队达成一致。搭建E2E和API自动化测试框架,编写自动化测试代码,并经常给项目小伙伴们科普洗脑(我不是,我没有)自动化测试的重要性,逐步提高项目的自动化覆盖。

除了UT、E2E、API这些自动化测试以外,其实任何经常重复执行的动作,都可以尝试自动化,比如准备测试数据,重复填写冗长的表单等工作。自动化测试可以减少人工重复点点点,解放QA的一部分劳动力,并且自动化测试的及时反馈,可以让团队和客户对产品质量更有信心。

测试左移

需求分析是开发流程当中非常重要的一环(不局限于敏捷开发),QA应该更早地介入需求分析,更多去关注业务需求,以QA的独特视角去分析需求的合理性,以及一些边界场景。在需求分析阶段,多与客户进行沟通,理解客户的真正诉求。跟BA一起pair完成写卡,补充业务场景。并尽量在Kick off之前,确定好这张卡哪些testcase需要API自动化覆盖,哪些需要在e2e自动化覆盖,哪些是需要UT测试来覆盖。

在故事卡进入开发阶段前,通过当面沟通、ACs、testcases的各种方式(根据自己项目情况来),确定并澄清需求,达成一致理解。减少因为需求不合理,需求分析不充分,需求理解不一致导致的问题。

持续改进

在一个项目开始或比较混乱的时期,QA总是有很多重要的事情要去做,如前文提到的,制定测试策略、提高自动化覆盖、提高team的质量意识等等工作。但是,当项目进入一个稳定期,团队小伙伴们已经有较好的质量意识,测试覆盖率也达到较高的标准,这个时候我们可以去做什么呢?

首先,我们知道质量内建是一个持续的长期的概念,让大家适应了各个角色在各流程承担的质量职责之后,QA需要保持观察,对质量守护工作保持敏感性,持续推进质量内建;

另外在新版本发布后,通过User Testing,收集用户反馈,或者分析终端用户的行为,收集分析生产环境的数据,持续进行改进;

QA还需要收集线上问题、UAT问题,进行缺陷分析,并组织团队一起共同制定质量改进方案。在项目的演进过程中,持续的思考是否需要改进我们的质量保障方案、测试策略。

质量内建以及高度的自动化测试,偶尔让我们看起来不再需要QA,可是谁来做质量内建呢?谁来输出质量保障方案呢?谁来写自动化测试呢?谁来做持续改进呢?是QA,或者是戴上QA帽子的人。

总结下来,其实QA在项目上能做的东西有很多,包括但不限于:

  • 制定测试策略,明确测试范围、测试方法,这是团队测试工作的重要指导;
  • 质量内建,将质量内建到开发各阶段,引领团队成员一起关注并提升质量;
  • 自动化测试,逐步构建各层级的自动化测试覆盖,提高自动化测试有效性;
  • 测试左移,将测试活动提前到需求分析阶段,减少由于需求不合理引起的质量问题;
  • 测试右移,关注生产环境质量,分析生产环境的数据、问题及反馈,由此去找到更多的质量改进方向;
  • 持续改进,保持对质量的敏感性,持续观察项目中可以改进的地方,持续推动质量内建工作;

除了以上几个点,QA还可以多关注提升效能,面向客户等方向。

我觉得,所谓“去QA化”只是在某些项目中去掉了单独的一个QA角色,但是总有人会戴上QA的帽子,或者人人都戴上了QA的帽子,人人都拥有很高的质量意识,这其实是QA的理想国。