该项目只有一名开发人员，基本上，该项目只有8个工时。管理层质疑我的团队能力，因为他们想看到的是：
，但实际的错误发现是：
我告诉他们吗？
#1 楼
没有足够的数据可以明确任何趋势。您在5月下半月发现了约26个错误。在6月的上半年，您发现了大约27个错误。如果错误发现率保持这样的水平，则预计您可能会在6月发现40个错误（其中40个有些保守）。
因此，您可能有两个数据点：26和40。
请考虑以下假设情况：
7月：37个错误
8月：46个错误
9月：33个错误
10月：33个错误
11月：29个错误
12月： 17个错误
1月：25个错误
2月：24个错误
3月：19个错误
4月：18个错误
5月：14个错误
将其放在您喜欢的电子表格中应用程序并将其绘制为条形图。看起来熟悉？如果您的高层管理人员试图在一位测试人员的160个小时的工作量上找到一些显着的进步，那么他们就会非常误解。您需要向管理层展示的是，在实施这种新的工作流/工具/测试技术时，您已经发现了代码中的43个错误。
可能您正处于其“预期”左侧的结果。也有可能一个项目的1个测试人员根本不足以生成这种模式。实际上，如果错误查找保持不变，则意味着您没有足够的人进行测试才能使他们足够快地找到错误；例如，当他们找到20个bug时，又创建了20个bug，并等待被发现。随着时间的流逝，看到下降趋势的唯一方法是测试人员能够比发现缺陷更快地发现错误。
只是要强调一下，无论是否记录，这都是一个问题，而且还没有足够的数据得出任何结论。如果他们似乎想要摆脱这个职位或完全停止测试，请尝试让他们将其视为试用期，并说服他们给您的团队6个月的试用期，甚至走到安排一个日期/会议，介绍试用期的结果。
因此总结：
强调小数据集。 br />尝试将测试扩展到至少6个月
在6个月末呈现结果，并尝试证明测试带来的好处
强调这些错误无论是否被记录都存在，并且代码中的错误可能是非常昂贵的风险。
评论
查找小数定律。 en.wikipedia.org/wiki/Law_of_small_numbers。这是一个非常常见的认知错误。我们都做到了。 OP的经理正在做到。
– O. Jones
17年6月23日在10:08
#2 楼
您与高级管理层之间的沟通存在差距。就我个人而言，我认为高级管理层不会太认真地对待第一个错误发现图。这只是一个理想主义的指导方针，在现实生活中可能永远不会发生。
我推测您的高级管理层质疑您的能力或承诺的原因也许是您在以下所示的那几天没有提供任何解释。 />
我个人的建议是：
鉴于他们对您的能力或承诺有疑问，您应该提供有关以下方面的详细报告为什么在几天内（没有忽略周末和公共假期）没有发现错误，即使高级管理层没有要求，也要每天提供更新。每当有项目状态更新时，请抄送他们以保持工作进度透明。
评论
由于OP表示该项目只有一名开发人员，而这些差距分别反映了一个周末，整个一周和一个周末，所以我认为该开发人员本周在休假，而不在周末工作。不过，洞察力很好。特别是粗体位。
–user26379
17年6月22日在15:28
#3 楼
有些错误可能需要几天的时间才能进行跟踪和正确报告（可重现）。如果错误无法复制，则错误报告将毫无价值。告诉您的管理者：“请小心您的要求：您会得到的”。如果他们想计算错误，测试人员将输入大量琐碎的错误，但往往会忽略需要很长时间才能正确报告的错误。这是不合理的指标。
发生的事情是这样的：管理层雇用了一群不熟练的暑期实习生，他们的任务是寻找最多的bug。受过最少的培训，因此甚至报告了正确的系统行为作为错误。报告），几个开发人员花了全部时间只是整理（并拒绝）大多数“错误”报告。当然，他们没有检测到任何严重的错误。
实验是如此灾难，以至于短短几周就被放弃了。
#4 楼
为了找出答案，有很多事情要解决。您应该告诉他们什么？他们。
然后我将尝试找出以下内容：是从开始到结束的功能数量的变化
早期和晚期错误的严重程度是什么？ br />
也-超过2个月的一天（最多几天）每天发生两次错误是进行此类分析的一个很小的样本。为了拟合该曲线，我宁愿比较这么小的样本每月比较而不是逐日比较。它可能逐月拟合该曲线，这仅意味着需要调整时间范围才能看到该模式。这是办公室政治的一种说法，您需要更多的时间和资源。
那是哪一年？周末呢？
#5 楼
这尤其无济于事，但是我非常想告诉您的管理层，如果他们非常喜欢统计数据，请重新获取统计数据。使用这样的小数字，所有关于统计模型的赌注都没有了，当您像这样建模时，基本上就是随机人随机出现并随机发现一些错误的情况。实际上，测试不是随机的，但是随着发现错误，您将扩展和开发合适的过程和领域进行研究。那不是模型的目的。#6 楼
许多因素都会影响发现的错误数量。方法论。如果您感到困惑，肯定会有随机变化。
变化。如果在测试新软件时更改软件很容易引入新错误，并在接下来的几天内发现新错误的数量就会增加。
错误的复杂性。遇到错误只是报告它的第一步。找到足够的信息来制作有价值的报告可能需要很长时间才能解决复杂的错误。
重点。如果您在不同的日子针对不同的功能区域，那么昨天的数字将不会对今天的数字产生影响。您正在探索不同的地形。可能有所不同的特定内容：
以前的测试。已经进行大量测试的区域比没有进行过先前测试的区域查找错误的可能性要少。
功能时代。一个已经存在很长时间的功能很可能只是通过使用就发现了主要错误。
Developer。由经验丰富的开发人员编写的代码可能比新开发人员编写的代码具有更少的错误。专门用于自动化测试的计算机功能，您可能仍处于测试的开始阶段。如果您当前的图表是短期图表，则没有必要根据长期趋势进行评估。
您可以编写测试说明，以讨论与您的情况相关的任何一项。发现错误是发现活动。您进行调查是因为您不知道会在什么地方，什么地方或何时找到。这是不可预测或一致的。看到发现的错误数量的波动是正常的预期情况。这将通过报告虚假错误来按摩图表。
评论
对于不同的功能领域，另一件事可能有所不同：测试难度。特别是对于手动测试，X项功能测试所需的时间可能会千差万别。单击1按钮将遍历5个表单页面，并每次填写所有内容。
– hg786t76g
17年6月22日在14:57
#7 楼
也许问他他从哪里得到那个模特的。数据收集最重要的事情是了解使用了哪些系统和流程来收集数据。如果您不了解数据的依据，那么您将无法有效地回应他的主张。 ，即烹饪和休息期间的食物温度。”这取决于所测试的食物，它们在休息时是否覆盖食物等。如果您以面值来绘制图表，则会做出很多假设。由于老板质疑您的团队的能力，请多问一些深思熟虑的问题，以了解他为什么认为您的错误检测率应该遵循该图表。能力和信誉取决于您所提出问题的质量。
如果您提出正确的问题，您的老板最终将使自己相信图表为什么不能代表您的项目。更好的是，通过正确的问题，您可以使用新的模型或解决方案来解决问题。
#8 楼
现实与虚构理论。因此，它取决于许多因素，例如：开发人员的质量，测试人员的质量，域的复杂性，甚至可能是要求的质量。以正确的方式制造正确的产品非常困难。http://blog.christoffer.me/9-things-i-learned-from-reading-the-clean-coder-by-robert-c-martin-on-how-professional-developers-conduct-自己/
就像UncleBob一样，我希望开发人员将没有（几乎没有）缺陷移交给质量检查团队。在最近的4个开发人员项目（运行了半年）中，我们仅发现2-3个生产缺陷，但是没有什么严重的。此外，我们没有质量检查人员或团队。尽管如此，除了一些非常复杂的仪表板和过滤功能之外，我们仍然会处理来自多个来源的大数据并进行复杂的分析。我们必须根据您的管理层进行测试，因为我们会发现并发现几乎没有缺陷。良好的开发人员实践会走很长一段路。
在单个开发人员项目中，缺陷应该更低，因为理解自己的代码库非常容易。将依赖关系降到最低，没有其他开发人员破坏您的代码也必须是一个伟大的壮举。它看起来像个草率的开发人员。他/她有时间阅读有关CleanCode和技术卓越的知识。
#9 楼
错误的沟通是关于“曲线”的平滑度。我看到高级管理层实际上想说完全不同的可能性很大：他们计划最多测试四个星期，并且他们期望到现在为止拥有稳定，几乎没有错误的应用程序。 （当我查看他们的图表时，清楚的消息-右侧是一个稳定的，没有错误的应用程序。）我将是魔鬼的拥护者，并假设已将此时间表通知团队。通常，该图的水平轴（到没有报告任何新错误的稳定程序的时间）应该持续数年或数十年。对于一个非常简单的小型程序，它只能缩短为四个星期。我还假设您没有挑战这个大假设。您在问题中什么也没说，就像您在几周内理所当然地要做大型应用程序数十年来所做的那样。说他们的目标是什么，那是他们的大错。他们有责任进行清晰有效的沟通，并知道他们期待几乎不可能的事情。因此，我认为您已经传达了这个超乎寻常的计划。
进入第四周，您每天通常可以修复3或4个错误。哇，还有很多，不是吗？他们期望在第一周和第二周进行更多测试。我知道我会在这样的时间表下进行。
特别是如果您只有四个星期的时间，那么第一周看起来根本就不是诚实的努力。测试人员只注册了两个bug后是否坚持不懈地“每天称它”？也许注册错误是一些重大的双峰制琐事？ （这取决于直接经理进行分析/修复，而不取决于高级经理。）也许没有足够的资源分配给测试？ （同样，这取决于直接经理，而不是高级经理）。也许程序员在整个测试过程中慢慢交付了新功能，所以在第一周几乎没有什么要测试？ （一个管理/计划/程序员问题-您雄心勃勃的计划显然应该延长）。
评论
-1。期望从一天到第二天发现一致数量的错误是不合理的。发现的错误更少= / =缺乏诚实的努力。
– hg786t76g
17年6月22日在14:48
@Lycan我并不是说高级经理是合理的。我并不是说他们沟通清楚。我并不是说他们实际上想要日常的流畅性。但是我要说的是，在四个星期的第四周中发现超过25％的错误，他们可能会感到惊讶。
– Kubanczyk
17-6-22在15:45
并不是的。在不知道这些数字的背景的情况下，它们毫无意义。如果测试人员以前没有接触过代码，那么第1周可能一直在学习。或设置。或许多其他事情。也许他们发现的错误非常严重，无法继续进行，一旦修复了显示错误，您将在5月29日发现大量错误。
–凯文·麦坚时（Kevin McKenzie）
17年6月22日在15:55
您也找不到找不到的错误。如果恰好发生在计划在第4周进行测试的产品出现大量实际缺陷的情况下该怎么办？对诸如“在4的第4周内发现了超过25％的错误”之类的事情感到惊讶，这也隐含着期望您的开发人员平均分配他们的错误。发现的bug数量根本不能衡量测试工作的完成，因此仅根据bug计数统计数据说“第一周看起来根本就不是诚实的努力”，这是荒谬的，而是侮辱相关团队。
–本
17年6月25日在4:41
评论
告诉他们：理论上，理论与实践之间没有区别。在实践中，有。这样的曲线可能被视为数百个项目的平均值。在单个项目中，没有机会。有效问题BTW，+ 1。要知道这两条曲线的匹配程度还为时过早。如果下个月您发现错误的数量是本月的两倍，然后下个月与本月一样，那么您将完全适合该图表的左半部分。
您告诉他们阅读此问题，以便我们告诉他们他们有多愚蠢。为什么管理在每个地方都如此无能为力？
在我看来，实际的错误发现曲线与理论上的曲线确实有很大不同。您将需要长时间平均才能看到任何东西，但这仅仅是错误数量少且在这种类型的数据中完全正常的产物。
第一张图是由数百名测试人员制作的，工作时间数以万计。你给我，我给你这张图作为第二张。不要指望它来自其他任何事物。