QA与开发比率 [英] QA to dev ratio

问题描述

我们有一个相当复杂的Java系统，其中包括一些后端层，包括数据库和专有的Swing前端。外部各方可以附加的后端API模仿我们的前端。我们的组织内共有大约5个孤岛，共享这个系统。总共有大约15名开发人员维护这个系统。

We have a pretty complex Java system which includes a few back-end tiers including a database and a proprietary Swing front-end. There are back-end APIs to which external parties can attach that mimic our front-end. There are approximately 5 silos within our org that share this system. In total there are around 15 developers maintaining this system.

我们的QA团队应该有多大的经验值？

Is there a rule of thumb on what the size our QA team should be?

编辑：根据迄今为止在回复中提出的问题添加一些上下文：

To add a bit of context based on questions raised in the responses thus far:

1. 我们每年大约有四个主要版本，中间还有一些小版本。


2. 我们的平台有转手钱，所以那里是对客户意义重大的计算方法。


3. 我们确实使用正式的bug修复系统。


4. 我们不使用TDD。


5. 我们使用cruisecontrol等工具进行持续集成。

1. We have about four major releases a year, and a bunch of minor ones in between.
2. Our platform has money changing hands, so there are calcs that mean a lot to our customers.
3. We do use a formal bug tacking system.
4. We don't utilize TDD.
5. We use tools like cruisecontrol for continuous integration.

推荐答案

作为以前的测试团队负责人，我建议尽可能多地进行测试。听起来您组织中的很多人都依赖于您的软件。经常测试并经常测试。

As a former test team lead, I would suggest having as much testing as you can. It sounds like a lot of people in your organization depend on your software. Test early and test often.

认识到测试是每个人的责任是非常重要的。开发人员需要编写好的单元测试。 UI开发人员应该手动测试用户界面。

It's very important to realize that testing is everyone's responsibility. Developers need to be writing good unit tests. UI developers should be manually testing the UI.

我尝试鼓励测试驱动开发，关注指标（使用正式的错误跟踪系统，跟踪缺陷密度等） ，设置持续集成服务，并设计可测试性代码（使用Spring之类的框架进行依赖注入，使用模拟和存根进行外部服务等等 - 我很乐意更详细地讨论）。修复bug的成本会在你找到它之后成倍地增加，所以最好在它进入正式QA之前找到它。

I try to encourage test driven development, keep eyes on metrics (using a formal bug tracking system, tracking defect densities, etc), setup a continuous integration service, and design code for testability (use a framework like Spring for dependency injection, use mocks and stubs for external services, etc - I'd be happy to discuss in more detail). The cost of fixing a bug gets exponentially more expensive the later you find it, so it's best found before it gets to formal QA.

Jeff

这篇关于QA与开发比率的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！