在进行质量检查之前，为开发人员进行跨浏览器测试的分界线

#1 楼

TL DR：建立基线，修补程序并做出反应。
通常，开发人员不必过多担心跨浏览器测试。是的，这是个问题，是的，他们需要意识到这一点，但我会尽量减少。让他们首先专注于出色的功能，而不是让开发人员不必在意质量（因为他们应该完全在乎！），但总的来说，他们应该将其交给专家。
但是，在明显的情况下，他们会应该。如果他们要修复特定于浏览器或浏览器版本的错误，显然他们需要在该浏览器和版本上进行测试。理想情况下，在这种情况下，它们也可以检查其他浏览器，因为跨浏览器错误很可能在修复它们时会产生其他跨浏览器错误。这显然表明开发人员必须要做一些工作。快乐介质在哪里？唯一的答案很大程度上取决于您的个人组织。您只能通过不受控制的实验来了解这一点。
首先进行很少的跨浏览器测试（通常，以及其他类型的意外开发人员测试）。在收集了一些冲刺或发布的指标之后，确定可以更快地捕获这些错误的测试类型。可能是跨浏览器测试。可能只有一两个浏览器经常引起问题。可能是与某个其他系统交互的接口。修改开发人员遵循的测试脚本，以包括那些特定类型的测试。然后等待，看看您在这些地区的房价是否大幅下降。而且重要的部分很重要。如果您将开发人员的测试时间增加了10％，而该区域的bug却减少了10％，那是一种损失（因为开发人员的时间本可以花在专门的质量检查人员身上，而他们可能会抓住更多的时间） ）。如果您在该区域下降了50％，突然它会开始获得更多收益。但是我认为没关系。这是对您的组织最有利的事情。
阈值的确定取决于组织所花费的成本，包括修复错误的速度，报告错误的数量，以及更重要的是日程受到影响。 （这是目标，对吧？减少错误，使开发人员不必花费时间重新编码已经完成的工作？）
像SQA中的很多事情一样，您必须建立基线，调整并做出反应。

#2 楼

这是一个好问题，没有“正确”的答案，因为有很多因素在起作用，而正确的答案取决于您的个人情况。

要考虑的因素是：


developer：qa比率
developer组规模
公司规模和资源
应用程序中的javascript数量
当前浏览器对软件的使用情况
使用本地浏览器
UI测试的自动化和持续集成
使用替代驱动程序运行自动化UI测试的能力
用于跨浏览器测试的工具及其可用性
开发人员可以使用的工具轻松的跨浏览器测试
开发人员可以花时间不对后端进行编码
可以使用其他浏览器驱动程序运行自动UI测试的功能

我称之为“ dev-qa幻灯片” ';）