我们的支持人员有时会进行测试，或者我们尝试测试彼此的工作，或者我们的经理来进行测试。有专门的质量检查小组成员。我发现质量检查非常有用，并且认为它可以帮助我们，但是我必须证明原因。
我可以想到的原因是：是由开发人员完成的工作，而这会占用开发时间。
没有人要负责我们所有UI和其他系统的领域知识。
一个选择了自己职业生涯的QA
实际上是想要做的并且擅长于此。
熟练的QA将具有编写自动化测试的知识/>我想念什么原因？
#1 楼
首先，我要说明一下您的原因：开发人员进行的测试在单元测试级别上是很好的。专门的质量保证可能会发现和利用开发人员没有意识到的问题（但客户可以并且将会发现）的情况会更加熟练。运用它来发现具有深远而狭窄的专业知识（这是必需的）的开发人员可能会错过的情况。 （我不会完全改变这一点-但我要补充一点，对于开发人员而言，当他们宁愿编写代码时也常常会不断地测试和重新测试的需求，这并不罕见。自动化测试。
您还可以添加其他一些原因：熟练的测试人员知道如何工作，以避免让熟悉感使他们看不到问题。
熟练的测试人员会故意使用该软件做错事。这可能会暴露出开发人员不会想到进行测试的主要问题（个人而言，我已经失去了将软件强制进入开发人员认为不可能发生的状态的次数）。将尝试找到并测试使用被测试功能的所有方式。他们不会找到所有这些，但这仅仅是因为每个足够复杂的软件都具有通过它的无限数量的路径。我曾经追踪过一个仅在50多个步骤结束时才出现的问题。
熟练的测试人员可以帮助开发人员选择有用的方案以在单元测试或其他自动化测试中实现自动化。
熟练的测试人员可以在编码开始之前发现需求文档和/或用户案例的问题，从而避免了返工，从而节省了时间和金钱。
如果您需要对管理进行辩论，则需要集中精力节省时间/金钱。为此，您需要对用于报告问题的任何工具进行深入研究，并注意在发布之前您认为已经捕获的比例（最好是特定时间段的平均值）专用测试仪。如果您有任何数量与解决这些问题所需的时间有关的数字（同样，每季度或每月平均工作时间），请使用它们，并将其与团队解决您发现之前所发现问题所需的时间进行比较已发布。然后，您可以提出一个论点，即区别在于您的团队本来可以开发新功能的时间，这对公司来说比修复错误更有利可图。
评论
这是一个很好的回应。
– Blarg
19年7月24日在12:18
您触及了它，但是也许您想特别添加这个角度，因为它可能与管理层的观点相呼应：擅长发展需要时间和“大脑能力”，因此需要金钱。测试也是如此。这些技能是分开的，大多数人可以在这两个方面的职业生涯中不断提高。开发人员尝试在测试上变得更好所花费的时间不是开发或在开发上变得更好的时间。聘请质量检查人员意味着他们已经具备了技能，您可以省下这笔钱，而不必浪费金钱（时间=金钱）给开发人员学习测试。
–弗兰克·霍普金斯
19年7月24日在20:00
对我来说，原因之一是开发人员对错误视而不见，因为他看到了自己想编写的代码，而不是自己编写的代码。
– Monty Harder
19年7月24日在22:30
如果您需要对管理进行论证，那么您将需要集中精力节省时间/金钱。部分。如果管理人员根本不是技术人员，他们可能会听到“我们希望您雇用将为我们做部分工作的人*
–火星
19年7月25日在4:32
+1，但这里还有一个更关键的问题：质量检查是另一组眼睛（和头脑），他们阅读规格并清除未说的假设-这可能与开发人员的假设有所不同。
–Peter M.-代表莫妮卡（Monica）
19年7月26日在18:15
#2 楼
测试人员（或专门的质量保证）会带给团队另一种心态：开发人员“构建事物”，测试人员“破坏事物”。（当谈到“破坏事物”的心态时：当然，没有人试图从字面上破坏软件，这只是从另一个角度来研究它。）致力于找出有关他们正在测试的事物的新信息，这些信息可能会在测试之前对所有人（包括制造事物的开发人员）隐藏。
评论
这是一个非常普遍的误解，有些想法很快就会瓦解。测试人员没有编写它，所以他们没有破坏它，他们倾向于不更改正在测试的程序/代码。因此，根本没有办法破坏任何东西。与可以通过丢弃或以意外方式破坏它的物理对象不同，软件只能由创建它的人员破坏。测试人员只是找到损坏的地方并报告。有时，它甚至不是真正的破损，而是不如客户期望或希望的那样起作用。
– Piotr Wicherski
19年7月24日在17:50
@MobileQA可能会争辩说，小Bobby D.表实际上破坏了数据库。在某种情况下，它停止了运行。我认为一个好的测试人员将不仅仅是发现坏的东西。至少我希望他们找到可能有用的东西，但是就他们不会抗拒滥用（无论是天真还是故意的）而言，这是不安全的。这与大多数关注幸福道路的开发人员不同（如果我正确地使用我的代码，确切知道其工作原理，我能否获得规格），也不一定要攻击规格。
– ptyx
19年7月24日在22:58
@MobileQA我说的更多是“打破常规”的心态。当然，没有人试图从字面上破坏软件，这仅仅是从另一角度进行研究。
–伴侣Mrše
19年7月25日在6:37
但是，不幸的是，描述测试者观点的“破坏性”方式具有导致更多不合逻辑的言语和行为的不良趋势。例如，“如果这些测试人员停止破坏所有产品，我们可以更快地发货。”我们打破了假设，或者像迈克尔·博尔顿经常说的那样：“我们打破了对软件的幻想”。那是我们的心态，但是如果我们在讨论方式上不清楚，人们很容易陷入不合逻辑的责备游戏，“射击信使”等。
–c32hedge
19年7月25日在17:16
另请参阅developersense.com/blog/2015/02/…，以了解迈克尔·博尔顿比我能发表评论的更好的解释：
–c32hedge
19年7月25日在17:17
#3 楼
我将在这个问题上稍有不同。我的答案是：不需要专门的质量检查团队成员，但是
专门的质量检查角色是个好主意。
考虑一下您拥有专门的质量检查团队的情况成员，但他
做得不好（或根本不做工作）。在这种情况下，您已经
找到了一个特定的解决方案，但问题没有得到解决
。您需要“上一层”并专注于实际的
问题，而不是特定尝试的解决方案的细节。
好的质量保证确实是非常有益的。如果问题是您
觉得您当前的项目没有足够的质量保证，那么您
（尤其是您的管理层）应该同时考虑如何移动
从其他地方进行质量检查，以及如何在项目中添加其他资源以进行质量检查。向团队添加专门的质量保证人员肯定是后者的一种方法，但不是唯一的方法。
以下是您可以考虑的其他解决方案：
每周留出一两天供现有的开发人员（可能是对质量检查最感兴趣的开发人员）专门针对此问题进行开发
，而不是专注于开发新功能。
聘请一位在质量检查方面具有丰富专业知识的新开发人员，并让他在一周的一部分时间内完成上述任务，并在接下来的一周的其余时间内进行开发。
聘请一位质量检查人员，对开发有所了解，并且对学习有兴趣，请让他花一些时间进行质量检查，并花费一些时间进行开发。 （确保您分配时间和
资源来培训他的发展！）质量保证项目中的时间成员
。
您可以选择随着时间的推移使用这些解决方案的组合，并随着时间的流逝将“关注质量保证”作为重点好吧。
这类解决方案有两个优点：
由于没有
可以使用一定的工作时间，因此您在资源方面更具灵活性仅用于质量检查
，在其他地方无用。能够将某人的“一部分”投入到质量检查中，这意味着您的经理不必面对“我需要花很多钱或什么都不需要花”的决定，而冒险
跟上后者。开发人员正在编写代码并开发旨在支持QA流程的系统，而不是
阻碍它们。
不管是谁在做，在某人专注于
/> QA，他不应该只是在思考“今天，我对
系统进行手动测试，而不是编码”，而是“今天，我专注于我们在哪里遇到质量问题以及在整个过程中我们可以改变什么开发过程以减轻这些负担。”这可能包括：
学习质量检查以提高其技能，测试和试用质量检查工具
，等等。
开发工具和系统来帮助在任何级别上自动化测试
（从客户接受到接受）。
分析当前和过去的质量检查问题，并找出最有效的方法来更改系统以缓解这些问题。这
范围可能从更改开发人员正在做的事情到更改发布过程的一部分。
培训其他开发人员进行质量检查的观点和过程，以便他们减少产生的问题以便QA捕获并使系统更容易捕获QA问题。
我在这里描述的实际上是更通用的敏捷原理的特定用法，该原理适用于DBA ，发布工程师和所有类似的角色
：与开发团队相关的每个人都是“开发人员”
并且应该允许甚至鼓励他们在其专业领域之外进一步了解事物，以便他们可以以多种方式为项目做出贡献。 （换句话说，避免“孤立”。或
让您的开发团队中的某个不应该从事开发工作的人。）为此，您要扮演专家角色，而不是别人，以便质量检查专家“戴上她的质量检查帽”
，而不是仅仅作为“质量检查专家”。 ，
并请某人花时间担任该角色。
不必花费很多时间（在只有两个开发人员的项目中肯定不是全职的），但是您需要确保减轻工作上的压力
另外请注意，您的问题“没有人对我们所有UI和其他系统的领域知识负有责任”
不好，尽管这听起来像是客户角色而不是开发人员角色。敏捷也有类似的解决方案，
，尽管我不会在这里介绍它们。
#4 楼
像许多其他角色一样（尤其是在较小的团队中），实际上没有必要专门扮演这个角色，甚至在某些情况下可能是低效率的。也就是说，就像软件开发的任何其他专业一样，拥有专业知识，兴趣和专注于特定问题领域的时间通常可以使专门人员在培训团队时运用他们的经验来解决问题或增加见解。我工作的许多开发团队都在尝试无QA模型或以与敏捷教练相同的方式使用QA。无论您是否进行自我测试，如果您鼓励团队遵循能够带来更高质量结果的实践，则有很多附加值。
#5 楼
我想争辩说，不需要QA专职成员。优秀的开发人员也是出色的测试人员。是的，在验证所构建的软件是否按预期运行时，您需要学习并练习在构建，破坏和以用户为中心的思维方式之间进行切换。 ）没有专门的测试人员。我担任他们的外部测试教练。他们要比我目前拥有3名测试人员和3名开发人员的现有团队构建质量更高的软件。主要是质量不是整个团队的方法。质量检查滞后。开发人员质量检查问题乒乓球。上下文切换。糟糕的测试自动化。 QA快捷键在发布时间的压力下。质量检查应该什么都没有找到
因此，在发布软件时，您应该期望质量检查没有发现任何问题。极端地故意发送您知道对质量检查有误的代码是非常不专业的。您知道什么代码是错误的？您不确定的任何代码！
Alan和Brent在他们的播客上讨论了此问题，并提出了以下现代测试可行的方法，这也表明专用测试人员可能没有未来：
我们扩展了整个团队的测试能力和专业知识；了解
，这可以减少（或消除）对专用测试专家的需求。
https://www.angryweasel.com/ABTesting/modern-testing-principles /
评论
Niels，我不同意您的观点。对于非常成熟的组织（开发人员和测试人员在两种技能上大多处于同一水平），但对于测试人员不太熟练且开发人员缺乏技能的中小型组织来说，这可能确实如此领域知识和一般测试技能。
– Vishal Aggarwal
19年7月27日在15:23
@VishalAggarwal好，我一直在与人进行讨论。您必须要有一个经验丰富的敏捷团队，他们具有100％的自动化测试和基于数据的决策能力，才能真正被说服。我仍然认为您可以教开发人员，并且在成熟的组织中根本没有测试人员。开发团队应该实践卓越的技术，测试是其中的重要部分，但我确实认为您不需要为此发挥单独作用，也不需要特殊技能：less.works/less/technical-excellence/index.html
– Niels van Reijmersdal
19年7月27日在18:00
#6 楼
专门的质量保证是直接程序员不可或缺的要素，它实现了软件开发的两个关键要素： br />聪明的程序员不会犯错误，所有程序员都喜欢假设自己很聪明，因此程序员不会犯错误...将此与程序员被迫满足的最后期限结合在一起，您会发现讨厌的滚雪球循环，许多小东西被“忽略”，以为它们会在“一段时间后”被悄悄修复。减少了掩盖质量检查的诱惑，因为“需要代码”需要人力资源。
通过保持专注于质量检查的核心团队作为他们的主要工作，他们可以保持自由地进行实际测试和探索软件，并花时间进行长期质量检查。当试图让核心程序员在开发方面进行QA工作时，让QA进行滑动并冒着滚雪球般的噩梦要容易得多。
尽管如此，如果人员不足，并且在代码“完成”和发布之间没有足够的时间，那么让质量检查人员进入“橡皮戳模式”仍然太容易了。人手不足和支持不足的QA团队也是通向滚雪球噩梦的道路。它们有助于在流程的早期阶段突出问题，从而节省项目时间和金钱。纠正可能占用几个月开发时间的缺陷。
#7 楼
根据我的观察，专门的质量保证将有助于以下过程：1）质量保证可以帮助开发团队捕获不同的故障情况和系统故障。
2）如果质量检查官是与初级开发团队一起工作的最高级人员，那么他可以指导团队构建项目或流程。
3）由于开发团队需要在不同的模块中工作QA可以在组件和系统的集成中找到问题。
4）如果QA是产品专家，那么它将帮助开发团队快速获取信息，而不必等待来自业务团队或产品负责人
#8 楼
为避免重述其他答案，这将是简短的。如果有一个单独的团队，则并行进行。许多开发人员对此并不熟练。在测试/调试自己的软件时，您会了解其内部工作方式。目标用户没有。这使得自检有些不切实际，尤其是对于文档中的缺陷。
评论
我认识的大多数质量检查人员都比与他们一起工作的开发人员昂贵。您会期望优秀的开发人员能够更好地报告缺陷，因为他们知道他们需要修复哪些信息。您无法测试自己的作品是一种过时的论点。
– Niels van Reijmersdal
19年7月25日在14:22
老旧的用什么方式？我的意思是，在缺陷检查中，您的想法和方法是不同的。开发人员知道如何解决问题，并解释/记录不同的事情。 （IME，编程技能和沟通技能在人们中成反比）
– bobsburner
19/07/25在14:32
好的程序员是好的沟通者。 “如果不能用英语写下来，就不能编写代码。” （Peter Halpern，《编程珍珠》，CACAM，1985年9月。）“ Joel Spolsky在这里和这里都说，母语写作技能是程序员要学习的三个最重要的知识之一，并且“我不会雇用程序员除非他们能用英文写得很好。”
– cjs
20-4-14在2:29
#9 楼
对于您的团队规模，合适的QA成员可能不合适。但是只有三个“ IT专家”，包括两个开发人员和一名测试人员，情况并非如此。在预算，时间表方面，他们可以与“资深开发人员”和“资深建筑师”进行交流。和优先事项。这不仅是职称，还是薪酬规模和在公司结构中的影响力的问题。一个孤独的测试人员只是一个测试人员，而不是经过认证的测试经理或部门负责人或任何其他人。这意味着您正在制造某种对抗性的局势。这样，质量检查人员就无法向开发经理报告，它必须是向链中更高层人员的直接报告。对团队进行质量检查”，然后告诉其他两个人不是。他们将减少测试，而提供更多未经测试的代码。而且如果孤独的测试人员有假期或病假，那您就会有问题。我相信测试自动化是团队开发人员的工作，如果您有这样的专家，可以与测试分析师合作。让开发人员也进行手动测试是极大的动机来自动化可以自动化的东西，而不是将其视为其他人的问题。
#10 楼
如果您在IT方面做得很认真，我认为最好让QA领域的专家检查您的代码。否则，您冒着将损坏的软件交付给客户的风险，这将导致负面的反馈循环（交付不良软件->激怒客户->您获得的新客户减少->您交付不良软件-> ...）。此外，如果在开发软件时将SCRUM用作项目管理，则不再有质量检查测试人员的角色。测试人员只是开发团队的一部分，因此被认为是这样的（在恕我直言中，这是非常好的，也是合乎逻辑的）。这应该是一个标准，但是要达到这一点，行业需要一些时间。 :-)
评论
简而言之，质量检查比开发人员便宜，并且在质量检查方面比开发人员技能更高。这就好比问您为什么要聘请会计师来管理会计，而不是让开发人员去做。开发人员不适合进行质量检查的方式与不适合会计的方式相同。@Stephen与“比开发人员更熟练”不同意。我认为您的意思是，它们并没有被我们强加给开发人员的“架构”和“编码标准”这种疯狂的想法，这使他们能够以与开发人员完全不同的方式与软件进行交互。 br />
@Aron因此，他们比开发人员在完成要求他们做的工作（QA）时更有能力。不管是什么原因，质量保证专家都比主要工作是开发的开发人员更擅长执行质量检查任务。
如果两个开发人员需要专门的质量保证，最好都是金童子，并编写一些非常好的代码来执行航天飞机之类的事情。我会假设您不是，而您不是，那么祝您好运，说服您的经理，您的劳动力中应该有1/3是辅助人员。 “合理化”是该职位中最重要的词；如果由于错误的代码而没有危害健康和安全或公司的声誉，那么雇用更多人的唯一理由就是赚钱的前景。
@Mazura公司的声誉受到威胁。