做个会讲故事的QA

2021-09-11
浏览次数:
返回列表

在信息大量充斥的软件组织内,QA的声音往往是最容易被忽略,见过图表并茂,数据充实、分析合理的QA报告,照样燕过无痕,留不下什么印象。只有一种例外,就是会讲故事的QA, 往往能触动我们内心,从而将情感带入记忆,有所行动。

讲好QA故事,有以下几个要点。

主题明确

在当今动态的环境下,每个QA报告都要有明确的主题。首先要清楚你的报告读者是谁,自己想要传达什么样的信息给他们?故事一定要围绕主题。比如,你认为现在做法导致测试团队没有足够的时间完成必要的测试工作,那么你的故事要揭示这样做给企业带来的危害,以及成功组织优秀实践带来的好处。你的报告的目的就是希望引起领导重视,改变现有做法,可能是追加资源,可能是改变开发模式,让测试更早介入,也可能是让领导痛下决心,真正推动测试自动化。讲故事之前,想好你的主题,千万不要跑题。

主题可以来源于管理层,EPG,也可以由QA团队自己定。

挖掘故事

会讲故事的QA一定是一个善于发现的QA。在和团队打交道时会随时记下一些让你难忘的场景,特别是失败的故事。在平时各种学习机会中,记下别人的故事,别人的经验。一定要有好奇心,搞清楚数据背后的故事。

在确定报告主题之后,找到最好的故事,当然有必要时,需要深入到团队中,完善你的故事。一般来讲,QA报告的频率至少按月计算,偶尔可以事件驱动,要给自己足够的时间。

做个低调的讲故事的人

千万不要把自己变成故事的主角,不要炫耀自己发现了这些重要的问题。故事的主角应该是你支持的团队,他们成功失败的喜怒哀乐,观察到的事件。在适合的场景下,让他们成为你故事中的英雄,这会让你的读者更容易接受你的信息。

强调团队如何应对挑战

应对挑战的故事是管理层感兴趣的,不要避讳后续改进的路会十分艰难。有挑战的故事,可以唤起读者,成为后续改进的好伙伴。

简洁、简洁、再简洁

QA的故事不是小说,不需要波澜曲折的情节。故事应该简单明了,开门见山,直入主题。一定不要让不必要的细节淹没主题。我相信这样的QA写作原则,“Less is more.”

想变成更好的讲故事的QA?多讲故事

充分利用反馈,不断提升你的讲故事能力是QA必须坚持的。好的故事带来的变化会让你有成就感,会让你成为领导的眼睛,团队的朋友。你花30分钟写个一个小故事,有可能给你的组织、团队带来数月甚至数年的的正面影响。坚持,不断的讲故事,你会成为QA中的超级战斗机。

三个让我难忘的QA报告例子

在不违反保密原则的前提下,和大家分享三个QA写的故事。

故事1:为何财富库在项目中没有发挥作用

2004年,看到过一份雷神下属一个组织的QA报告。在推动CMMI三级改进中,QA发现财富库没有真正在项目中发挥作用。在一次季度的QA报告中,他们围绕这个主题做了深入探讨。我看到了两个团队在向财富库提交数据、材料中的困扰和应付交差的故事,看到了他们在形成解决方案、计划、调整中面对财富库的不知所措。故事里打动我的是财富库的使用者的心声,以及他们被排斥在外的无奈。

故事贯穿的一个核心理念是如何让团队在研发过程中不再单打独斗?什么样的财富库能发挥作用?财富库应如何管理?

这份报告是过程的执行者的故事,这份报告让他们开始变成了过程的主人。我有幸参加了他们后来的评估,看到了一个富有生命力,易使用的财富库,过程执行者把它当成了一个有效经验的学习平台,极大推动了各种复用。

故事2:一个Bug后面的故事

之前写过一篇“一份软件Bug报告”的文章,里面讲的是一家瑞典IT公司一个Bug的故事,我感触很深。故事带来了众多启示,其中比较重要的是QA的定位。

故事3:看板推动中的好与坏

招行的QA堪称国内行业楷模,在他们精益转型过程中发挥了重要的作用。2017年2.0试点评估时,看过一位QA写的颇有价值的一个团队看板转型中的故事。在2个月的时间里,他深入到这个团队,对其核心看板实践做了第一手的调查,展示了看板的变化、团队的优秀实践以及如何克服解决转型中一系列的问题、QA自己的观察和建议等。时隔4年,我至今还能记得其中的一些内容。这份报告对管理层和其他看板团队都有一定的参考价值。当他们告诉我“研发团队都在期盼着QA的到来”时,我一点也不奇怪。大家都喜欢会讲故事的QA,都喜欢能给团队真正带来一些重要启示的QA。

好像乔布斯说过一段话,大意是会讲故事是我们应具备的最重要能力之一。这句话对QA来讲更加贴切,可惜这个能力长期不被重视。希望能看到、听到越来越多QA让人耳目一新的故事。

本文转载自老丛讲桌。

CMMI文章推荐
热门资质推荐
最新热门政策
常见问题推荐