为什么开发人员不应该成为唯一测试其代码的人的实际数据？

#1 楼

似乎没有很多研究数据。这是我发现的：

等待构建：测试人员会花时间吗？
2014年）：


59％的被调查者，所有可用选项中百分比最高的
表示他们希望进行的一项活动他们可以花更少的时间来做……“等待测试资产”。 Dagger。


这也是我过去作为手动测试仪的经验。当您发现一些阻碍测试的严重缺陷时，情况甚至会变得更糟。您需要将其交还给开发团队，然后等待下一个可测试的版本。

快捷方式：

我已经读了一段时间了（但找不到）它表示），随着他们的公司改用专门的质量检查小组，其产品的整体质量开始下降。由于开发人员认为测试人员将对其进行全面测试，因此开发人员停止了大部分测试工作。他们的工作仅差一点，因为他们没有立即发现明显的问题。测试人员比开发人员承受更多的时间压力。他们落后了，而公司想出货。测试人员开始采用越来越大的捷径，丢失了越来越重要的问题。

就个人而言，由于上下文切换而忘记了单独的团队发现的问题很难解决，而忘记了该功能被建。这应该可以用数据证明：关于多任务和上下文切换的研究很多。

公司正在削减他们的QA团队： br />未知

专用质量检查小组：

只要成员是专门的软件开发团队的成员，我都属于质量保证小组。他们在整个团队中为质量和质量建立提供帮助。最好帮助团队进行测试优先实践。

但是拥有一支专业的测试团队，您会将可测试的产品移交给……那感觉真是恐怖，我希望以后再也不会经历。

我喜欢蜂拥而至。汇总需求，聚集架构和设计，聚集以创建自动化测试和代码，聚集以重构然后聚集探索性测试会话。

培训：

您可以训练开发人员在构建思维和批判思维之间切换。对产品进行评论只是另一种心态。大多数开发人员足够聪明，能够掌握这些技能。您只需要激励他们，这很重要。我真的相信，优秀的开发人员也必须是优秀的测试人员。

#2 楼

免责声明：此答案完全基于个人的轶事经验。

在我作为软件开发人员的10年里，我知道4种不同的情况：测试员（本人除外），
另一个团队的测试者，大延迟（周），
另一个团队的测试者，短延迟（小时），
同一团队的测试者，短延迟（小时/天）。

请注意，单元测试总是在我的尽头，而由测试人员负责手动或自动的高级测试。

扰流器：对交付质量的主观评估已告知我列出情况的顺序。


测试仪

首先，根据我的经验第二双眼睛是非常宝贵的：



对规格/要求的不同理解有助于识别歧义（因为测试人员期望的输出与开发人员期望的有所不同），
人们只是考虑要执行的测试。

t，作为一名开发人员，如果我想到了一个极端的案例，那么我的代码将会处理，而我的测试也会显示出来。但是，问题是我没想到的极端情况。

其次，专业的测试人员会发展出可能出错的直觉，而我（唯一的）数据点就是他们在遇到的情况下更加恶毒（比我想象的要多得多）。因此，对于提高项目质量，专业的测试人员是无价的。


延迟

也许很简单，但我的最佳经验是测试人员可以快速进行测试的时间。

由于降低了生产率，但是我的经验也降低了质量。

对数据流，特定问题等的记忆力越强，修复时我越有可能一个错误，请：


请避免引入另一个错误，
考虑潜在的其他错误情况并予以解决。

这意味着缩短生产和反馈之间的延迟不仅可以提高生产率，而且可以提高质量。他们对我们

我没有遇到个人问题，但是我经常碰头反对不同的优先事项。 ，这意味着没有人可以快速测试我的交货，然后...它带来了延误及其所有后果。甚至导致功能在生产中交付，然后再经过质量检查。我想它可以帮助开发人员保持警惕……但我不建议这样做。


参与

总体而言，我最好的经历是

从一开始就让测试人员参与进来：


该软件旨在促进测试，
如有必要，将仅测试要求纳入设计中，
参与设计时，测试人员会了解预期的功能和要求（超出书面规范），
位于附近开发人员可以随时要求澄清。

后一部分对提高我正在研究的产品的质量很有帮助。

如果您可以与测试人员/分析师要求澄清，您可能会这样做。如果可以给他们打电话，那可能很好。如果需要电子邮件...您可以这样做...但可能不需要。因为您现在正在编写代码，并且在他们阅读电子邮件并回复之前，您不会暂停。这是澄清某些事情或假设“现在”之间的区别……我们都知道结果如何。

反之亦然。因为不清楚如何使用您的代码，所以不必等待测试的实现，现在您可以更轻松地进行回答。而且，回复越快，切换到另一个任务时就越不可能将您的测试放到后面的燃烧器上。在一天之内，一个人做出的澄清并不是世界末日，而每天引入一次的bug则明显降低了质量。最后，我的经验是，拥有专门的知识渊博的测试人员可以带来最高的质量：


