在过去的几年中，我们的质量检查团队一直非常积极地对我们的产品进行手动和自动测试，从而导致很少有实际用户对我们主要产品的功能和可用性提出投诉产品。
对我们有用的一件事是“尽早开始测试”-当一项功能已部分实现或只是在非常不成熟的状态（处于“开发”状态）发布时环境）。这个想法是要尽快给开发人员反馈。这是受巴里·博姆（Barry Boehm）定律推动的：发现问题的时间越早，解决起来的成本就越便宜。
问题
虽然事实证明对我们有用，但仍有相关问题。通常，它是“信噪比”。
一方面，测试尚未准备就绪的功能通常有助于揭示关键问题，即设计/架构功能时遇到的问题。
另一方面，很多问题并不是真正的bug或问题，而只是“在进行中”或暂时中断的事情。这导致我们的开发人员和测试人员都浪费了时间。
您建议如何提高“信噪比”？
#1 楼
开发人员和质量检查人员之间的沟通更加畅通，从而使质量检查人员已经了解在制品方面的问题。
在存在分歧的地方先进行亲身沟通，然后记录该协定。
明确所使用的质量指标的定义在您的公司工作。
在编写第一行代码之前，需要进行更多的讨论和计划。
定期讨论哪种测试适合于构想，原型，初稿或最终产品
对不适当记录的问题进行有计划的审查以学习和更改
商定了开发人员在票务管理系统中的特殊区域标记“ wip”内容的方法，以便质量检查人员在开始测试之前可以首先看到。
继续您的总体指导，并确保开发人员接受您的“左移”理念。我的个人经验是，开发人员总是乐于听到有关它的信息。
评论
在开发者会议上讨论“通信”是我们讨论的第一个想法。之后，我们花了45分钟的时间争论开发人员如何准确地将WIP内容传达给质量检查人员。决定坚持使用当前版本的Wiki页面，其中包含有关WIP部件的特殊段落。虽然它可能无法很好地扩展，但是我们将看看它是否对我们有用。谢谢！
– alecxe♦
17年5月5日在18:40
我建议进行1：1对话，然后进行记录。如果最初的对话花了45分钟，那么有一些问题需要通过委派给文档来解决，这对解决我的经验中的基本问题没有效果。
–迈克尔·杜兰特（Michael Durrant）
17年5月5日在22:48
#2 楼
何时编写bug的悖论...噪声仅仅是对那些收到意外消息的人的一种感知。如果我们查看ATDD和BDD，则想法是所有测试均在编码周期之前编写，并且所有测试均被视为失败。所有Bug都是测试失败的结果，通常仅在编码交付后才编写。但是实际上，错误应该没有负面含义，因为它只是行为的记录。每个错误可以是有效的或无效的。
然后，错误队列将成为面向行为的数据库，如果管理得当，它可以成为非常有价值的离线资源。主要原因是要确定要包含在每个迭代中的最有价值的Bug。
我曾经做过一个项目，我们尽可能早地进行了测试，它产生了许多开发人员不喜欢的错误。他们说：“我们还没有完成这个项目吗？”它的确增加了跟踪事件的开销，但是当产品发布时，它没有一个严重性问题就可以直接投入生产。产品负责人陷入了我们的错误队列，直到完成所有严重性为1和2的错误后，才发布项目！
如今，大多数开发团队都无需在进入下一阶段之前就通过自己的单元测试显示测试结果。如果做得更多，那末会有更好的结局。甚至对于QA团队而言，单元测试也是最好的测试场所。
向前迈进，QA团队成员将不得不掌握编程技能以保持相关性。自动化不仅涉及从GUI进行处理，还涉及从代码端进行处理。
评论
绝对，我们与开发团队就这些早期错误有一些争论！好主意;心存善念;睿智哲思！我没有提到这一点，尽管这可能是相关的：尽早进行QA测试的另一个动机是，我们的UI开发人员根本没有对他们的代码进行单元测试。我们尝试在应用程序的整个生命周期中进行更多的端到端测试，直到产品投入生产为止。.我知道，这很可悲。非常感谢！
– alecxe♦
17-6-5在18:38
我经常从开发人员那里听到我们没有足够的时间进行单元测试，他们是对的！这个问题的根源在于迭代的计划。如果开发人员没有足够的时间进行测试，那么截止日期是错误的！产品所有者和用户现在想要的东西无济于事，因为他们负担不起。解决此问题的唯一方法是2周的迭代，不断为产品提供最大价值。质量检查团队可以使每次迭代滞后，但这并不是最佳选择。就像他们说的那样向左移动...
–约翰·彼得斯
17年5月5日在22:04
#3 楼
我认为您是错误的……您不会通过发现这些问题来浪费您的测试时间。由于您没有详细说明到底浪费了什么时间，因此我将做出一个危险的假设，认为这是实际问题之间的噪音交流。首先，我想重新来看我先前的观点；让测试人员发现并注意这些问题（我的意思是要注意，不要进行任何正式的错误报告程序，在这种情况下，这是浪费时间），这本身就是一件好事。它可能不会直接增加产品的价值，但会增加测试人员的技能。如果这些注释可由外部方清楚阅读（这在干净测试中是主要目标），则仅凭它们本身就可能足以向开发人员传达问题所在。好的测试人员应该尝试评估潜在的噪声因素（按钮损坏而不是正确的数据表示），并适当突出显示。
如果需要更吸引人的方法，请与开发人员和开发人员一起进行有时间限制的配对测试活动测试人员可以创造奇迹来减少这种破坏。
在如此迅速变化的环境中，形式和时间的浪费是沉重的负担。
#4 楼
后端的更改更容易（因为用户的POV没有更改或定义的更改）。更棘手的是如何对UI更改进行早期测试，尤其是对UI进行彻底的更改。与正式的早期测试相比，我们取得了巨大的成功，开发人员展示了重新设计的新页面，而该页面仍在DEV中供更广泛的使用观众：5-10人。开发人员进行所有单击（并可以限制对损坏部分的访问），但用户可以看到页面的工作方式和感觉。仅阅读页面设计文档就很难获得这种感觉。
我们发现最有价值的受众是培训师。他们非常了解我们的系统，但也知道哪些部分对用户而言比较棘手或不太直观。但是欢迎任何人（代表将来的用户）参加此类演示。
开发人员可以展示新的GUI，并尽早获得反馈（可以用自己的术语写出问题列表），而不会产生太多的错误和将它们分类的额外工作。
通信而不是文档。
#5 楼
我曾在跨职能敏捷团队中工作，简单的答案是，如果在发现问题的同一天无法解决问题，则写一个缺陷。保留白板/停车场的空间记录当天发现的所有东西。最终，任何尚未解决的问题都需要记录为缺陷。
分配给缺陷的优先级或严重性值是否不同？为什么QA不能仅将项目标记为“低”，而只是简单地忽略或滤除这些问题，直到有时间解决它们为止？
如何决定对缺陷的评分方式是另一个问题谈论。您对什么定义为低/中/高缺陷有定义吗？您和您的质量保证团队是否就高优先级与低优先级的缺陷的维修时间表达成一致？缺陷修复是仅在完整版本中进行还是在进行中所有问题都已修复？如果它是动态的，那么您如何确定最终版本所需的所有回归测试？
评论
我很高兴在这个论坛上提出这样的相关问题。与我们平常的饮食方式有很大不同...是的，来自@alecxe的第二个好问题！
测试尚未准备就绪的功能通常有助于揭示关键问题，而开发人员未发现这些问题？
@JohnGordon绝对是这样，其中有些确实也被开发人员捕获，另一些确实被质量检查团队捕获-我们从功能开始就基本上对白色，灰色和黑色盒子进行了测试。同样，我们希望通过QA团队的早期参与解决的其他问题之一是弥补UI方面缺乏单元测试的问题。我理解这是不正确的，我们应该对此进行改进。谢谢。