深度指南
QA 与迭代瓶颈模拟器：当开发速度超过测试能力
行业管理层分析
软件团队就是一条流水线，而流水线的发布速度不可能快过它最慢的环节。当开发人员完成的功能多于测试人员能够验证的功能时，多出来的工作不会消失，而是加入一个队列。管理者看到忙碌的开发人员和满满的迭代看板，就断定团队很有产出。但一项已经构建却没有测试的功能没有赚到任何东西，而且每多等一周，它的价值就减少一分。在这种情况下增加开发人员，只会同时提高薪资总额和队列长度，而已发布的产出原地不动。
这个问题的结构是两种速率之间的差距。开发产出是开发人员数量乘以每人完成的功能数。QA 产能是测试人员数量乘以每人能验证的功能数。已发布的功能是二者中较小的一个，两者之差就是队列增长的速率。由于队列月复一月地累积，它的成本不会保持不变，而是不断积累。一个略微超出产能的团队，在第一个迭代里看起来一切正常，到第六个迭代却明显出了问题，这就是为什么这个问题在变大之前很容易被忽视。
多米诺效应展示了这个序列。较高的开发产出让所需 QA 产能的占比超过百分之百。这种负荷使队列增长，拖延了排在它后面的每一项功能。等待直接损耗价值，同时还通过缺陷修复和疑问把开发人员拉回旧的工作中，使他们的时间消耗在上下文切换上。不堪重负的测试人员匆忙行事，更多缺陷漏网。每一环都推动下一环，所以第二格里的小幅过载，几个迭代之内就可能让最后一格变红。
冰山把薪资总额与瓶颈的成本区分开来。水面之上是开发人员和 QA 的薪资，人人看得见。水面之下是四项很少单独列示的成本：功能等待期间损失的价值、因测试仓促而流入客户手中的缺陷成本、开发人员因上下文切换损失的时间，以及测试人员在过载下的加班。它们合在一起，可能超过本可以消除这些问题的那一名额外测试人员的成本。用这个模拟器找出您的流水线无法回本的开发与 QA 比例，然后将其与增加一名测试人员作比较。
公式与方法论蓝图
模型按月、在稳态下计算。开发产出等于开发人员数量乘以每人完成的功能数。QA 产能等于测试人员数量乘以每人验证的功能数。已发布的功能是二者中较小的一个。队列每月按差额增长，六个月窗口期内的平均队列是该增长量乘以六的一半。延迟成本等于平均队列乘以延迟成本单价。每有一项排队的功能，开发人员就损失 1% 的时间用于上下文切换，上限为 20%。漏网缺陷随过载而增加。
- 开发产出
- P = 开发人员 × 每人完成的功能数
- 每月完成并移交给 QA 的功能数。
- 已发布功能
- S = 取较小值(P, 测试人员 × 每位测试人员验证的功能数)
- 流水线只能发布测试所验证过的内容。
- 队列
- Q = 取较大值(0, P − 产能) × 3
- 六个月窗口期内等待的功能的平均数量，因为队列呈线性增长。
- 漏网成本
- E = S × (3% + 15% × 过载) × 4,000
- 随着 QA 过载而增加、流入客户手中的缺陷，每个缺陷的成本为 4,000。
- 流水线结果
- Net = S × 价值 − 薪资总额 − Q × 延迟成本 − E − 上下文切换税 − QA 加班
- 月度结果。盈亏平衡的负荷就是该值降为零之处。
层层传导的弹性
开发产出与 QA 产能之间的差距是弹性最大的因素，因为它同时驱动队列、延迟、上下文切换和漏网缺陷。每项功能的价值直接放大已发布的产出。薪资总额是线性的，起到门槛的作用，这就是为什么多招一名测试人员往往能带来数倍于其成本的回报。
三个真实案例研究
白手起家的初创者
三人的产品团队
三名开发人员和一名测试人员负责一个小型产品。开发人员每月完成六项功能，测试人员可以验证七项，所以没有任何排队。加载这个案例，看看一个均衡的小团队：发布等于构建，没有需要解决的瓶颈。
处于扩张期的中型市场企业
拥有 24 名开发人员的均衡组织
一个大型组织为 24 名开发人员配备了七名测试人员，并投资于自动化，使 QA 产能略高于开发产出。队列极少，已发布的价值很高。加载这个案例，看看为什么健康的比例能让大团队保持盈利。
黑天鹅危机
十名开发人员与两名超负荷的测试人员
十名高效的开发人员每月完成 30 项功能，但两名测试人员只能验证 10 项。队列每月增长 20 项功能，缺陷漏网，开发人员不断回到旧代码中。加载这个案例，看看比例问题如何把庞大的薪资总额变成亏损。
行业基准矩阵
| 指标 | 危险区 | 行业平均 | 前 10% 的佼佼者 |
|---|---|---|---|
| 每位测试人员对应的开发人员数 | 高于 8:1 | 3–5:1 | 借助自动化约为 2–3:1 |
| QA 负荷（开发产出相对于产能） | 高于 130% | 90–105% | 低于 90% |
| 等待测试的平均队列 | 超过 10 项功能 | 2–4 项功能 | 少于 2 项 |
| 每次发布漏网到生产环境的缺陷 | 高于 10% | 3–6% | 低于 2% |
| 从完成到发布的周期时间 | 超过 4 周 | 1–2 周 | 少于 3 天 |
变量与杠杆
开发人员
构建功能的工程师。开发人员越多，产出越高，但测试速度不会随之提高。
杠杆: 在测试能力提升之前不要增加开发人员；限制在制工作量，让团队完成得更少，却发布得更多。
每位开发人员每月完成的功能数
一位开发人员每月完成并移交给 QA 的功能数。
杠杆: 把每个迭代启动的功能数限制在 QA 能验证的范围内，因为完成了但没测试的工作不会带来任何收益。
QA 测试人员
在发布之前验证功能的人员。
杠杆: 增加测试人员，或把测试工程师嵌入团队，因为每多一名测试人员，就能释放一批目前正在等待的功能。
每位测试人员每月验证的功能数
一位测试人员每月能够完整测试、回归测试并签字确认的功能数。
杠杆: 自动化回归测试并提前写好验收标准，让测试人员验证新工作，而不是重复旧的检查。
一项已发布功能的价值
一项功能触达用户之后带来的收入、留存或节省。
杠杆: 按价值为功能排序并舍弃低价值的功能，因为测试能力会被花在任何进入队列的东西上。
每项功能每月的延迟成本
每项功能在队列中每多等一个月所损失的价值，以损失的收入或客户信任衡量。
杠杆: 更频繁地发布更小的增量，这会缩短每项功能的等待时间，并降低延迟成本。
如何使用本模拟器
- 1输入开发人员的数量以及每人每月完成的功能数。
- 2设定测试人员的数量以及每人能验证的功能数。
- 3估计一项已发布功能的价值，以及每项功能每月的延迟成本。
- 4查看五张多米诺骨牌，留意 QA 负荷何时超过百分之百。
- 5在“平行宇宙”标签页中与增加测试人员的方案作比较，并分享链接。
应避免的错误
- 用完成的功能数来衡量开发人员。等待测试的工作是库存，而不是产出。
- 对很长的时期取平均值。每月增长的队列，早期看起来很小，后期却很大。
- 把测试人员当作要削减的成本。在瓶颈状态下，测试人员的产能是流水线中最有价值的产能。
- 只计算延迟成本。漏网的缺陷和上下文切换的损失，往往超过它。
常见问题
为什么增加开发人员并不能提高已发布的产出？
因为发布速度受限于最慢的环节。额外的开发人员只会增加 QA 前面的队列，抬高成本，却不会提高发布速率。
仅凭开发与测试人员的比例就够规划了吗？
这只是个开始，更有用的比较是产出与产能。自动化、需求的质量以及产品类型，都会大幅改变这个比例。
延迟成本是如何估算的？
按每项等待中的功能每月的损失来估算，以损失的收入、留存或信任衡量。这是一个假设，所以请测试一个较低和一个较高的数字，看看哪个占主导。
为什么缺陷会在过载时增加？
被催促的测试人员会跳过用例，减少复查。模型根据需求超出产能的程度按比例增加漏网缺陷。
多招一名测试人员的情景说明了什么？
它显示了多招一名测试人员并实现回归自动化的回报，这会提高 QA 产能，通常能清空队列。24 个月标签页会显示何时回本。
这个结果有多准确？
这是一个用于教育和规划的模型，其假设已在上文列出，不构成工程或财务建议。请用您自己的吞吐量和成本数据替换输入。
这是一个带有明确假设的教育性规划模型，不构成财务、税务或法律建议。请将输入替换为您自己的数据，并就重要决策咨询合格的专业人士。