当我最近提出了更多的想法时，正式的（我实际上使用了“行业标准”一词）质量检查部门，我被告知“已决定进行精益开发流程。”原来，这个决定是在大约7或8年前做出的。我只有在过去的5个月中才说服他们迁移到2周的部署周期（之前是3-4个月），直到最后一个月，他们才削减了“构建”供“测试人员”进行测试。另外，对该“内部版本”进行必要的更改（可以编译或解释代码，因此修改很容易。）“内部版本”用引号引起来的原因是，它实际上只是主干的副本，最多最近的变化在这条道路上提出了更高的要求，因此它们被首先发现，并且都可以即时得到解释。
因此，似乎对“精益开发”是一个基本的误解。他们过去有一个质量检查部门，但由于缺乏生产力而感到困扰。当然，我们知道质量检查部门不是“富有成效的”。如果从制造的角度来看（确实如此），那么质量保证就可以通过增加失败和延长时间的项目的机会来阻碍生产率。 （我们尝试使用这样一种论点，即软件的质量检查就像他们生产的产品的质量检查一样。他们的看法不一样，因为政府要求其质量检查而不是软件。）
我如何使他们相信正式的质量保证将使公司受益？
#1 楼
这一定是开发人员在没有质量检查的公司中面临的最常见情况之一。由于我是质量检查专业人员，而不是开发人员，所以让我尝试从质量检查的角度对其进行解释。首先，质量检查的生产率很难衡量。如何做到这一点实际上并没有行业标准，这很可能是不可能的。但是，投资回报要容易一些。质量检查只是人为因素，因此我们将平均遗漏20％的错误。现在考虑一下软件投入生产时遇到的问题。每个软件故障都会花费金钱，时间花费在修复它，停产，收入损失或其他方面。节省80％的钱总是有用的。
其次，错误总是更容易（读起来更便宜）更容易在周期中发现它们。设计中的错误比代码中的错误容易修复10倍，而代码中的错误比生产代码中的错误容易得多。
第三，我发现这个比喻适用于老式的“实际-行业”的人就是人力资源或会计。他们在那里是为了促进业务的核心工作，即使他们不运行制造产品的机器。
除此之外，我想问问某人是否会使用未经测试的电机控制软件来驾驶汽车。该软件是至关重要的，否则您将无法使用它。
评论
+1用于修复/查找生命周期中较早的问题。与生产环境中发现的漏洞相比，在开发人员级别查找错误的成本为几分钱。另外，一旦产品中出现错误，成本就不会总是金钱。公司声誉，销售，信任的损失-如果问题足够显着，这些将使质量检查的美元成本降低。
–史蒂文
2011年5月11日17:13
我想说的所有内容都为+1，但占用的空间更少，也很清楚。希望我可以再说一句，指出我们只是人类。
– Lyndon Vrooman
2011年5月11日18:02
@Lyndon Vrooman：我发现问题后的下一个挑战是如何向管理层解释QA有时会错失bug，就像开发人员有时会编写bug一样。人性是一个我们都幸福的缺陷。
–卡米
2011年5月11日18:15
也许我对管理层过于自大，但这通常是当我要求管理层解释在某种情况下做出错误的业务决策时，他们不知道会阻碍某个重要的业务部门。
– Lyndon Vrooman
2011年5月11日18:38
#2 楼
目前有多少开发人员时间用于维护活动？熟练的质量检查人员不仅可以发现错误，还可以帮助提高代码的其他方面和开发质量，从而使开发人员经常摆脱那些平庸的，低级的活动，这些活动会影响生产力。结果可能是实际产量的大幅增长（不过，“熟练”一词在这里很关键）。此外，拥有质量检查部门应该使您的公司更容易雇用更好的开发人员并保留现有的开发人员，因为最好的开发人员将习惯于进行质量检查。缺少质量检查可能会给可能的雇员以印象，即您的公司不是技术公司，并且不会认真对待软件开发。您可以使用这样一种论点，即所有大型技术公司都在质量检查方面投入了大量精力（微软，谷歌，亚马逊），如果没有优势，为什么还要这样做呢？但是，老实说，我有一种印象，就是管理层可能根本没有在听你的话。他的技术足以说服吗？您的团队能否摆脱“变通方案”质量保证，您的一名开发人员需要四分之一左右的时间才能成为SDET，并且该团队轮流履行这一职责？这不如专注于职业生涯质量的专注于测试的测试员好，但可能会比当前情况更好。然后，您将有一个专心于发现产品一次3个月左右会失败的方法的人，这是一个巨大的进步，它使人们只能找到成功的方法，然后投入一些精力来确保产品不会失败。不会失败。如果开发人员中的某个人是面向测试的，也许您可以说服管理层，经过几个月的尝试，才有必要从SDE永久过渡到SDE-T。
您可能能够提出的最佳论据是找到更好的工作，然后跳船，除非您当前的公司拥有真正的质量检查部门-或只是离开并告诉他们原因。对于员工而言，“用脚投票”是有效的选择。当然，这取决于您对该问题的看法以及在公司工作的其他利弊。我的确给您的印象是，您的公司不了解技术，但这并不意味着它们并不成功，或者您的报酬不高。只要确保您保持最新状态以将来过渡到更具技术性的公司，就不要让您的技能停滞不前！
TL; DR：如果管理层不听，您可以尝试通过使开发人员成为临时SDET或尝试移动开发人员来解决这些问题。永久固定到SDET位置。否则，您可能要考虑离开一家技术娴熟的公司，并让他们知道原因。
#3 楼
使用事实和数据来证明您为什么需要质量检查部门的主张。您支持的一件事是您每2周发布一次。开始跟踪的一件事是每个版本中出现的缺陷数量，如果发现错误，还必须部署多少其他版本/修复。当您可以切实地解释更快的开发周期和更高的质量时，您的案子会变得容易一些，但这仍然是艰难的tough路。
评论
+1，因为坚持事实对我有很大帮助。除了可以找出比赛的结果以及他们是否有QA团队之外，我没有什么可以增加焕发光芒的人了。 （有时我认为我们在同一地方工作。）
–劳拉·亨斯利（Laura Hensley）
2011年5月11日19:04
#4 楼
我认为这里的核心问题是“用户在最终版本发布后发现了多少个错误？”
“最终版本中的错误有多严重？”。
管理层似乎看不到专用质量检查的意义，因为他们在最终版本中看不到很多严重的错误。揭露这些错误，显示基本的错误统计信息，进行最终用户满意度调查有机会说服它们。
评论
不幸的是，我们无权访问最终用户。 7200个用户，10个开发人员以及与他们的所有通信都通过BA，然后是工厂经理来进行。他们实际上看到了许多错误：他们的解决方案是报告它，打开一个新项目并修复它。大约80％的项目（“错误”）花费了大约50％的时间。当然，“错误”被定义为“当它不执行我们想要的操作时”。因此，如果他们的要求发生变化，那就成了一个错误。您可以说这是一场艰苦的战斗，但我当然不是第一个走这条路的人。 :)
–corsiKa♦
2011年5月11日17:09
#5 楼
您是否考虑过以质量和业务成本来表达您的期望/要求，即设置大量项目要花费多少（时间+金钱），而要进行专门的Q.A则要花费多少。团队吗？还可以与B.A.合作吗？团队发布产品投入生产后重新制定要求所需的成本（时间+工作量）？
我在想的是您可以“出售”采取预防措施的想法吗？而不是治疗措施？
评论
大约两年来，开发一直试图将其“出售”给BA。直到最近它才开始受到关注。从过去的经验来看，建议这样做实际上会损害关系。例如，广管局局长在我参加双周会议时曾经与我共享办公室。我问他对BA进行测试而不是QA团队的想法，他说BA进行测试没有错。从那以后他也没有来我办公室。耸耸肩
–corsiKa♦
2011-10-19 15:49
直接与工厂经理交谈并把想法卖给他们有什么价值？另外，您是否可以与公司中的实际预算持有人交谈，并向他们解释好处？回顾您的原始帖子，您是否可以从工作的2周下降周期中提取一些指标，然后对这些指标进行按摩，以显示如何使用专门的质量检查团队/部门使开发更加精简（即离开开发人员）和BA有足够的时间专注于他们应该做的事情？
–开发
2011-10-20 7:38
#6 楼
我曾在三个不同的行业从事产品开发和质量保证工作。合理化质量检查是一项教育和组织成熟度问题。专用QA的价值取决于团队的规模（角色的专业化）和与软件问题相关的风险。一些团队无法证明这一点。每个项目都是独特的。
根据我的经验，需要专门的质量保证归结为两件事：
1）观点和风险。
很容易地说每个人都应该检查他们自己的工作，但这是一个乌托邦式的结构，类似于说您的孩子应该为自己的数学作业评分。从本质上来说，开发人员的工作几乎总是从用户和产品的角度出发，而这对于良好的质量检查至关重要。他们的工作性质要求他们专注于深入研究复杂逻辑问题的细节。如果他们提供良好的代码和良好的吞吐量，大多数开发人员将无法执行良好的质量检查。大多数人都可以通过撰写研究论文或论文来确定自己的身份，以及在做几天其他事情后又回到何处时，会发现写作中的重大问题。开发人员没有足够的时间让代码闲逛几天，而他们却只能用“新鲜的眼睛”看着他们，而很少有最终用户或客户的观点。要求他们自己进行质量检查甚至是不公平的。他们是超级聪明的人，但他们不是魔术师。如果软件中存在问题的风险对您的公司/产品/客户很重要，那么质量保证的执行方式就需要在开发过程中进行不断讨论。
2）周转时间和构建周期。
如果要快速发布和构建版本，则需要同时进行开发和测试。如果没有角色的专门化，就不可能快速地进行代码，QA，修复和QA修复。
那谁应该做？
向专用软件QA全面分配人员的一个很好的过渡步骤是将其与业务分析师或产品角色相结合。业务分析和测试是同一事物的两个方面。验证几乎可以由与代码有一定距离并熟悉团队SDLC的任何人进行，但是真正的验证需要产品方面的某个人在最终用户的头脑中具有最终用户的观点。让产品方面的人员与软件团队紧密合作是一件很美好的事情。这个人确实需要决定成为开发团队的扩展，并学习事物在开发方面的工作方式。一个优秀的质量检查人员无论如何都要反向执行很多BA，仅仅是为了建模信息以使开发人员可以测试和使用它们。
最后要考虑的是“测试”与“ QA” 。测试是一项任务，更容易外包，并且开发人员可以根据工作完成并取得一些成功。另一方面，质量检查人员是一个职业/职业，并进行了很多测试，但具有很多整体观点。如果您曾经在监管机构，制造商，医疗保健机构或金融机构中工作过，那么即使没有任何代码，QA还是一个完整的职业。在质量专业领域，这通常被称为质量控制与质量保证，并且值得Google进行10分钟的主题之旅。将QA称为“测试”确实使它降低了许多等级，但这可能是与管理团队建立联系的最佳方法。测试的价值对他们而言更为切实。
步骤（可能需要多次迭代，可能要花费数月或数年的时间：
1）为每个需求定义需求或用户故事或等效内容软件迭代。如果您有业务分析师，请加以利用。实际上，这比专门的质量检查更有价值。
2）定义质量保证交付物，以确保满足这些要求，并在团队中进行划分，以便交付物本身成为合理的，而不管是谁做的。
3）让管理人员参与有关基于技能集的资源智能使用的讨论。许多经理认为，他们需要保持开发人员的编码，让其他人进行质量检查变得容易。一段时间后，在许多环境中，很明显，您需要一个专门从事该行业的人员来做得很好。您的项目和公司将有独特的需求，随着时间的推移，这些需求将变得清晰。
4）有时公司文化或教育障碍无法克服。如果您对优质产品充满热情，并且您的管理团队不愿意为此目的工作，那么您可能会选择错误的公司。软件具有无形的质量，许多公司根本无法解决行业中的独特挑战。如果您发现自己说的是另一种语言，而别人却听不懂您的话，则说明您的环境已经不适应了，您需要继续前进。
#7 楼
很久以前，我读了一篇文章，介绍了为什么我们需要质量检查人员或测试人员，以及您的经理是否使用MAC与他共享这个High Sierra安全漏洞。没有骆驼看到他的预感！因此我们需要有人来观察一下预感：)
下一步是使事情井井有条。
评论
即使如此，我也很欣赏答案。我要说的是，此后我已经离开了那家公司，现在我的公司的开发人员与质量保证人员的比例为3：1。他们使每个人的生活都悲惨。关键是他们会让人们的生活变得痛苦，而不是客户或支持团队！！！系统正在运行！！！
–corsiKa♦
17年11月29日在18:42
毕竟，对于某些人来说，这仍然是一个问题：)
–mysql_user
17年12月1日在6:25
#8 楼
有时，我写了一篇博客，介绍了为什么还需要专门的测试人员，他们也不应该负担编码：手动测试人员的死亡
似乎无关，我认为它回答了有关为什么需要测试的一些问题。
以全球烹饪秀Masterchef为例：有些人认为自己做得很好，直到将菜品发送给评委。法官，手工艺专家进行了细致的分析，并找出了普通人无法分析的差距。
在做出判断之前，厨师一定以为他们的菜真的很好看。经过判断，这完全是另外一个故事。
“软件”软件开发的困难之处在于，您需要具有专业技能和领域知识的测试人员，以确保您的产品/项目能够满足客户的期望。
但是，所有这些都是理论性的东西-很难用理论概念说服人们。要说服人们，您需要数据：大量数据。具体，易于理解的数据可以证明您的观点。
挖掘一些有关软件错误和不完整的开发如何导致错误，信誉丧失和公司金钱的事实（在金钱方面有压力...应引起他们的注意！）。
您的公司管理层不喜欢拥有质量检查部门的原因可能很多。这些可能是：
也许他们生产的产品并不复杂，可以使用大爆炸方法进行开发。公司认为在开发阶段可以考虑所有
测试覆盖范围
。也许他们觉得需求很清楚地提到了
，它们本身涵盖了测试用例。
他们认为开发可以完成单元测试和集成测试。团队本身，不需要额外的
专用质量检查资源。
也许他们没有看过和/或不觉得有必要展望未来并预测他们的产品将如何推出。可能没有为其定义的路线图。他们认为当前的流程足以确保无缺陷交付，并且不需要添加专门的质量保证。
您提到您的公司不使用自动化：令人惊讶的是，自动化是人们不再喜欢手动测试的第一原因。自动化绝不是人工测试的替代品和替代品，完全是另一回事。
我建议您挖掘一些事实和具体数据，以了解潜在的漏洞将如何损害产品的声誉并导致收入，声誉和商誉的损失。
看着您的问题，我很想知道：
a）贵公司仍在构建什么软件/产品？它的功能和体系结构是否非常复杂？
b）在产品的生产中是否没有发现问题？如果是的话，贵公司如何处理呢？
c）为什么贵公司不使用自动化？
评论
我从哪里开始...“精益开发过程” =“敏捷” =“根本没有过程” ...额头for。 :-)也许是因为我没有看过您的其他帖子而错过了，但是为什么您觉得您需要正式的质量检查或更准确的是测试部门？
希望您不要介意将您的答案转换为评论（因为这是需要澄清的要求）。要回答您的问题，因为目前我们还没有人进行真正的质量检查。我们有分析师列出了项目清单，以确保它们仍然有效，但是没有人测试系统的其他方面。也没有测试标准，只是他们是否认为它“应该被批准”。对于拥有12名开发人员和8名分析师的团队，我们至少应有2到3名专门的质量检查人员。