质量保证部门（QA）在软件中搜索错误。 各个公司的方法各不相同，但这通常是由熟悉该软件的员工完成的。 他们以各种方式使用它，并尝试查找开发人员遗漏的错误。
质量保证一词可以指流程本身，组织以及该组织内的单个测试人员。 通常，质量保证组织中的测试人员称为“ QA”。 在本文中，为了保持一致，我们将使用常见的缩写QA而不是更精确的“质量保证测试仪”。
不同的公司对产品的整体质量负有不同的质量检查责任。 有时，如果“质量保证”一词仅搜索错误并计算其数量，则并不完全适用于该部门。
以下是质量检查部门存在问题的人员：
消防水带
测试人员报告如此多的错误报告的速度如此之快，以至于开发团队将永远无法完成。
- 可以变异为警报者
- 与统计信息等项目经理结合使用会很危险
- 校正的可能性： 高
- 项目危险： 高
问题
如果发现错误，重要的是要做出清晰的报告，并立即将其分配给适当的开发人员。 但是，某些测试人员能够比开发团队对其进行修复的速度更快地发现错误。 因此，错误列表不断增加，并且永远都不可能关闭它们。
乍一看，产品质量似乎有问题，但并非总是如此。 与使用非常错误的程序的常规测试仪不同，消防水带生成大量具有一个或多个特征的报告：
- 他们的报告不够详尽，因此可以更快地报告更多错误。
- 许多错误是其他错误的重复，因为它们只是一个主要原因。
- 没有时间重现该错误，因为一次编写报告就足以看到该错误。
消防水带测试员经常出现在公司直接或间接的压力下：
您发现的错误越多，您的工作就越好 。 这就导致了这样一个事实，即质量保证测试人员会仔细监视错误的实际根本原因，并清楚，简明地报告这些错误，因此，它们不如在单位时间内发布最多报告次数的消防水带工作。
这样的测试人员的活动可能会引起项目恐慌，因为产品质量似乎很差，并且该项目现在已落后于计划。 他们对士气的影响可以是即时而戏剧性的：开发团队祈祷中断bug报告的流程。
解决方案
在固定消防水带之前，至关重要的是要准确地识别它，并且不要将其与有效的质量保证相混淆，而质量保证会与非常多虫的系统发生冲突。 最清楚的证据来自开发人员的抱怨：
- 大多数错误是重复的。
- 许多错误具有明显的根本原因，因此可以将它们报告为一个错误。
- 错误消息不包含详细信息。
为了解决这种情况，应说明消防水带没有诱因报告大量错误，其目的是提高系统质量并为开发人员提供帮助。 此后，产品质量应以相同（或更好）的速度提高，但不要惊慌。
检察官
质量检查（QA），每次发现错误后，它都会指责开发人员未测试其程序。
- 可以变异为警报者
- 与统计信息等项目经理结合使用会很危险
- 校正的可能性： 高
- 项目危险： 低
问题
从理论上讲，开发人员可以在将产品转移到质量检查部门之前发现并修复所有错误。 因此，一些测试人员将发现的每个错误视为开发人员未充分测试其工作的另一证明。 这种无可辩驳的论点使检察官可以更大声地表达对开发团队的不屑一顾的看法。
检察官吞噬了团队的士气。 他没有帮助提高产品质量，而是试图证明开发团队没有完成这项工作。 每个错误都被添加到大量证据中，这些证据表明开发人员过度依赖质量检查，而不是自己识别错误。
不幸的是，检察官是通过典型且相当可预测的过程创建的：
- 在生产中检测到严重错误。
- 测试人员被指控缺少此错误。
这种情况经常发生，因此质量检查人员自然会使用无可辩驳的论据为自己辩护。
解决方案
在更正原告之前，组织必须首先停止将QA归咎于生产错误。 那些需要这样做的人需要接受更有效的方法培训，以提高软件质量。
当组织不再责怪质量保证人员生产中的错误时，您可以通过邀请测试者更改主意和态度来修复它。
应该告诉他，开发人员只是人，所有人都容易犯错误。 质量检查部门必须补偿开发人员的这种自然财产，以保护其免受影响客户的错误的影响。 此外，由于繁琐而繁琐的编码过程，开发人员很容易看不到树后的森林：他专注于解决特定问题，以至于他忘记检查看似明显的事物。
改变态度：我们必须记住，我们每个人都在一个团队中工作，同志们不应因犯错而互相指责，而应为团队的善意帮助纠正它们。 对于QA而言，就项目而言，与开发团队建立合作伙伴关系尤为重要，而且不间断的错误检测，报告和修复漏洞的生命周期流程对于产品质量至关重要。
警卫
质量检查（QA），它指出整个产品的质量都无法接受，而其意见仅基于表面的印象。
问题
本质上，不同的应用程序功能具有不同的质量。 有些可能相对简单，或者是由熟练的开发人员开发的，因此几乎没有错误。 其他的则相对复杂，或者是由经验不足的开发人员开发的，因此存在很多错误。 这位警报者不幸运立即遇到质量差的区域-
未经进一步调查，他宣布整个产品不合适 。
您可以谈论很多有关QA轮胎开发人员如何浪费时间的信息（请参阅测试人员的
误导性文章 ），但情况有两种。 实际上，开发人员常常有意识地提供质量检查未经严格测试的软件，以奖励所完成的工作或声称自己已按时完成任务。 质量检查人员开始测试这样的系统时，会立即遇到开发人员应该已经看到的许多错误。 因此，很明显，他将所看到的东西推算到整个产品上，并声称质量很差。
危言耸听的人通常在质量检查部门中具有一定的权威，他的意见受到尊重。 他的权限级别越高，对项目的影响就越大。 典型场景如下：
- 产品已转移至质量检查。
- 一名报警员开始测试一个质量糟糕的区域。
- 警报器停止所有测试，并通知当局有关产品质量的严重问题。
这是一个典型的将孩子扔水的案例。 有时，质量保证会做出正确的选择，尤其是当开发团队因将未经验证的软件转移到质量保证而享有盛誉时。 但碰巧的是，由于一个弱小的开发人员而发出警报，该开发人员的代码是第一个出现恐慌症的人。
解决方案
如果开发人员反复让测试人员失望，那么它将成为一名危言耸听的人。 如果她始终提供高质量的软件，那么就不会有不信任的理由。 但是，如果测试人员成为一个危言耸听的人，那么开发团队将很难重新获得信心，尤其是如果该团队确实
在中国商店拥有开发人员的
大象并且
能力不强时 。
通常，在大型开发团队中，低质量的代码来自单个开发人员，而不是整个团队。 因此，当务之急是对能力不强的开发人员的工作进行最后测试，否则就不会落入危言耸听之列。 但是，这隐藏了一个真正的问题，即团队中有一些
开发人员会对项目产生负面影响 。
科学家
一个测试人员，大部分时间都在记录错误，而不是寻找新错误。
问题
在系统中发现问题就像寻宝一样令人兴奋。 当您找到这笔宝藏时，解决难题也同样有趣。 可以说，考虑以这种方式发现错误的过程的测试人员是理想的。 但是，如果他试图仔细记录他的迷人旅程，就会出现问题。 开发人员没有专注于主要问题，而是被迫阅读了很多没有帮助的细节的长篇小说，试图选择相关信息。
这位科学家从字面上理解“仔细记录错误”的要求。 他以文本历史记录的形式来描述它们，而不是简短地描述它们，并具有清晰的再现步骤顺序。 阅读此类报告需要花费大量时间，最后仍不清楚问题出在哪里。 通常，这样的描述包括多个错误，同时指的是系统的广阔区域，而不是特定的问题。
开发人员在收到科学家的错误消息时的主要抱怨是信噪比太低。 他们花时间在意识流中进行筛选，寻找特定的细节。 这对于开发人员和测试人员都是浪费时间。
解决方案
QA科学家可以通过教他如何编写正确的报告来轻松纠正。 通常，只要他们解释了对他的要求，便会立即进行纠正。 教授正确样式的最有效方法是以正确的格式重写一个或多个报告，这将成为将来的模型。 结果，一个热情的测试人员将撰写清晰简洁的错误报告，而这些错误是无法使其更理想的。
误导
QA通常会错误地报告错误，从而导致开发人员在尝试重现并解决问题时采用错误的方式。
- 可以变异为警报者
- 与统计信息等项目经理结合使用会很危险
- 校正的可能性： 高
- 项目危险： 高
问题
错误报告应包括以下内容：
- 确定确实存在错误的能力
- 能够定义播放错误的步骤
- 错误的完整描述，通常是根本原因
- 清除错误的步骤
在任何这些阶段，报告都可能误导开发人员，结果他将浪费时间：
- 如果没有错误，则开发人员将花费时间寻找不存在的问题
- 如果错误无法重现，则开发人员会花一些时间进行重现
- 如果错误描述不正确，则开发人员将花费时间寻找过于具体或过于广泛的根本原因
- 如果复制步骤不正确，则开发人员会花时间尝试解释它们，或者可能会声明没有错误，尽管他确实
有时，由于简单的测试器错误，开发人员会感到困惑。 但是误导性的测试人员经常会生成此类报告，从而引起开发人员的不满。 如果这种情况继续下去，测试人员最终将失去开发人员的信任，而那些开发人员甚至将无法修复实际的错误，从而拒绝此类错误报告。
解决方案
误导性的质量检查人员通常善于发现错误，而对错误的文档却很少。 因此，值得训练他。
最有效的方法之一是监视开发人员，该开发人员根据他的报告尝试找出问题所在。 只需坐在收到他的一份报告的开发人员旁边，然后静静地观察（不受干扰）开发人员如何设法解决该问题。 通常，这将导致有关如何最好地报告错误的健康讨论，这将使开发人员和质量检查人员都受益。
被压迫
质量检查（QA）被开发人员击败，以至于不太可能报告任何错误，担心他们会欺负他人。
问题
也许没有比开发人员对待质量检查的典型态度更能体现放纵的精神了。 另外，人们经常会看到积极进取的开发人员公开威胁测试人员，即使他报告了他们代码中的自然错误。 为了解决这个问题，与积极的开发人员一起进行成功的质量检查应具有以下特征：
- 已经赢得了开发人员的极大信任，因此他的错误始终受到重视。
- 与不认识该错误的开发人员在争端中表现出同样的攻击性和毅力。
不幸的是，没有很多测试人员具有这样的特征，因此开发人员经常擦拭他们的脚，并主要指责质量检查人员检测到一个新的错误。 不管看起来多么不合逻辑，这都是在以下情况下的典型情况：
质量检查随着时间的推移而被彻底击败之后，通常可以避免与敌对的开发人员进行对抗以减轻压力。 因此，尽管这些特定开发人员的错误可能存在，但很少报告。 通常，只有在生产中出现问题时才发现情况，并且开始调查测试部门未发现错误的原因。 沮丧的测试人员将提供以下任一解释：
- 他与开发人员进行了交谈，他说这不是错误。
- 他提交了错误报告，但开发人员拒绝了该报告。
- 他发现了一个错误，但是“没有认为这很重要”。
被动角色通常使人们难以识别受压的质量检查。 关键将是分析与该QA合作的开发人员-寻找明显的敌意迹象。
解决方案
开发人员经常直接嘲笑测试人员。 因此，应该像对待任何流氓一样对待它们：
- 要求立即停止嘲笑质量检查并避免采取侵略性行为。
- 培训专业沟通。
- 如果开发人员无法解决其行为，则将其关闭。
在特别严重的情况下，人事部门将必须进行干预，尤其是当局势恶化为公开敌意时。
令人遗憾的是，这种情况是常态，而不是例外。 唯一的区别是敌对程度。
随机答题器
通过随机点击方法搜索错误的质量检查。
问题
在系统中查找错误的方法主要有两种：
- 根据测试计划有条不紊地处理测试用例列表。
- 尝试在应用程序中四处游荡，以模拟用户操作。
编写测试计划是一项耗时的工作，并且不能保证在测试开始之前，该计划在更改需求之后仍然有效。 这可能导致测试人员完全放弃测试计划，而只是与应用程序进行交互以希望发现错误。
确实，与应用程序的意外交互会揭示错误，尤其是在产品开发的早期阶段。 但是，随着产品的变老，以这种方式发现错误将变得更加困难，因为剩余的错误被隐藏在临界情况下。 尽管没有经过应有的测试，但这会导致错误的安全感，就好像应用程序没有错误一样。
重要的是要记住，与应用程序的随机交互仍然是可以接受的方法，因为它可以揭示计划中未记录的情况。
但这只是测试计划的补充，而不是替代。解决方案
在以下两种情况之一中可能会出现随机的答题器：- 没有教他如何正确测试应用程序。
- 他积极避免编写测试计划。
如果问题是缺乏培训，则需要提供培训。但是，在这种情况下，即使测试人员知道自己应该制定测试计划，也仍然可以属于第二类。编写好的测试计划需要很少的组织，勤奋和专注水平。结果，某些类型的人喜欢这种工作，但大多数人却不喜欢。如果您很幸运，随机的答题器会找到编写好的测试计划所必需的特征，但是几率很小。胆大一点
, -, .
问题
正确报告错误是一个耗时且认知困难的过程，并且某些QA不想付出足够的努力。通常，这些是具有某些权利的测试人员：他们认为他们不必尝试选择措辞。他们也常常不屑一顾地看着开发人员，并不认为花时间进行某种错误分析是值得的：总的陈述足以使开发人员敢于找出问题所在。来自粗心的测试人员的典型错误报告包含以下短语：- “这不起作用。”
- “它又坏了。”
- “如果您实际使用此功能，问题将很明显。”
- “我不知道他们为什么错过它。”
- “下次仔细检查”
- “我不知道为什么我们不能正确实施它”
显然，开发人员对使用类似短语而不是重现该错误的步骤的报告并不满意。很少由专业的质量检查分析师来完成此操作，但是通常会发现该公司的另一位被要求查找错误的员工是否报告了错误。这通常是在发布前的时间很短且测试人员不足的情况下发生的。由于这种“帮助”，通常会发生混乱，因为开发人员拒绝了报告，从而在团队中引起更大的争议，这进一步加深了愤慨。解决方案
通常，专业测试人员应负责发现错误。不幸的是，业界认为每个人都可以搜索错误，但是事实并非如此。准确地说，任何人都可以检测到错误，但通常，只有专业的质量检查专家才能识别边界情况下隐藏的重要错误，并以开发人员可以立即理解，重现并修复此错误的方式进行报告。粗心大意的测试人员认为，他有权获得这些琐碎的报告。如果他进入质量检查部门，应被警告纠正其适得其反的行为。如果查找错误不是他的直接责任，那么应该禁止他报告错误，直到他学会专业地做。仅仅删除粗心大胆的测试器通常比尝试修复它要有效得多。通过他的行为，他明确表示他不想参与测试，因此删除它符合共同利益。另请参阅：