目录内容
启动任务时，需要证明其合理性。 您必须说服开发人员：
- 这确实是一个错误；
- 它需要修复；
- 必须完全按照我们所说的进行修复。
有时您会阅读错误（尤其是初学者的错误）并问自己：
-为什么这是一个错误？
例如，它说：“下载报告，我们得到57.6。 它应该是-57.9“。
编写基本原理将解决问题：
- 同事们以“为什么这是个错误？”的问题分散了注意力，使它脱离了上下文。
- 一个月后，您自己就忘记了，但是实际上，为什么它是一个错误...
另请参阅：
为什么需要在错误中进行辩护 -更详细地说明为什么通常需要辩护。数以百计的初学者（学生）通过了我。 正是在他们的任务上，我才开始问“为什么这是一个错误？”……问你们，然后您得到“是的，很明显！”。 好吧，以某种方式不是很=））
通过一堆任务和问题，“为什么？” 反应的模式开始出现。 我强调了好的和坏的模式。 我想谈谈他们。
本文适用于：
- 初级测试人员 -学习如何正确解释您的观点；
- 测试经理 -链接到他们的Padawans，然后引用反模式，无需进一步说明。
1.反模式：基本原理不佳
1.1。 明显地
测试人员为什么根本不写错误的基本原理？ 是的，因为对他们来说似乎很明显。 他们将自己的想法投射到每个人身上。 对我来说很明显=对每个人都显而易见为什么要写东西？
但实际上并非如此，因为每个人都处于某种上下文中。 对您而言显而易见的事实根本不是对他人显而易见的事实。
让我们看一些简单的例子。 读一下我将在下面写的字-当您阅读该字时，您会怎么想？ 我想到了什么关联？
锁
门锁还是巨大的石头堡垒？
婚姻
婚礼还是iPhone坏了？
...
是的，这些是谐音。 但是它们非常清楚地显示出问题“很明显”。 对您来说，这座城堡显然是一座城堡，对我而言，那显然是一座城堡。
如果您写了一个错误：
结果
57.6
预期结果
显然应该有57.9
那没有回答我的问题“为什么？” “显而易见”是什么意思？ 请向我解释。 这对我来说并不明显，否则我不会再问了。 但是作者很明显，他认为每个人也是如此。
如果我们谈论初学者的经验，那么我的一位学生最先提出了这个想法：
“直到我读完其他学生的错误，我才完全不知道为什么要对错误进行辩护”
您可以在很长一段时间内告诉所有人，这对每个不同的人都是“显而易见的”，而我不在您的上下文中，还有更多……但是任务的作者将认为他们只是发现他的错，其他人都不理解，但他做得很好！
刚读完别人的错误，您就会开始思考：“嗯，他为什么这么认为？ 我有不同的想法。” 正是在这样的理解下，您的“显而易见”并非对所有人都显而易见。
当我进入Bug跟踪器并从学生那里看到这样的Bug时：“我们输入名称Sharipat，它被定义为男性。 而且应该像一个女人！” 为什么要像女人？ 我看着这个名字-Sharipat和Sharipat，看起来像个男人。 我问：
“你为什么决定呢？” 为什么是女性？
-是的，因为我老婆这么称呼！
至少这已经向我解释了他为什么开始这项任务。 在测试应用程序时，我们首先尝试简单的数据，这是我们所知道的。 我们尝试我们的名字，我们妻子，兄弟，姐妹的名字...
他试图输入妻子的名字并发现了一个错误。 而且，如果他甚至在预期的结果中写道：“性别是女性，这是一个女性名字-我叫这个名字”，那么至少有一个问题：“为什么您甚至开始这项任务？”就消失了。
当然，这样的理由是不够的。 Google是“不寻常的名字”，因为我们甚至禁止我们在儿子的床头柜上命名，但是否值得将此词作为正确的男性名字呢？
因此，在这里有必要用google来搜索本地名称（俄语名称的问题）的一般名称是什么？ 哈萨克人？ 乌克兰语？ 但是系统应该能够处理它们吗？ 依此类推。 也许根本不是一个bug ...
但是，“我妻子的名字是如此”至少可以使作者向我们介绍他的情况，并解释为什么他决定开始这项工作。
请记住，证据可以由上下文决定。 您已经仔细研究了系统的大型模块，您已全面了解所有内容。 因此，“这片芯片应该可以正常工作”对您来说是完全显而易见的。 但是，如果您在一两个月后返回该任务，您将已经在另一个模块上工作，并且记住为什么会如此会更加困难。
甚至最笨的铅笔也比最清晰的Internet存储器更清晰
当您启动错误时，预期的结果对您来说显而易见，请停止思考：“我为什么这么认为？”。 并写下这个问题的答案。
1.2。 我向妈妈发誓！
当学生意识到“因为很明显”根本不写任何东西都不会失败时，他进入了愤怒，否认和对错误进行辩护的下一阶段，这就是“我发誓，妈妈！” 这是当我们只是说对了，而没有解释原因的时候。
也就是说，基本原理如下所示：
结果
57.6
预期结果
57.9因为非常正确
但是，这样的理由再也不能回答我的问题“但是为什么？”。 您为什么认为那是对的？ 我仍然不是旺旺或心灵感应者，也不知道你为什么认为这是对的。
实际上，这与“没有写任何东西，因为很明显”的情况并没有太大不同。 因此，我将其称为第二阶段-正是在这种情况下，事件通常会首先“明显”发展，然后“是，非常正确”发展。 让我们看一个学生生活中的例子：
彼得和印第安人
我们的系统可以按大小写更改名称。 一个学生检查彼得的名字。 你知道它的倾斜度吗？ 在主格中，它用字母E书写，在其他所有字母中都用E书写。“彼得，但彼得”。
因此，我进入了错误跟踪器并阅读了这样一个错误：“ Peter通过字母e来倾斜案例，但是应该通过e来倾斜。”
我问：
“你为什么这么认为？”
-好吧，很明显，通过E（第一阶段）
“你为什么认为这很明显？”
-但是，按照俄语规则是如此！
-根据什么规则？
-好吧，我应该运行和搜索俄语规则吗？ （第二阶段-好的，相信我）
-是的！ 是的，这正是您应该做的。 因为这将是该错误的理由。 因为也许您的开发人员是印度人，而您也是印度人。 而且您不了解俄语规则！ 因此，给他们一个链接，所有问题将立即消失。
当然，当您在拼写错误或逗号遗漏处输入错误时，无需走极端，并提供指向字典的链接。 然而，彼得是一个不平凡的例子，这是规则的例外。 它总是那样工作，但是对于Peter则有所不同。
因此，此处的链接将非常有用。 特别是如果开发人员问：“真的吗？” 您可以指责他愚蠢和文盲并破坏恋爱关系。 您可以提供一个链接，轻轻地确认您的观点。
但是好吧，让我们再举一个例子，不是关于俄罗斯语言的规则，这些规则“是如此明显”。
Email.rf
我的学生非常喜欢这个任务（几乎每个流都完成了它）：
-我正在尝试向email.ru注册，但不能。 这是一个错误！
-为什么？
-为什么呢？ 我们生活在俄罗斯，每个人都有这样的电子邮件！
我在DUMP会议上告诉了这个案例，并且我有一个完整的听众室。 我要求举起收到这类电子邮件的人的双手。 在200个人中，有3个人举手。
我们生活在俄罗斯的事实并不意味着每个人都有这样的电子邮件。 好，是的，是的……还有驯服的熊和嵌套娃娃……
这里没有因果关系，很难放弃你的想法。 毕竟，在这里，我发现了一个错误！ 这怎么可能不是错误？ 好酷 俄罗斯，显然！ 不，不是很明显吗？ 好吧，俄罗斯，还是一样。当然有很多。
这个理由更像是“我懒得去Google，寻找事实。 相信这个词。” 当我们没有事实和证据时，就有一种希望掩盖其理由并写上“可能，也许，肯定地……”的愿望。
但是这些都是停用词！ 如果您希望编写它们，那么您就没有真实的事实。 因此，您只需考虑一下。 为什么我们需要根据测试人员的想象力来完成一项任务？ 证明你的理论！
如果没有事实呢？ 然后，该任务甚至都不值得开始。 是的，很难拒绝“您自己的本地”错误。 但这也必须能够做到。
Email.ru-事实
可能是什么事实？
首先，我们可以为一些需要在domain.rf中注册的政府客户建立我们的网站。 企业标准，他们别无选择。
或者我们确实有很多这样的客户，这可以从统计数据中看出来。 例如，“试图通过这样的域进行注册”日志中存在很多错误。 然后也许值得进行此功能。 为了不失去潜在客户。
基于这些事实，PM（项目经理）将决定我们是否要执行任务。 如果我们愿意，那么什么时候。 或者他可能会说：“嗯，有错误，而且，注册总数不到1％，我们不会这样做”
而不是抽象的“是的，这样的人肯定存在！” 给出事实。
而在设置任务时，为什么要使用原理5。 当您写下预期结果时，问自己：“我为什么要这样？” 第一个答案将是“这很明显”，但再次提出问题“为什么？”。 如果您发现没有数据，在您看来就这样-查找事实或与同事讨论情况。
1.3。 兔子被冒犯了
如果没有事实，但是您不想拒绝该错误，则学生会进入愤怒，否认和错误的正当化的下一阶段……情绪压力：
我尝试使用名称Cthulhu注册，但系统没有注册。 应该给，否则...我被冒犯了，离开了，你！ 失去客户！
当然每个人都和我一样，因此您失去了所有客户，他们还提起了侮辱性诉讼，并抢走了所有钱！
和其他汽车...
当然，当我个人不喜欢的东西，这是非常生气不理我的问题。 这是什么意思“普通人不使用该名称注册？” 我疯了吗？ 就像我想要的那样，你怎么能禁止我做某事？！
然后投影打开-如果我不喜欢它，那么其他用户将不喜欢它！ 如果不是全部，那么至少很多。 因此，这绝对是一个错误，需要修复。 好吧，或者如果我们在谈论学生，至少是在培训框架内出发。
但是，冒犯的用户是有史以来最糟糕的理由。 因为它们可以证明任何废话是合理的：
- 主体上没有猫吗？ 好吧，就是这样！ 我得罪了，走了！ 还有你！ 失去客户！
- 我注册了，但没有得到报酬？ 我被冒犯了，离开了……而你！ 好吧，你明白了！
任何事情都可能发生并冒犯我。 该按钮为绿色，但我想要一个红色，该系统没有向我提供披萨作为礼物。作为用户，我可以冒犯任何东西。 但是谁在乎呢？ 一样，您不会满意，怨恨是不可避免的。 威胁通常是最后一件事。
一切始于一名学生，他们刚刚说出了这句话：
-啊，您不想通过俄罗斯联邦注册吗？ 作为我尝试注册的用户，我看到了这种公然的情况，然后就消失了！ 还有你！ 失去客户！
然后我的朋友说，这种讲话与“邦尼被冒犯”非常相似。 我不知道她从哪里得到这样的比喻，但每个人都喜欢。
学生意识到他很兴奋。 去寻求理由而没有情感。 并且我们得到了反模式名称。
记住一个简单的规则-
错误中不应有情绪！情绪是一种过时的现象。 现在，您正以义愤激昂，并想用恶意评论来表达它，例如“只有白痴才能编写这样的代码”。 但是，请记住任何情况下，当您旁边的孩子反复无常时，都会因未购置的玩具或冰淇淋而大发脾气。 作为外部观察者，您喜欢看这个场景吗？ 但是您在错误跟踪器中的歇斯底里看起来完全一样！
因此，如果您确实想要，请口头说出所有内容。 与开发人员讨论在吸烟室中的任务，大力捍卫自己的立场。 但是，一旦进入计算机，我们便消除了情绪，只写了事实。 没有“如果是，如果”，没有“和你！ 失去了客户！”
请记住，他们在一两年或三年后返回到任务。 然后，即使您也会凝视自己的发脾气。 毕竟，不再有过去的情感，这看起来很荒谬。 因此，口头上最大的情绪-在吸烟室中！ 而没有它们的某种方式的错误。
而且有理由不写关于大罪兔子的事。 有时，对任务的这种辩护变得荒谬：
学生在用户的报价中发现了一个错字。 优先考虑错误。 当被要求澄清优先事项时，他非常愤慨：
-系统欺骗了我，我不能相信她！
他可能担心这个问题会变成“根本不是bug”，因此他开始捍卫自己的bug。 但是没有人不介意这是一个错误。 但是为什么关键呢？ 谁在阅读优惠？
-我看了！ 因此，我发现系统很糟糕，如果那里有错字，那该怎么办？ 以及现在如何相信呢？
但是“我读”≠“每个人都读”。 然后，学生本人承认，他没有认真阅读安装程序时滑入我们的每份许可协议。 因此，与报价相同。 虽然一切都很好，但他们没有阅读。 如果有些不愉快的事情，请遵守规则。
但是，“该系统欺骗了我，我现在简直不敢相信”，因为该文本的第十页上有一个错字，很少有人读过……好吧……不要把它写在一个错误中，不要告诉您的RM。
因此，我们从错误中消除了情绪。 那我们可以离开那里吗？ 当然，事实！
与其说“情绪肯定会得罪，他们会离开，而您会失去客户”，不如说：
-收集统计数据；
-估计人工成本；
-计算投资回报率；
-采访用户；
-将产品与竞争对手进行比较；
而不是像歇斯底里的松鼠一样，您将成为制作周到错误的凉爽测试员！
2.合理的证明模式
如何正确证明错误？ 需要在预期结果中写些什么，以便在编写时修复错误？ 他们没有问十遍“为什么这么对”？
上面讨论了三种反模式，让我们讨论三种用于证明错误的良好模式。
2.1。 专利链接
可能是：
- 链接到需求
- 需求本身（word文件，存在...）
- 互联网链接
- 预计投资回报率
- 客户来信
- 统计资料
链接到需求最简单的错误是当存在TK并且系统无法按此处所述运行时。
因此，我们在预期结果中写道：“ 57.9，因为在工作说明中是如此。” 嗯，嗯...等等。 听起来像“我向妈妈发誓” ...
是的，用这种措辞听起来像那样。 因此，请通过链接确认您的单词。 否则，开发人员将读取该错误，并且他需要：
- 意识到涉及哪种传统知识；
- 寻找传统知识本身；
- 查找有问题的特定地点；
- 掌握...
仅保留最后一个项目难道不是很容易吗？ 毕竟，开发人员可以从事10个不同的项目，其文档分布在10个不同的地方。 他将需要5到10分钟的时间来搜索TK，为您添加链接只需一秒钟。 现在，您正在根据TK进行测试，这意味着它是开放的并且在您的眼前。 复制链接并粘贴！
尊重同事的时间，他们将感谢您。
要求自己如果要求不是存储在融合或其他云系统中，而是存储在常规Word中，请附加要测试的文档。
您可能正在测试过时的需求。 而且，如果您附加了要检查的直接Word文件，那么分析师可以看到它并说：“哦，等等，我们已经更改了10次，我忘了上传。 等等！”
如果您不这样做，那么请花三个小时与开发人员进行对决，他们会说：“但是我有另外一个！”。 您将运行，观察他的要求，然后观察您的要求，然后寻找分析师来澄清谁是正确的...
因此，您立即提出了要求，开发人员看起来说“有些东西是垃圾”，从而重定向了分析。 分析师写下了它们，当他打开您的嘴时，他将立即了解他是否过时。 节省时间！
互联网链接我们记得，需求远非总是如此。 也许代替他们……链接到Internet！ 是的，为什么不呢？
如果我们回想一下示例“ Peter，Peter”，那么即使我们在系统中有要求，也不太可能说“系统根据俄语规则运行”，并且所有俄语规则都被列出。 当然，没有人会这样写。 事实证明，如果您想参考俄语的规则，就必须去搜索谷歌。
或者，如果您以Sharipat为例。 再说一次，您从哪儿得知这是一个普通的女性名字？ 我们用Google搜索各种哈萨克语和其他名称，找到Sharipat，找到其他相似的名称，并提供指向此页面的链接。
在这里，即使开发人员不同意您的看法，他也可以说：“看，您给了该站点一个链接，但这是一种黄色新闻，他们总是在写垃圾。” 但是，如果您未提供链接，则开发人员将不得不自己搜索Google，自己搜索各种网站，然后他才知道您可能已经攻击了一些虚假信息。
为节省时间，请立即提供指向Internet的链接。
是的，在这里您需要了解并非每个链接都是有用且合理的，但这至少将表明您为什么认为这确实是一个错误。这不是我对你的“妈妈起誓”，而是有道理的！客户来信理由可能是发送给客户来信。我们甚至有一个单独的字段，业务理由，我们在其中写下哪个客户要求此功能。然后，当我们阅读我们的错误时，我们立即看到：-是的，业务案例是空的。这意味着我们自己已经发现了这个问题，并认为需要解决。或：-是的，这样的客户在2015年8月1日抱怨该问题而且，如果我们需要与该客户澄清到底什么不适合他，那么我们可以轻松找到这封信，因为我们掌握了所有信息（调用该信的人，时间，名称）。知道了这些信息后，我将在5秒钟内在Outlook中找到一封信。如果此信息不存在，那么我将不得不转至Outlook并在10个不同的父亲中进行搜索-哪个客户提出要求，以及哪个信件？此外，如果我们看到几个不同的客户都要求使用此功能，那么它将立即提高优先级。由于我们了解：-是的，那么这是客户1的投诉，几周/几个月之后，客户又投诉了。嗯，但是肯定有很多其他客户也在遭受苦难，却保持沉默。哭，刺，但继续吃仙人掌。毕竟，并非所有人都会写信给我们并报告问题...
因此，投诉越多，优先级越高。由于我们知道这是一个真正的用户抱怨，所以他们确实有这样的问题。而且即使六个月或一年后我们回到该错误中，也要感谢随附的信函或至少指向该错误的链接，始终可以提高该任务的历史记录。投资回报率我们可以尝试计算投资回报率-投资回报率。我们真的需要制作此功能或解决此错误吗？这会带来适当的效果吗？进行半小时的开发进行较小的编辑是一回事，这将帮助数百个用户。完全不同-由于一位用户的歇斯底里，需要两周的时间来重做该系统的工作，这适用于其他所有人。如果我们计算了投资回报率，并且发现游戏值得进行，则将计算结果放入任务中。但是有时经过计算，结果表明您不需要执行任务。这是正常的！因此，我们节省了小组讨论不必要功能的时间。这就是我们考虑基本原理的原因-因为有时似乎是“啊，什么是错误，什么是错误！”，然后您开始考虑基本原理...并且您知道，这种垃圾，而不是错误，不值得启动...例如，我们开始使用移动应用程序，并且为测试人员提供了一个调试面板，看起来像这样：
哇，哇！有一点蓝色，有一点红色，文本不完全可见，字体散落着。这怎么在我面前没有注意到？紧急清关，需要重构！
如何证明？“您的意思是，如果用户这样做，那么他将立即被冒犯并离开。”停下 . -. , [2]. . , , !
… , ? . , , . ? !
, . . . ? ? , , .
— , !
统计信息收集统计信息并投入任务：-日志中的错误数；-技术支持方面的投诉数量；-按钮的点击次数；-在下订单阶段离开的用户数量（关闭了标签）；-...也就是说，如果您认为在在线商店下订单的标准格式是“不好的”并且需要改进，请加以辩解。为什么不好？为了输入地址，您需要知道索引并填写10个必填字段？是真的很糟糕还是只会让您烦恼？请记住，开发人员可能看不到其软件中的“显而易见”。毕竟，他们开发了它，对其进行了测试……他们每天不断地看到它100次，它们已经习惯了该界面。因此，即使确实过时，您也需要事实。而且事实很容易收集-我们要求您进行统计以查看用户何时离开页面。如果他将比萨饼加到篮子里，然后开始填充田野，经过5-7次吐口水后离开，这不是很酷。而且，如果三分之一的人都那样做-绝对值得改进！如果您回想起email.rf，则可以查看日志-是否存在诸如“尝试注册此类电子邮件被拒绝”之类的错误？也许它们根本不存在，但我们已经提出了许多冒犯性的用户，因此，该网站实际上损失了数百万。
为什么统计数据比情绪更好？因为我们，IT专业人员和普通用户是两个不同的世界。对我们来说方便的是他们的不便。反之亦然。
假设我们做会计软件。在我们看来：“傅，没有人使用鼠标，我们必须确保一切都可以从命令行运行，这样就不必触摸鼠标了！”我们在此功能上花费了大量时间，但实际用户根本不使用它。因为他们需要用鼠标来拾取，才能按一下大按钮。但是对于程序员来说方便的地方，他们通常不在乎，因为对他们来说便利性完全不同。而且，如果您想告诉所有人用户的需求，请先研究可用性测试，然后说出兔子是否受到冒犯。在我们的系统中，我们收集匿名统计信息，使用哪些功能，不使用哪些功能。Web表单上有太多的过滤器难以维护。他们需要吗？您不仅可以取货，还值得检查。
因此，统计数据通常非常令人惊讶。我们以为根本没有使用该过滤器，但实际上它每小时都会工作。另一方面，他们寄予厚望，但没人需要他...
只有统计数据可以诚实地说明问题的存在。如果没有统计数据，那只会是味道。每个人都有不同的口味。测试人员需要红色按钮，开发人员需要绿色按钮，而设计师则需要蓝色按钮。因此，寻找事实并给他们一个pruflink！
2.2。 均匀度
如果没有pruflink，我们可以参考系统中的统一性。因为如果系统始终以这种方式工作，然后突然以不同的方式工作-这很可能就是该错误的原因。例如，如果我们的系统像puntoswitcher一样工作（这是当我用俄语打印时，忘记切换布局，而系统自己进行切换）。我可以输入“ Olga”，也可以输入“ Jkmuf”，系统会将第二个选项变成第一个选项。这在各种政府申请中都会发生。有时他们自己也遵循相同的原则。您必须像在护照上一样清楚地注册。由于我们居住在俄罗斯，所以注册使用俄语，因此我们将更正英文字母。显然，您忘了更改布局，伙计！杰科夫→奥尔加
好的，但是如果我尝试输入名称“ Julia”怎么办？它以字母U开头，并且该字母不对应于俄语字母，而是对应于特殊字符：>→Yu
这是完全不同的等效类！也就是说，如果我们了解该系统像puntoswitcher一样工作，那么我们至少有两个等效类：存在对应于拉丁字母的俄语字母，以及对应于特殊字符的字母。这些是完全不同的类，必须对其进行检查！也许当我们打印一个特殊字符时，系统无法识别它。然后我们开始一个错误-输入>符号，我希望系统将其转换为字母U，但是什么也没有发生。我为什么要这样？因为系统已经这样工作了，因为如果我输入Jkmuf，系统就会知道它是Olga。我们证明该系统已经可以这种方式工作，这是一个很好的理由。我们不会说“我由母亲发誓，她是那样工作的”，我们在奥尔加身上证明了这一点。
2.3。 问题，或＃生活痛苦
告诉我们一些实际的用户问题。因为我们是测试人员。我们的任务是粉碎和破坏，在短字段中输入“战争与和平”，在两个浏览器选项卡中编辑一个条目，另一个在另一个条目中进行编辑。即使某些事情对我们不起作用，也不意味着用户会做同样的事情。有时由于“是的，没有人这样做”而无法修复错误。这是正常的。为什么要浪费能源和资源解决永远不会出现的问题？对于可用性问题尤其如此。我们记得，对于IT专业人员而言，简单的用户不方便。反之亦然！事实证明，如果我们只写“嗯，这很不舒服...”-这是一个不充分的理由，您永远都不知道什么不舒服，其他都适合。但是，如果我们从用户那里收集反馈，并附上他们向我们投诉的信件，那么这立即表明确实存在此问题。这已经增加了它的优先级。真实客户的问题总是比仅仅来自测试人员的负面测试更好。
这并不意味着测试人员永远不会因问题而得到纠正。如果您有问题，也要投诉！也许开发人员可以在5分钟内为您提供帮助，但他只是不知道情况如何。测试新功能时，我会进行自动测试。 测试框架已经存在很长时间了，我们已经习惯了。 测试彼此相似，因此复制粘贴-毕竟，我们通常会更改一个参数，其余参数保持不变。 这就是“ 1次测试= 1次测试”的原理，因此测试下降可立即表明原因。
现在，我需要将参数从自动测试复制到自动测试。 而且我必须将它们从第一次测试中挖掘出来，直到第二，第三，第四，第五，第十个……在此复制粘贴中，我只需要在一行中更改1值，否则，一切都会变得很糟糕。一个错误。
当然，当我执行复制粘贴操作时，我至少在某个地方弄错了…结果，我编写了30个测试，一次运行它们，而NPE一切都失败了。 我坐着，挠头思考，“该死，我在哪里错了？”
我整天都在整理，寻找错误，运行自动测试……我试图找到一个错误或一个我搞砸的地方。 结果，我找到了，然后在下一次集会上我抱怨：
“我昨天整天写了这些自动测试，因为我在第五次测试中犯了一个错误，然后试图长时间了解跌倒的原因。” 哦，这个复制粘贴！
然后开发人员说：
“是的，她会来找我；我将在半小时内为您重构所有内容并解决此问题。”
所以有可能吗？
请不要害怕！ 也许您正在受苦，而开发人员甚至都不知道。 也许他可以在此时此刻快速解决您的问题。 也许无法解决，但建议一种解决方法。
当然，如果问题是一次性问题，或者修复时间太长，则优化任务将移至下一个版本或以后的版本。 但是至少值得讨论“如何改进”并设定任务。 毕竟，如果没有任务，没有人会做任何事情。
存在各种情况的问题：
-客户问题；
-真实用户的问题；
-测试人员的问题；
-团队内部的问题；
有些优先级更高，有些则更少。 但是，如果我们描述真实的情况和真实的问题，那么与“显然，每个人都会变得更好”相比，这样的任务有更多的纠正机会。
是的，您需要了解，即使我们描述了它对真实用户的不利影响，也仍然不能保证我们将修复该错误，但这就是生命。 无论如何，如果我们至少描述了问题，那么至少会清楚为什么我们要设置此任务。 即使我们一个月后回到他身边，也要两三个月。 我们将始终看到为什么我们认为用户使用它不好并且不舒服。
3.不需要理由时
突然吧 =）
但是，反模式“显然”有例外。 如果系统是以下情况，我们真的不需要写理由：
尤其是在生产中发生这种情况时。 如果是我们的网站，则没有任何理由要证明其合理性，您必须战胜锣鼓，奔向开发人员“紧急修复它！” 完全没有错误是可能的。 而且，您可以简单地出现一个“错误500”，就足够了。
不要从根本上弄清基本原理，因为“这始终是必要的”。 为了文字，写“系统不应该倒下”是文字。
但是！ 您肯定需要写出预期的结果。 即使您觉得很明显，也请写下来，它不会让您失望。
步骤
打开example.com网站
结果
错误500
预期结果
主页已打开
这里的一切似乎都很简单-主菜单没有打开，但是应该打开。 但是还有更复杂的例子。
例如，开发人员从TK中创建了一个公式，并且某处被零除。 如果您只写“应该没有错误，报告已加载”，那么开发人员仍会向您询问“应如何打开？ 除以零！”
您需要考虑一下，并写上“我希望报告会根据公式以这样的数值打开”-当您认为应该存在的内容时，您自己可以在TOR中找到关节。 然后与分析人员一起检查如何正确。
因此，即使没有正当理由，也至少会有预期的结果。 请记住，这是规则的例外。 系统不应掉落并冻结。 但是，此类错误很少见，在其他情况下应说明理由。
4.总结
我们讨论了3种反模式。 愤怒，拒绝和证明错误的三个阶段：
- 显然 -对我们来说我们显然没有理由。 然后我们得到“哦，我忘了我为什么要这么做”……这仅对您，仅在此刻和现在才可见。 六个月后，您自己会忘记原因。 解释有多愚蠢，有什么样的证据。
- 我由妈妈发誓，对！ -为什么发誓？ 由于某种原因，您认为这是正确的，所以请告诉我为什么。 例如，提供一个链接到需求。
- 兔子被冒犯了 -“哦，您没有在首页上添加一只猫吗？ 好吧，就是这样！ 我被冒犯了……而且走了！ 还有你！ 失去了顾客！” 但是给您带来不便的地方可能对其他人也很方便。 因此，消除情绪并提供事实。
相反，他们应该使用正确的理由：
- Pruflink -TK，Internet，他要求此功能的客户来信...
- 均匀性 -如果系统始终以这种方式工作，并且在一个地方有所不同，则值得修复！
- 问题 -描述您或用户（如果您正在与客户交流）出现的问题。 真正的问题总是比消极测试更好。
一定要写下为什么我们认为这确实是一个错误，以及为什么要像我们在此处所写的那样对其进行修复。 我们问自己“ 5个为什么”系列中的问题
-为什么我认为这很明显？
-为什么我认为那是对的？
-为什么我认为用户不满意？
我们提供Internet上的需求链接，表明一致性或谈论用户的实际问题。
一年之后，当您重新阅读能胜任执行的任务时，您仍然会对我说：“谢谢！” ツ