作者 | 赵瑞华
随着测试人员陆续开始尝试角色转变，坚守的QA需要找到自己的发展之路。兴趣和性格是客观因素，好奇心和发散性思维则是帮助成为优秀QA的必要因素。我想通过一些小的例子来与大家互动探讨。
测试你做对了吗？
让我们从这样一个现实中的小例子来开始我们的思考之旅 “假如一堆稻草中不小心掉入了一根针，我们该如何将它找出呢？”
回想当时看到这个题目时，我的第一反应是太难找了。从这个小事例联想到自己的工作，我作为QA或多或少是否做过类似的事情呢？在初入行业的时候我可能就是这个在草堆里找针的人，我花费了大量的时间仔细地在草堆外面认真查找，甚至使用了放大镜一点一点的反复，努力不漏过每一个角落。再后来慢慢积攒了一些经验，我开始使用工具了。我尝试使用不同吸力的磁铁，金属探测设备。这正是我工作经历中的纯黑盒测试阶段与纯自动化UI测试阶段。
在有了不同的经历后，我开始反思自我。类似大草堆里找针这么大的工程，耗时耗力，是否会有更好的办法呢？我真应该去多了解一下每个产品使用的工具与技术，以及深入了解并参与它的搭建过程。于是我加入了TW，开启了第三段测试之旅。
再回来看看这个例子，我在想也许草堆的中间是空心的，有一扇隐形的门可以走进去。但是在过去我竟然没有想过要去尝试（当然，这里所说的没有尝试是比较夸张了点）。在我们打算开始堆草堆的时候就应该考虑的更多一些，制定相应的策略保证在堆积的过程中不会有一些杂物不小心被堆进去，我们应该争取在草堆堆积的过程中不让这根针有机可乘。
多思考，多探讨，不要急于开始
有人告诉我下面这张图片中有一只虫子，让我猜猜它在哪里？我仔细地找了一遍没找到，于是又开始第二遍第三遍的寻找。甚至试图拿着放大镜仔细研究这张图片。我努力不放过每一个角落。可是最终我也未能找到，这只Bug到底藏在了哪里呢？
等到答案揭晓的时候，我忽然意识到了作为QA我竟然忽略了最重要的东西——澄清。上周在听冰玉老师的session《构建体系化思维》时，她对于这块也做了详细的讲解。对于她给出的测试茶杯的例子印象非常深刻。面试的时候经常会随机问候选人，水杯怎么测，插线板怎么测，开关怎么测。有相当一部分的候选人觉得蒙圈，也有人觉得非常容易，很多人没有要求思考时间也不提问，直接开始回答。这样草率的回复怎么可能会是面试官想要听到的答复呢？
下面我以所在的某项目中最近发生的一件事情为例引入我自己的一些反思。我们会批量生成一种类似于限量版的现金券，用户收到该现金券便可使用它并从中受益，前期我们只做了简单的生成与存储。Marketing团队会根据规则手动将限量版的现金券发给特定的用户群体。该功能投入生产后反响很棒，于是我们决定将发送流程自动化，集成到内部后台系统，根据 Marketing 团队上传的用户列表生成对应的现金券并绑定到相应的用户账户。到这里所有的需求都很清晰明了。
接下来客户提出来既然券都跟用户绑定了，那么我们为什么不把它展示给用户呢？于是提出了我们需要做一个最早可用版本用来展示功能。我们为此专门定了一次会议，参与的人有客户多部门的老大以及我们项目小组的所有相关人员。大家都很兴奋我们要实现这样一个功能了，我们讨论了需求，设计，需求将要带来的价值以及如何衡量这个需求是否成功的指标与方法。我们也书写了相关的需求文档。然而UX老大参与DC的时候，他询问了我们这个版本是要给内测人员看吗？经过一番讨论，这时我们才发现大家的理解不一致。由于我们开始讨论的时候提到了想根据市场效果再决定是否继续做下一个版本，我们组的UX理解我们只给内测用户展示，所以她设计了一个很简单的展示版本。而其他人则认为想先实现简化版的功能，再根据市场反馈决定是否再进一步投入时间进行优化。等国庆假期过去了，我看到它竟然还没有发布。直到上周我们终于发布了这个功能。
大致增加了：
- 复杂漂亮的UX 设计
- 分享现金券给他人
- 用户事件记录
- 自动发送通知给收到现金券的用户
- ......
对于纯纯的远程协作团队（成员分散在超过四个国家，超过5个城市），我们的线下交流少之又少。每天的交流主要是在站会和Mob会议里（每天4小时），如果在我们开会讨论需求的时候多讨论几句，在我们每天交流中多探讨一些。可能我们能更早的意识到了我们大家对于_Earlist usable_ 的理解是不同的，我们就能提早设计，不至于后来返工拖延了发布。在后来的retro中，大家一致认为在开始每一项工作之前我们就应该做足够的思考与探讨。
花絮： 尽管有点插曲，但是在发布前内测的时候，客户的老大们对这个功能的实现非常满意，团队开始咨询marketing是否可以给我们每人一张现金券。客户的老大们也开始通过这种方式去分享现金券给他们的好友们。
跳出思维定式的束缚
让我们从一个简单的小互动开始，一起感受一下我们怎么考虑这个问题。请大家拿出小本本一起画出如图的9个点。然后用一笔将9个点连起来，你会怎么连呢？
1.不同起点回形绕圈
2.Z形
3.三角风筝形
4.用一根足够粗的笔一笔划过
我相信一定有很多聪明的小伙伴们想到了第四种方法。此处有掌声👏👏👏但是还是会有很多小伙伴很容易被问题中“连起来”几个字带着开始连线而忽略了最简单的一笔划过。
我看到过这样一个实验，将相当数量的蜜蜂和苍蝇置于一个开口的瓶子中，将瓶子放倒，让瓶底朝着有光的地方。大家猜猜接下来会发生？
结果苍蝇跑光了，而蜜蜂基于出口就在光亮处的思维方式，设定了出口就是那个有光的地方，所以它们一直朝着光亮的地方努力而忽略了藏在暗处的出口，一次次地撞向瓶底。而毫无逻辑的苍蝇到处乱飞却意外地找到了出口。
大多数时候思维定式没有错，但是在一个产品上工作久了的伙伴或多或少都会遇到越熟悉的地方越容易出错的情况。我自己也曾遇到过类似的问题。日复一日测试类似的功能让我们很容易形成了思维定式，形成了固定的操作习惯。对于熟悉的功能反而考虑得不再那么周全，总是以老的方式去考虑熟悉的功能，殊不知在不知不觉中它已不再那么熟悉。而对于新的功能模块大家通常都会格外的小心谨慎和关注。所以我自己会定期复盘，定期反思。一旦发现自己沉浸于思维定式里，一定要设法打破它。尽管我自己其实做的也并不是很好，但是我时常会反省并时刻提醒自己。
保持好奇，多提问
这里又来了一个有意思的小互动，请大家帮忙找找以下这段话中包含有多少个字母F？
答案是6个，你找对了吗？
请大家再一次帮忙找找这段话中有多少F呢？
答案是68个，这次你对了吗？
请大家再一次帮忙找找这段话中有多少F呢？
答案是68个，这次你对了吗？
请大家回想一下在第一遍大家都是如何找的呢？有没有漏掉的呢？在第二遍查找的时候大家又是如何做的呢？是否将第一次漏掉的字母找到了呢？看到这个配色大家应该多少有点好奇，为什么好好的一段话要用黑色背景，有多少人因为好奇而做了进一步的思考与调查呢？联想我们的日常工作，我们可能偶尔的遇到了一些奇奇怪怪的问题，但是刷新，重试之后我们发现问题不存在了，我们是否继续深究了呢？
很多时候往往都是这些不起眼的小问题积压最终导致越来越多的系统问题。所以在我们每次遇到这些行为的时候一定要保持住好奇心，多思考多调研。即使不能重现，我们可以停下来休息一下，画一画，再深入思考一下。我们可以截图，查看日志，回想自己的操作步骤和不寻常之处（也可以利用系统的行为跟踪工具，总结反馈或者咨询相关人员。又或者我们可以记录一个stakehold卡在我们的backlog里面用来追踪后续。）一定不要等到有一天客户报了问题过来，我们突然意识到这个错误，这个问题自己曾经也遇到过。当然我们也得综合考虑一下投入产出比，以及问题所带来的用户影响有多大，优先级如何等。
在移动端测试中经常会有一些偶现的问题，有的问题真的是特别边缘的情况，多个条件同时满足才能偶尔触发。有的却是通过某些特定的操作就会100%触发。所有保持好奇，适当的投入一些调研是很有非常有必要的。
提高专注还得发散
这个小题目貌似有点自相矛盾，到底是要专注呢还是要发散呢？让我们还是先从互动开始探讨。假如有一个大的正方形，它被平均分为了四个小的正方形ABCD。A、B、C三个小正方形内分别嵌套了一个更小的正方形，那么请按照要求的规则将每个图形淡灰色部分进行切分。
1.请将右上角的正方形A中淡色部分分成两个相同的图形
2.请将左上角的正方形B中淡色部分分成三个相同的图形
3.请将左下角的正方形C中淡色部分分成四个相同的图形
4.请将右下角的正方形D中淡色部分分成七个相同的图形
如果按顺序来做这四次分割，每次成功完成一步我们会很容易尝试使用相同的方法求进行下一次的图形分割。然而到了第四步，我们可能还会专注于之前的分割思路。假如我只给出了一个单独的正方形让大家分成七份，大家应该都会很容易就可以分成功。
再来说说我自己，入行不久我就发现我自己的思维比较发散，想象力丰富，我经常是团队中讨论需求提问最多的那个人。每次有了新的需求，除了需求本身的描述，我可能会瞬间联想到与它相关的大大小小的功能。时间久了我慢慢的反思总结，在讨论需求的时候我们优先需要考虑需求本身，我们需要更多的关注点。其次，我们再向外发散考虑更多更深更远的情况。
在之前的一家公司我们经常在发布前回归测试阶段抽出一定的时间来做随机测试。经常发现随机测试发现的问题要比我们遵从测试用例做回归测试发现的问题多一些。就我自己而言在随机测试阶段我可以挣脱束缚，随心的设想一些配置，再搭配上特定的一些用户行为。而在做随机测试的时候，也不是完全没有章法的胡乱点击一通。我经常会提前设想一些情况，在纸上列出来，再思考并挑选一些出来。但是往往在操作的过程中我的步骤就突然间改变了，我会操作完某一步后，突然间联想到另外的一些情况。然后转而去尝试。结果大多数时候都会有出乎意料的发现。
我总结了一下我自己，我本身的性格非常急，所以在日常工作中，我可能有时候容易思想不够集中。尤其是在那种特别长的会议里，我经常会在听到发言人的某些发言后瞬间蹦出一长串的疑问，这时候怎么办呢？
以前的我可能会很激动地就直接发问了。现在的我慢慢地意识到自己的问题，于是我学着将自己的思绪拉回，不要继续在自己的疑问里越走越远。我会强迫自己继续听发言人的后续发言，结果往往会发现会议结束的时候我的很多问题都不是问题了或者并不那么重要了。说了这么多我其实就是想分享一下我自己关于专注与发散的经验。我相信很多QA在专注力与发散这块都有一些很好的见解，欢迎大家分享探讨～
小结
卖了这么多关子，到了我该回答问题的时候了。这么多年我也不是没有动摇过，但是每一次动摇的时候我都进行了深入地思考。我尝试自问自答，最终我还是坚守在QA这个岗位。对于我为什么坚守，我想首先肯定是非常喜欢的。其次我觉得是因为适合，这得归功于我超强的好奇心以及发散的思维方式。当然也有性格相关的因素在里面。另外，作为一名QA，我们必须要有很强的责任心与沟通协作能力。
