在信息大量充斥的软件组织内，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让人耳目一新的故事。

本文转载自老丛讲桌。