测试团队的真实故事：从负面测试中排除负面因素
测试团队的真实故事：从负面测试中排除负面因素
误解通常会导致测试人员对软件“破解”的评价不高。开发人员和利益相关者可能会称其为负面测试，但结果却是更好的产品，而且都是积极的。
测试人员是新软件的第一批用户，它们对于使其可用至关重要。最后，每个人都有提供最佳产品的相同目标，因此让测试人员探索和发现新的错误始终是一件好事——发现的错误越多越好！在软件开发生命周期的开始阶段，通过鼓励探索性测试，可以更早、更轻松地修复漏洞，从而更早地发现错误。
当然，我发现的许多错误都与功能要求无关。性能问题是一个常见的例子。在大多数情况下，需求并没有说明需要多长时间，但是测试人员可以很容易地判断出什么时候不合适。如果我不耐烦地等待我们的软件，那么我们的客户也会。而且，当我们仍然可以修复它时，您是否愿意从我这里而不是从客户那里听到？
我们到底在测试什么？
早上8点30分，我们的产品经理走进我们的办公室，问：“项目负责人在哪里？”
首席开发人员说：“他出去了。需要我们怎样帮助你？”
“将数据库从MySQL迁移到MariaDB的用户故事的状态如何？”
首席开发人员回答：“我们之所以延后，是因为MySQL主表的某些关键元素不容易迁移到MariaDB。”
产品经理的语气立即变得更加清晰。“延后多少？几天，几周？”
我们的主要开发人员如实回答：“至少还有四天。”
房间里寂静无声。最后，产品经理说：“你能告诉项目负责人来我办公室吗？我需要和他谈谈。”他转身离开。
显然，产品经理对我们的用户故事进度不满意，并且所有开发人员和测试人员现在都感到压力很大。
在当天晚些时候的计划会议中，团队考虑了所有可能的路径：幸福的道路、不愉快的道路以及边缘和边缘情况。之后，我坐在小隔间中测试用户故事，尽管大多数任务仍在进行中，但我还是决定进行一些负面测试。在好奇心的驱使下，我开始导航到与数据库更改无关的区域，并且发现了严重的缺陷。
此时，项目负责人从产品经理的办公室回来，他看上去并不高兴。我转到项目负责人并通知他，在执行负面测试时，我在登录页面中发现了一个严重错误。
“你正在测试用户故事以外的东西吗？”他回答。“请不要尝试使用有趣的负面内容来破坏应用程序。我们正在赶时间，我认为普通用户不会遇到该缺陷。”
“好吧，”我说，“我将提交错误并继续执行之前的进度。”
不过，我私下里想知道：“普通用户”是谁或什么？
测试真实世界
仍然存在软件质量工程师破坏产品的误解。测试人员自己会惊呼：“看吗？我破解了该软件——当您单击此处时，它就崩溃了！”
当然，他们并没有真正做到这一点。软件不会损坏；它只是按照它的设计和编码来做，不管是好是坏。
说到设计，另一个普遍的神话是，所有错误都是编码错误和编程错误，而实际上，大多数错误是在需求和设计期间引入的。软件质量工程师对系统进行调查，查看系统的功能，然后发现并报告软件损坏的位置和方式，并确定系统何时在负载或压力下出现故障，或者像任何用户一样在周围闲逛。
因此，测试人员有义务超越积极的幸福之路，并揭露不太幸福的事物。
积极的测试是在正确的时间单击正确的位置。用户不太可能只会这样做。用户在需要时单击所需的内容。我们无法使用户一直以相同的方式做相同的事情，因此我们不能依靠我们的自动化测试来涵盖人机交互。
这就是为什么我不喜欢负面测试一词的原因——它不是负面的！
我更喜欢“真实世界的测试”。每个用户都以独特的方式使用产品，我们不能将用户彼此进行比较，也不能期望他们使用相同的路径浏览应用程序。用户不会走幸福的路。用户不遵循说明，或者说实话，通常甚至都不阅读文档。用户习惯挑战产品。
因此，作为测试人员，对我们挑战产品也至关重要。我们必须改变测试方法，以找出产品的响应方式。出色的测试不仅限于表明产品可以产生预期的结果；这意味着在用户做某人没有预料到的事情时了解产品的功能。
作为软件质量工程师，我们的职责是像真实用户一样行动和思考。我们需要在测试计划之外进行测试并关闭脚本。开发人员和利益相关者可能会称其为负面测试，但结果却是更好的产品，而且都是积极的。
改变对话
任何软件都有潜在的风险，无法按预期运行，因此至关重要的一点是，至少要验证有人登录时该软件不会崩溃。当我在登录页面中发现错误时，我没有进行负面测试；我正在研究软件。
因此，我应该以积极的方式进行交流。我们的言语对他人如何看待和理解我们的工作有很大影响。
当我告诉项目负责人我在进行负面测试时发现了一个错误时，他的反应令人无法接受是可以理解的。如果我反而说：“当我测试登录页面时，我发现了一个严重的错误”他的反应可能是：“去存档该错误，稍后我们将对其进行研究。”
因此，我认为我们应该停止使用正面或负面的术语。相反，我们来谈谈“发现”和“调查”。它不那么混乱、更明确，并且避免了开发人员和管理人员说诸如“哦，您只是消极”之类的令人畏惧的潜在问题。
转移词汇帮助我改善了与利益相关者和开发人员之间的沟通。我可以看到方程式的另一个角度，并且我能够与开发人员进行交流，而不会遇到任何磨擦。现在，团队将我的工作视为积极改进产品，而不是消极地尝试破坏软件。
尝试将词汇表从“积极”和“否定”改为解释性更好的动词来解释您的探索。团队将更容易接受对话，他们甚至可能更珍视您的工作。