从头到尾参与其中，
非常接近，
提供反馈很快就可以了。这并不一定意味着要由同一个人举报；我公司当时使用的项目团队将来自不同实际团队的人员召集在一起，并将他们聚集在同一办公室。

#3 楼

TL; DR：开发人员编写自己的单元测试。如果您希望其他人关注单元测试代码，那么代码复审就是答案。

编辑：OP澄清了一个问题：关于e2e测试。对于e2e测试，可以使用单独的开发人员团队，但是会增加各种挑战。

相关问题：测试人员对软件的看法与开发人员的看法有何不同？

质量无法购买，但必须付出代价-没有捷径


没有研究，只是常识。

开发人员应该编写自己的单元测试（并修复损坏的单元测试），因为最新的开发人员最了解

使用不同的QA测试团队编写和修复单元测试是没有意义的，因为他们将必须学习开发人员刚刚学到的知识并做到了（开发人员已经在操作记忆中），问他们很多问题，原因（可能造成误解）。只是巨大的重复劳动，就完全浪费时间。所有这些问题都应在代码审查期间提出，并由原始开发人员解决。

单独的QA测试人员（如果使用，则很大）最适合编写系统/集成/ e2e测试，因为这些测试可能（也可能不会）从不同的眼中受益最大，可能使用不同的未说假设，有时使用不同的编程语言：核心开发人员可能更关注性能，而QA e2e测试人员则更关注生产率（如果进行测试，出于有效的商业原因，需要更快地运行，购买更多服务器并并行运行测试。）

但是，开发人员通常也在编写系统/ e2e测试，因此他们可以修复UI中的任何更改，因为他们最熟悉这些更改（不足为奇：原始开发人员无需调查更改的内容）。


端到端测试是完全不同的动物。有了这些，第二双眼球可能是有益的。

同样，没有学习，只有现实生活中的经验才是最困难的：靠自己的汗水和鲜血:-)

在我们公司中，我们使用所有三种方法：


