本文要点
你将了解思维工具相关内容；以廉价且有效的方式开发一种测试思维增强测试技能。
思维工具是从测试故事开发而来的，因此你自己很容易就能把它在要描述的场景中形象化地展示出来，并且易于学习和使用。
你将跃跃欲试对观察和反思进行改革创新
你将了解，如何开发自己的思维工具，作为测试人员、程序员、测试或项目经理等角色如何变得更具价值。
简介
许多测试人员经常缺失测试和交付高质量产品所必需的思维。有时，看起来它是质量意识的缺失。难怪有些测试人员只能发现明显的缺陷，这也是为什么尽管项目具备测试人员但质量与程序测没测过没多大关系。为增强高质量产品的成功发布，每个角色都应对其他角色有充分、适当的理解，如果一个项目缺乏了这种理解，那么不必要的挑战就会如暴风雨般不期而至。本篇文章，探讨的就是我是如何培养测试思维的，以及对增强我的测试技能有多么大的作用。
我的思考：我是什么类型的测试人员，我想要成为什么类型的测试人员？
我一开始只是个“明显缺陷的发现者”。好吧，作为测试人员的第一天，我的确仅仅就是这样的。我认为，许多测试已经都经历过或正在经历着这一阶段，他们看起来只能发现明显的缺陷。而其他测试人员可以在我已经测试过的程序中挖出重大缺陷，在这个时候的我，将这些人称之为“优秀的测试人员”。我常常问自己，“他们是如何找出这些缺陷的呢？”以及“为什么我和他们不一样？”
我最初安慰自己说，那是因为随着时间的积累他们有着更多的经验。我有希望变成他们。但没过多久，我发现某些没有经验的测试人员也能在我或其他测试人员已经测试过的程序中发现重大缺陷。还有一些有着多年经验的测试人员却只能发现“明显的缺陷”，就像我。所以我认识到，哦……嗯……好吧……这似乎不是经验的关系！
所以，我对自己说，可能是因为他们通过了某些认证。我也去过认证，然而并没有什么用。我记得这段时间我参加了一次面试，面试官问我某段具体的程序将如何测试。我开始告诉他，我将编写测试计划和测试用例，即用我在认证中学到的方式。他对我说，“……你知道吗，我不想要像你这样的测试人员！我想要的测试人员是在测试之前不必写长长的测试计划，只写一行测试用例就能测试。”这次面试使我认识到，认证并没有教我太多有用的东西。
然后，我想，可能“优秀的测试人员”读过许多关于测试的书籍。所以，我开始读书。事实证明，这真的非常有用，但速度却不尽如人意。
我还发现，“优秀的测试人员”在项目中会得到更多的重视。测试负责人通常会把更关键、更重要的功能分配给他们，与此同时，把不怎么重要、不怎么关键的特性或任务分配给“明显缺陷的发现者”。
作为一名“明显缺陷的发现者”，一名把认证作为工具的测试人员，我的感觉很糟糕。我渴望成为一名有价值的测试人员，能帮助提供更重要的信息，从而帮助提升产品的质量。
我经常受一种想法的打击，我不时地问自己，如何能把愿望变成现实，“为什么这些我称之为‘优秀测试人员’的测试人员能看到和找到我看不到和找不到的东西？”。如果我能找出这些来，很可能就会知道什么令其变得不同和如何成长了。所以，要着手寻找前进的道路了！
改变我测试方式的探索：测试人员的思维和思维工具！
思维工具
就像我一直在思考什么使其变得不同一样，应该在周围发生的事中学到什么也一直萦绕在我的心头。所以，当我或团队中的其他人发现重要缺陷时，我开始去观察、分析和反思：我或他们是如何找到它们的？那时我或他们的思考过程是什么？
我的反思把我的注意力引到了发现缺陷的测试故事上，以及日常测试和交流中遇到的项目中的不同角色。我发现：
我的思维对如何找到缺陷和什么是好的测试有着重要的作用
随着继续地观察、分析和反思，我得出的结论是，测试需要我：
在测试时保持灵活的思路
从不同的角度，用不同的眼光和不同的思维来看待不同的测试任务或功能
于是，每当面对我要测试的待测程序时，都需要各种思维或推理。
为了保持思维的灵活性，并帮助我从不同视角看待事物：
我把有助于找出缺陷或有助于项目交互的思维方式识别出来
我给这些思维方式贴上标签，把每个贴上标签的思维方式称之为一种思维工具
想个更容易记起来的名字或更容易与已识别的思维工具联系在一起的名字
我逐条列出从这些测试故事中学到的经验教训，将其称之为思维调整（Mindset Tweaks）
每当测试时，我都会按照思维调整去调整或应用我的思维，借助思维调整把每种思维工具用起来
举些思维工具的例子，它们是我从测试故事中识别和标记出来的，它们包括：
“用户”思维工具
“已经测试过了”思维工具
“懒惰的测试人员的”思维工具
“善于分析”思维工具
“批判性思维”思维工具
“好奇心”思维工具
“缺陷信念”思维工具
“传播者”思维工具
“信任，商业”思维工具
“团队领导”思维工具
“应对批评和遣责”思维工具
“应对困境”思维工具
呯！我给你说吧，更好更有效地测试这个宇宙引发了最初的大爆炸，而且还在快速成长！
所以，我自己想，这是令你不同的东西！缺少这些能力意味着只能看到明显的缺陷！难怪有些测试人员只能发现明显的缺陷，这也是为什么尽管项目具备测试人员但质量与程序测没测过没多大关系！
测试人员的思维：
作为这些经验的后续，我为测试人员的思维想出了一个定义。我是这样定义测试人员的思维，或者测试思维的：
一种推理方式，决定了测试人员、程序员或项目经理看待对待测程序测试态度、观点和心理状态
在对待测程序的讨论和研究中需要这种推理。这一条受到了测试的定义的启发，即：对待测程序进行讨论和研究，从而增加产品质量的相关信息。（James Bach）
定义测试人员、程序员或项目经理在涉及待测程序和其他相关事物（比如，测试活动、伙伴程序员、项目经理、团队成员等等）时如何采用他或她的思维或推理的一种行为
测试人员的思维需要：
测试人员始终回答这个问题，“涉及到待测程序及其相应事物时我想怎么做，从而有效地提供有价值的信息，帮助做出待测试程序质量相关的决策？”
程序员、测试主管和项目经理始终回答这个问题，“我想要如何支持测试，从而为高质量产品的开发和发布带来提升？”
思维工具：如何做使其有效？
为解释我是如何使用思维工具的，我将给出三个例子。
第一个例子是“用户”思维工具：
测试故事背景：在我是测试人员的初期，经常会出现这么一种情况，当我找到一个特定的缺陷时，程序员或软件团队主管会说，“用户不会这么用产品的！”曾经有一次，产品带着这么一个“用户不会这么用产品的”缺陷发布了，而这个缺陷一开始就在我们的测试报告里。你猜怎么样？经研究，我们发现用户实际上会以之前程序员已声称用户不会这么用产品的方式去用产品！
去相信用户将不会以我们预期之外的特定方式来使用产品，这简单就是谬论！而我们需要张开想象力的翅膀，想象用户使用产品的方式。基于这个测试故事，我标记了“用户”思维方式，并识别了以下在我测试时要使用的思维调整。它们在发现此类重要缺陷中发挥了巨大的作用。
思维调整（从经验教训中提取出来的）：
化身为用户，也就是说测试时把自己想象成用户（不论程序员还是测试人员）
用户将用五官来感受产品：他们是如何接触的，感受到了什么，接触、品尝、闻产品和听产品的声音时可能会有什么反应
人类有着天然的探索属性，所以用户会探索！
收集用户会如何使用待测程序的相关信息，以帮助你的推理
第二个例子是“已经测试过了”思维工具
测试故事背景：我经常遭遇的一种情况，说是这块程序已经测试过了，所以要做的就是快速检查一下。有一次，有个程序员同事告诉我一个功能里的函数已经测试过了，我不应该再操心再去测试它了。但为预防意外，我仍然决定简单地检查一下。令我惊讶的是，这个程序员所谓的已经测试过的函数根本不能用。
我当时遇到的挑战是，怎么告诉他我仍然去检查了他说不用测试的程序呢。好吧，我建立了一个测试场景，在当前的测试中包括对失败函数的使用，从而解决了这个问题。所以，我邀请他去实验和解释我所观察到的在众多测试中其中一个我所不能理解的行为，我希望他看一下。当他看到时，说“……但我之前测试过呀。”他继续说，“Vivien，你不会再相信我了。”
我看到他浑身透出的难堪，清楚需要缓和一下这样的局面。所以，我回应说，“一点也不，相信我，我信任你，而且我知道你总是在努力完成工作。然而，我清楚一点，那就是有缺陷是代码的本质。”（化解尴尬和信任思维在此都发挥了重要作用）
还有一次，我的一个程序员同事告诉一名测试人员不必测试就把一段程序合并到主分支上。按他的说法，他只是做了很小的改动，只是清理了一行无用的代码，那是之前的一行注释。但他不知道的是，在这个过程中他多删除了一行有用的代码。
那么，测试人员未经测试就合并了，之后就没人能使用这个软件的主分支了。调查期间，导致问题的原因被找出来了，就是他让测试人员合并的那段代码。
基于这些测试故事的经验教训，我命名它们为“已经测试过了”思维工具，测试时将采用以下思维调整：
思考调整：
考虑之前完成过的测试的质量
考虑“令测试人员或程序员感到压力的可能性”
我们看到了差异、推理差异以及程序员与测试人员拥有不同的专业知识
小心所谓的“微小的变更”，就没有“微小的变更”
第三个例子是“懒惰的测试人员”思维工具：
测试故事背景：以前我出席一次会议，我听到软件领导说：“……懒惰的测试人员发现了那些缺陷”。他继续说道：“有他们在项目上很不错，但也别太多呀。”这引起了我的注意。我记下了缺陷报告中的ID并找出了“懒惰的测试人员”是谁。
我发现那个被提到的人是我的一名测试同事，他经常找非常重要的缺陷。但他采用的方式是，在测试的过程中，会跑到咖啡机那边休息。在咖啡旁，他开小差与同事聊着天，似乎已经忘了他还在运行测试呢。当他回来时，发现一些反常的情况：发生错误了！他报告了这个错误，还附上了他开小差去找同事聊天了。因此，他得到的标签是：“懒惰的测试人员”。
分析这个测试故事，我研究懒惰后发现，比尔盖茨这样说过：“我永远都会用懒惰的测试人员去做困难的工作，因为我清楚，他永远都会找到轻松完成它的方法”。然后我自己这样想：
似乎懒惰的人有些价值，因此我把这个思维工具命名为“懒惰的测试人员的”思维工具
有些缺陷可能是我们永远都无法发现的，除非我们像懒惰的测试人员那么做测试
我不必变得懒惰，只是切换做事的思维！
所以，我想到以下思维调整，在我测试时会采用它们：
思维调整：
探索懒惰的测试人员所做的事情；他们探索软件的方式是勤奋的测试人员不会采用的！
对于测试领导来说：发掘团队中的人才：比如不要清退“懒惰的测试人员”
测试思维的定论：思维工具适用于每一个人！
作为我对团队内部交互的进一步观察结果，我发现某些行为并不停地问自己：
当所有测试人员得到的计划表是不可能完成的任务时，为什么应该由于没发现某些缺陷而责备他们？
为什么程序员被规定在他们的代码中发现多少缺陷，或者测试人员被规定要找出多少缺陷？
为什么在生产期间未找到缺陷，而期待测试的时候仅由测试人员过一遍检查表就找出来？
为什么待测程序不是“虫富五车”，测试人员的大脑和思维被局限于写测试用例，从而限制他们去推理所写测试用例范围之外的缺陷？
为什么产品的测试和质量被认为是测试人员或程序员的责任？
因为对测试相关的内容缺乏适当的理解，这些认知损害了我们的项目。
现在，让我们想像一条正在漏水的船，以及下图中描述的态度：
谁处于小船的那一边并不重要，如果船沉没了，每个人都会淹死。同样的，如果项目失败了，每个人都会受到影响，不仅仅是测试人员和程序员。
所以，来思考一下：
程序员说：我想要构建软件
测试人员说：我想要测试软件，并为改进质量提出意见
项目经理说：我想要为干系人交付可工作的软件
市场人员说：我想要销售有利润的软件
每个角色都有对测试人员的期待：他们应该找出软件中的所有缺陷。
但依我看来，要想测试成功和有效，首先需要每个角色的个人认识到：
测试依赖于他们的角色，而且他们的成功也依赖于测试。换句话说，测试不成功，他们也不会成功。
构建高质量的软件是每个人的责任，因此软件开发项目中的所有角色必须一起协作。
随时理解每个角色的心理以及什么是最重要的，这对于高质量软件的开发和发布来说是必要的。
与待测程序相关的每个人都需要具有一种思维，那就是理解每种角色以及他们的目标。
如果你同意以上观点，那么大概也会同意，与待测程序相关的每个人都需要测试思维以开发和发布高质量的软件！如果你同意这一点，你很可能会继续同意，思维工具适用于每一个人！
如果每个与产品开发相关的人都在测试思维上有合理的投入，充分地理解我们的工作对测试和最终产品的质量有怎样的影响，那么质量就不会是靠不住的了！
探索和开发你自己的思维工具
通常我们不会观察，或者有时观察，但没有反思观察结果，或者即使我们这么做了，很可能也未下结论或从反思中总结经验教训。测试故事到处都是，在每一天，在我们工作于软件开发项目的各个地方。如果我们去探索它们，那么它们会成为学习的良好来源。我通过观察、反思和针对反思结果调整推理，提出了这些思维工具的理念。
人们经常问我：我们如何牢记这些思维工具和思维调整呢？这个问题我实际上已经思考过了，我想的是，不需要死记硬背。因为思维工具来源于我们身边发生的测试故事，如果我们观察到这个过程，自然就会领会它们，甚至开发出我们自己的思维工具。因此，我建议的思维工具模型如下：
观察：
观察每天的任务中发生了什么
关注你或其他测试人员是如何发现缺陷的
学着诉说或记录团队中测试人员、程序员、测试主管和项目经理相互协作的测试故事
反思：
反思每一天的观察活动、找到的缺陷，看他们是如何在团队中的测试人员、程序员、测试主管和项目经理等等人的共同协作下找出来的。
行动/回应/调整
识别在测试故事中和在执行项目任务时觉得有用的推理或思维，给它们加上标签。
列出经验总结清单，提出思维调整。
随着执行项目任务，基于已识别的思维工具和思维调整调整推理
总结
如果我们敢于观察，并敢于反思观察结果，进一步敢于就反思结果采取行动，那么我们就敢于学习和成长！当我开始使用思维工具时，我就开始成长更擅长测试了。我成了更有价值的测试人员，在产品质量方面有了更强的话语权。除那些明显的缺陷之外，我看到了事情的差异并找到重大的缺陷。我的程序员同事喜欢问我的意见，看是我对要解决的问题有什么看法，或者我认为修复特定缺陷或问题的最佳解决方案是什么。他们认为薇薇安总能看到软件中会出错的那些东西。这，我认为，是因为他们认识到了我对软件有价值的推理。
我发现同事问我，我是如何发现特定缺陷的，因为有时他们感到困惑，什么会使人想到这么有价值的场景的。我的项目经理给我的公司反馈说：薇薇安是个“超级明星”测试人员。有一次，我们拜访一个客户，程序员把我介绍为“全世界最好的测试人员”（……尽管我觉得离成为最好的或超级明星测试人员还有非常远的距离，但我猜这是他们用这种方式来表达我的测试方式的价值）。还有一件有意思的事，在我实际使用思维工具的时候，我注意到它还影响了程序员的工作方式。他们也成长了，学习和改进了他们的测试思维。
