gbj*_*anb 16
恰恰相反.发展应向质量保证部门报告.
如果您认为质量保证部门是您的客户(注意:质量保证,而不是测试)那么您会做得很好.错误将得到修复,产品将发展到良好的标准,开发将意识到他们在那里为业务和代码产品提供相应的服务.
然而,公司政治以其他方式提供资历,因此如果你有一个QA部门,那么一般来说,开发对于较小的QA部门来说会变得更加高级.
编辑:一个小小的附录来解释我自己:在我工作过的一家公司,我们有一个"模型办公室",它被设置为一个客户网站.我们构建安装程序CD并将其交付给QA团队,QA团队将其安装到一组干净恢复的计算机上.如果以任何方式出现问题,我们将向用户报告,我们必须在构建另一张CD并重复此过程之前修复它(显然,取决于错误的严重程度).起初我认为"这将是地狱",它只是...但只有几次迭代,然后开发人员得到了消息,并确保这些CD工作,并且它安装的软件工作.
我现在的公司需要这样的东西,来自网站的反馈是通过邮件列表,安装程序通常不能完全正常工作,有时缺少依赖项,并且一次又一次地出现相同的安装问题.与质量保证部门相比,这里的质量很差,因为质量保证部门确保以前工作得很好.在这里,我们有一个开发驱动的小组,他们总是专注于下一个版本,新功能.质量保证始终关注当前发布的现有产品.它对最终用户获得的东西产生巨大影响.
因此,即使质量保证部门确保质量可以接受,我仍然认为应将其视为开发"报告"的客户.
我认为这取决于谁负责提供适当质量的软件.如果是开发组,则QA应该是其中的一部分,其中开发决定QA所需的资源与开发所需的资源.
另一方面,如果它是技术部门,那么它们可能是平等的,既可以向主任或CIO或CTO报告,也可以通过平衡两个组的需求来达到资源分配决策.更大的目标.
如果QA部门推动了开发目标,那么开发向QA报告可能是有意义的,尽管它肯定是不寻常的.
如果QA是组织内部的特定实践,而不仅仅是开发过程的一部分,那么它可能不应该向开发组报告,但在许多情况下围绕内部应用程序开发,QA并没有被赋予重要性.
在我一年前工作过的公司里,在我看来,我曾经见过最好的开发实践,QA和开发并肩工作.两者都是平等的,但QA有责任发布和支持已发布的代码,例如:如果在现场发现代码问题,并且几个第一级支持无法修复它,它将首先到达QA修复,然后才进入开发