开发人员还编写e2e测试（维护用FitNesse编写的测试，旧的本地自动化框架以及使用新的本地框架增强Selenium WebDriver的新测试）。
独立的测试自动化编码器（仅一个:-(）赶上原始开发期间未开发的e2e测试（业务决定采用捷径）
测试使用混合方法和结对编程开发。

自动化测试仪（me）开发了用于页面对象测试的内部框架，并使用了该框架的助手功能，从而简化了代码并提高了生产率，但是e2e测试依赖于所有语义上重要的页面元素的便捷可靠的定位符（ID和名称），这是问题的根源。

您可以想象，开发人员不喜欢学习其他框架即使提高了编写端到端测试的效率，也可以正常工作。

OTOH，在回填测试时，有时会缺少方便的定位器。解决方法是使用不稳定的XPath定位器（解决所有涉及的问题-更好地避免），花费更多时间开发CSS定位器，或要求开发人员在现有代码中添加方便的定位器（名称/ ID）。

添加定位器很容易，但是很难安排。可能要花费数小时或数天的时间（取决于开发人员的工作量，合作的意愿以及切换上下文的能力），并且测试必须等待这些新的定位器（并迫使他们在等待改进的定位器时切换上下文），因此需要添加定位器需求方法远非最优。

最好的方法（根据我们的经验）是用于e2e测试开发的配对编程（将自动化测试仪与开发人员配对），以开发新页面的页面对象，并进行触摸页面上许多/大多数小部件的冒烟测试。自动化测试员知道自动化部分以及如何做到这一点，开发人员知道如何在需要时添加定位器。使用这种方法，添加定位器并在测试中使用它只需几秒钟，而不是数小时或数天。

但是如果没有这个“成对的”步骤，开发定位器将使自动化测试人员感到沮丧：


要么花费很长时间等待和交换上下文，
花费大量时间使用CSS和其他可用属性设计位置策略，
或使用易碎的XPath。

我们正在使用e2e测试过渡/设置/改进页面处理过程使用Selenium WebDriver。带有Angular的单页应用程序页面使其更加复杂。

角度和单页面的应用程序设计模式也打开了另一种蠕虫病毒：当UI设计更改后页面失败时，谁负责修复e2e测试。

我的感觉是，测试应至少分为两组：烟熏测试，由上述配对编程开发。测试失败（更改的定位器）主要由UI开发人员自己解决。
更复杂的测试，由质量检查测试自动化团队开发和维护。测试自动化。

采用“扔掉”的方法（在没有体面的定位器并且无法快速方便地添加必要的定位器的情况下，页面被丢弃在QA自动化中），QA自动化的生产率将非常低，测试将变得脆弱且不可靠，并且反对端到端测试，因为这样做会浪费大量资源。

加上使用具有较低水平技能的自动化测试仪的诱惑，灾难是不可避免的，正如我们每天在此论坛上提出的问题所看到的那样，更好的定位器和琐碎的问题可以轻易地回答这些问题编程技能。

#4 楼

免责声明：不是硬数据，而是个人经验中的一些东西。

我们的产品之一是AngularJS应用程序，其前端由多个UI JavaScript开发人员开发。我们的JS方面是成千上万行JavaScript，而没有一个单元测试。 UI开发人员在被问到原因时可能会提供的解释之一是“我们没有时间”。换句话说，我们的开发人员没有参与任何测试活动。

我们的质量检查团队正通过添加更多端到端浏览器自动化测试来弥补单元测试的不足（我们目前有大约一千个），这基本上颠倒了著名的金字塔。

这会产生多种后果：


我们经常有一个手动测试期当我们（质量检查小组）发现一些琐碎的问题，而这些问题很容易在单元测试中被发现时，
有时这类问题会使分阶段升级和生产进一步发展，从而导致端到端测试的修复成本更高
真的很慢而且容易出错
经常需要研究端到端测试失败以找出真正的原因-反馈循环真的很慢
我们还存在一些交流标记更改的问题

#5 楼

从经验中，我发现开发人员在测试代码的功能方面非常有效，但在测试代码的功能方面却不那么出色。

我想到的第一个示例是我设计的GUI。我测试了日光，尽管它是完美的。将它带到我的客户面前，他花了10秒钟使系统崩溃。他对此很友善，但是后来，我不得不弄清楚为什么我测试过的系统如此惨重地失败了。我会做


单击按钮1-确保它确实X
单击按钮2-确保它确实Y
跳过按钮3-我知道它不会还没工作
单击按钮4-确保它确实为Z

当我知道按钮3坏了时，我怎么想念按钮3？好吧，我在构建过程中做了很多次测试，因此养成了习惯。我知道按钮3不需要工作，所以我一直跳过它。然后，当它需要工作时...我一直跳过它。

我可以采取很多方法来解决此问题（从一开始就进行自动测试），但是轶事强调开发人员测试的主要挑战：我们知道代码的作用。在我们的脑海中，是一个巨大的思维模型，涵盖了代码块正在做的所有事情，我们在测试过程中下意识地利用了该模型。积极地这样做。很难从您自己的模型中退后一步，并且要从空白处着手软件。这就是我们进行代码审查的原因。

评论

---

+1 ...这就是为什么您需要另一个人的头脑来阅读要求并检查代码是否满足要求，并且可以处理诸如无效输入之类的意外情况。其中一些测试也可以自动化。

– Peter M.-代表莫妮卡（Monica）
17年8月7日在19:56

---

#6 楼

当处理复杂的事物时，总是存在大脑思维部位偏见，盲点，隧道视力和压力导致的故障
的风险。 （尽管是一本好书，尽管来自IT领域之外，但作者是Matthew J Sharps着，《压力下的处理》）人或反对者，请换个角度看一下并保护自己的后背。
用于代码，还用于购买房屋的新油漆，购买新的西装
或写重要信。

/>这需要一个环境，让这位拥有标题的朋友
*尊敬的敌人*可以在不被斩首的情况下工作。
许多价值数百万美元的电影都因为导演
而失败，
接受是的人来审查想法。

让同事的开发人员进行测试是可能的。进入测试人员或测试人员角色。鲁ck的牛仔”，最终用户都将其视为“来自火星的极客”，最终用户将被视为“那些（愚蠢的）最终用户”，...那么，什么也无法保存产品。

测试人员是一部分一个团队，通过短线沟通，每个人都对创造质量感兴趣并致力于创造质量。

#7 楼

几年前，我已经对测试进行了相当广泛的文献研究，特别是关于测试的好处。我没有按照您的要求（开发人员还是测试人员）进行科学研究，但是我确实遇到了一个非常有趣的科学研究：Mäntylä，MV和Itkonen，J.，“更多的测试人员-人群规模和时间限制的影响软件测试中”（2013年），信息与软件技术55，第986-1003页，2013年。总的来说，使用10h会比使用9.9h“的非时间限制的测试仪多发现71％的缺陷。测试人员是学生，他们执行手动测试。尽管有一些限制可能会因实际的测试过程而有所不同（举几个例子：学生，没有自动化，有时间限制，背景信息可能更少，本身不是端到端测试），但它仍然表明一个人在测试中非常有帮助。

总而言之，即使总测试时间相等，与开发人员和测试人员相比，只有开发人员才能（最有可能）发现较少的缺陷。