#1 楼
专用测试员我认为重要的是要强调，成为测试员的角色与成为测试员的工作不同。需要测试，但您根本负担不起或无法拥有专门的测试人员，即100％的时间有工作的人。
您只是没有足够的测试，或能够证明专用测试人员费用合理的资源（例如2人启动）。
您所在的组织中，您积极地练习角色合并，即UX或PM可能扮演测试角色。 />您可以使用业务分析师来执行测试
所有非常有效的理由，即没有专用的测试人员。是的，专业的测试人员是首选，但这并不意味着它们总是合适的。测试人员在某些情况下。我认为功能团队方法是一种更好的工作方式，在这种方法中，测试人员是与开发人员并列的一个角色。一个单独的质量检查团队可以建立我们与他们之间的心态，这是不健康的。
#2 楼
我一直希望有一个独立的，专门的，有能力的测试人员来测试我的代码。但是，我也总是希望有个人厨师为我做饭。通常，我通常也负担不起。对我来说，我经历过几次，那真是太好了。拥有一个还没有能力的独立测试人员来测试您的代码非常可悲。不用了。
评论
Ya知道...由于某种原因，在我发表这一评论时，看到James Bach仅代表91令我感到奇怪。
– TristaanOgre
2011年5月23日13:24
#3 楼
Nikita，团队首席执行官Joel Spolsky认为需要专门的测试人员。Joel雄辩地写了关于测试人员的需求（以及什么才是优秀的测试人员）。
实际上，Fog Creek似乎正在尝试雇用一个或多个测试人员来支持StackExchange。
可以使用出色的软件由没有专门测试人员的小团队制作？是。
这是个好主意吗？不一定（尤其是随着应用程序变得越来越复杂）。
StackExchange的创始人是否主张在没有一个应用程序的情况下构建像StackExchange这样的应用程序？否。请参见下文：
评论
为什么不行？我不认为“因为Joel Spolsky这么说”和“ ps他们正在招聘”确实回答了这个问题
–布鲁斯·麦克劳德（Bruce McLeod）
2011年5月20日14:17
布鲁斯，我不同意。原因如下：如果问题是“我想知道什么时候缺少专职的质量保证人员不会不会导致交付软件的质量下降？” ...我同意您的观点（并且可以接受您的否决投票的有效性）。但是，这并不是全部问题。问题开始了：“我突然想到，stackexchange团队中没有专门的QA。由于他们确实在生产出色的产品，...”因此，恕我直言，这些参考文献极其有效。
–贾斯汀
2011年5月20日15:34
而且Joel显然不认为聘用测试人员时的经验很重要-“（不需要）特定的测试经验”。另请参阅：strazzere.blogspot.com/2010/04/…
–乔·斯特拉泽（Joe Strazzere）
2011年5月23日12:08
@Joe-知道SE团队在Alan测试中的表现会很有趣！ sqa.stackexchange.com/questions/59/…
– testerab
2011年5月23日14:18
@testerab那是一颗宝石！我很想亲自看看！
–corsiKa♦
2011年5月27日19:37
#4 楼
因为他们确实在生产出色的产品，所以我想知道缺少专职的质量保证人员会不会导致交付软件的质量下降吗？
何时可以没有专用质量检查的出色产品，就可以了。
有些可以。许多不能。
#5 楼
我认为这首先取决于产品，其次取决于团队（严格按此顺序）。如果您有软件开发人员愿意将测试视为其角色的重要组成部分，并且您拥有良好的单元/集成测试策略，并且您的用户愿意接受质量稍低的产品，那么没有专门的测试团队也可以接受。请记住，堆栈溢出正在制作一个很棒的产品，但最终，它还是一个相对简单（当然不是关键任务）的Web应用程序。
另一方面，如果没有专门的测试团队就无法发布医学或军事项目，我将对此表示严重担忧。
#6 楼
如果您的质量已经足够好，可以没有专门的测试人员。当然，这意味着您必须承担风险，即在您决定需要添加专用测试仪之前，您会经历质量不够好的时期。没有专用的测试器可能是出于预算原因。我为一家拥有三名开发人员和一名测试人员的初创公司工作。我们从一开始就拥有测试仪，它具有优势，但是这意味着在进行任何测试之前都要先付他们的薪水。
#7 楼
我同意这里的大多数答案，即任何人都可以成为测试人员。但是，测试人员和其他软件开发人员的思维方式有所不同。并不是说开发人员不能分享这种思维定势，而是在这里查看问题。对于一支专门的团队，虽然可能没有必要，但测试人员和开发人员之间需要有某种隔离至少由管理层/团队负责人负责。测试人员应该与开发人员分开负责，原因是，尽管我们尽量不对开发人员“面对面地哈哈”，但人是人，如果您需要始终指出自己的领先优势，那么他们的代码就糟透了，这几乎是利益冲突。
#8 楼
有人提到，一个单独的质量检查团队可以建立“不健康”的我们与他们的心态。我希望对此有所不同。如果您可以负担一个单独的质量检查团队，那么我建议您有一些专业的“他们和我们”。他们和我们不必讨厌或不合作。他们和我们可能具有建设性。竞争可以非常富有成效和建设性地进行。
如果您在一个专业的团队中拥有专业的测试人员，那么您将永远拥有他们和我们。但是，优秀的测试人员将始终与开发人员保持建设性的合作。而且，这通常意味着良好的工作关系。良好的工作关系可以帮助每个人交付高质量的代码。
#9 楼
关于这个主题，GTAC 2011上有一篇精彩的演讲：http://www.youtube.com/watch?v=X1jWe5rOu3g摘要：质量检查已死。新的范例是开发人员进行更多测试。
评论
好的答案通常不只是一个链接。你能总结一下谈话吗？
–杰伊·巴祖兹（Jay Bazuzi）
2012年1月17日23:40
我认为那不是他的意思。相反，我认为他说：“在以抓地模式运行的精益Web初创企业的背景下，正确构建软件并不比构建正确软件重要。只有提前发布，您才能了解是否正在构建正确软件。而且经常，不要拖延测试。”
–杰伊·巴祖兹（Jay Bazuzi）
2012年1月31日下午2:45
同样，“一旦发现自己正在构建正确的软件，就需要提高质量，但是您将继续快速迭代。”
–杰伊·巴祖兹（Jay Bazuzi）
2012年1月31日下午2:48
#10 楼
除了单元测试（这是编码的一部分）之外，我还看到拥有专门的测试团队的两个最重要的原因。我只是不相信开发团队那么好，所以不需要独立测试。
当压力到来时，让同一个人同时做这件事，以及无论角色分离如何，都将简单地转化为：更少的测试，更多的编码……这是灾难的根源。
话虽如此，同一个人可以设计+代码+使用（=测试）的（小）事物可能会有例外，例如一个小型网站。
#11 楼
始终如此。产品出色的事实仅表明，如果有专门的测试团队，产品会更好。
#12 楼
恕我直言，当开发人员同时进行开发和测试工作时，您不需要测试团队。优点是开发人员为可测试性和据说也为可维护性设计和编写了更多代码。当然，质量也不会被视为“由其他人（测试团队）完成”的“额外的东西”。评论
这样做有两个问题-第一个问题是大多数开发人员缺乏测试技能和专业知识，第二个问题是真实的系统测试通常需要基础架构，而需要有人100％地维护它。
–Rsf
2011年5月19日在8:16
在开发人员正在测试自己的代码的情况下，这可能会很困难，因为他们知道自己编写的内容及其功能。他们对预期的行为有偏见，可能不会想到事情或做出假设，即从编写代码中除名的人会继续前进。
– CKlein
2011年5月19日在12:33
是的，开发人员必须学习一些新知识。我认为这比其他任何事情都更积极。
– binary_runner
2011年5月19日在12:34
是的，今天大多数单元测试的创建都是由开发人员完成的，但这正在改变一些情况，因为从纯QA（无编程背景）的资源转移到了QA / Developers（选择更加关注QA的开发人员）。这些QA / Dev仍仅执行QA，但它们使读取和编写代码的能力不仅与开发人员一起进行，而且可以创建集成测试，这些测试可以构成自动接受测试的基础。这是QA / Developer可以帮助项目的一个示例好处。
–约翰·伯利（John Burley）
2011年5月19日23:27
“恕我直言，当开发人员同时进行开发和测试工作时，您不需要测试团队。好处是开发人员可以为可测试性设计和编写更多代码”。可测试性。
–乔·斯特拉泽（Joe Strazzere）
11年5月23日在13:07
评论
回复：专用团队。这种对抗方法不是必要的吗？尽管我作为测试人员希望保持开发人员的良好风范，但同时也需要将责任制分开。测试人员在主管级别上需要他们的拥护者，而从本质上讲，他们不会与开发人员并肩工作，因为有时测试人员需要具有测试人员心态的人向开发人员争辩他们的情况。
– TristaanOgre
2011年5月20日下午14:50
@TristaanOgre回复：敬业的团队。测试人员仍然有一个测试经理，由他或她管理，但是他们与开发人员“齐心协力”，为共同的目标而工作。
–布鲁斯·麦克劳德（Bruce McLeod）
11年5月22日在9:51
我非常同意。不幸的是，我还没有在实践中经历过。
– TristaanOgre
11年5月23日在12:32
我曾在测试和开发人员向同一位经理报告的团队中工作过，而在我们向不同经理报告的团队中工作过。以我的经验，分离越大，政治越多，这使测试人员的工作变得更加困难。如果有选择，我现在总是选择与开发人员一起嵌入。
– testerab
11年5月28日在23:35
@testerab经理也嵌入在团队中，另一个经理的同伴也是如此。因此，没有他们和我们，只有不同的重点。
–布鲁斯·麦克劳德（Bruce McLeod）
2011年5月29日0:56