本文主要是介绍读书笔记《estimating tester to developer rations（or not）》，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
最近读了一篇文章《estimating tester to developer rations（or not）》，文章介绍了一个model, 这个model描述了项目中测试人员与开发人员的比例关系，并举了实例，作者也说明了这个model并不能给你准确的回答说一个项目需要多少测试人员，应该和开发人员的比例是多少，不过可以根据当前项目的情况，并把一些作者文章提及到的影响测试人员和开发人员的比例的各个因素考虑到实际的项目中，根据baseline的项目，去评估实际项目中需要的测试人员。
Model 如下所示：
影响测试人员-开发人员比例的一些因素：
Developer Efficiency at Removing Defects before Test
² 这项如果开发移除缺陷效率高，就会降低测试人员与开发人员的比例。
² 人的因素（people factor）：
² 单元测试和review技术缺乏经验；
² 过于自信（over-confidence< <script src="http://hi.images.csdn.net/js/blog/tiny_mce/themes/advanced/langs/zh.js" type="text/javascript"></script> <script src="http://hi.images.csdn.net/js/blog/tiny_mce/plugins/syntaxhl/langs/zh.js" type="text/javascript"></script> span style="color: navy; font-family: 宋体; mso-ascii-font-family: 'Times New Roman'; mso-hansi-font-family: 'Times New Roman'; mso-fareast-language: ZH-CN;">）（深有感触，当前的这个项目，刚开始develop lead就一直强调没有什么技术问题解决不了的，快要release的时候，才告知有些bug不能fix掉）
组织的因素（organizational factors）：
² 管理层认为测试人员能否发现所有的错误，开发人员没有必要进行单元测试。(This is also known as “development already did enough work.”
产品因素（product factor）：
² 代码很难被理解和测试。
过程因素（process factors）：
² 没有单元测试；
² 没有有效地进行reviews 和 inspections。
Developer Efficiency at inserting Defects
（想到当下的这个项目，开始预估的时候，development manager认为产品不大，bug数会在60个左右，还有一周就release了，到今天为止，已经有400多个bug，未修复60多个，远远超过之前的预估，原因有很多，其中也有一下提及到得几点）
人的因素（people factor）：
² 软件工程知识的缺乏，导致比较糟糕的设计；（inexperience with software engineering principles）
² 项目相关行业知识的缺乏；(inexperience with the technologies or business domain of a particular project)
² 追赶进度而不注重质量；（belief that working fast is better for the schedule than working carefully）
² 筋疲力尽。（burnout）
组织的因素（organizational factors）：
² 开发人员彼此沟通不畅;(a:地域差别；b：传递需求到开发人员不顺畅；c：有外包人员)
² 各个team之间存在敌意和抱怨；（arguing or hostility between teams）
² 强迫开发人员遵循不切实际的schedule；（disfranchised engineers with imposed schedule）
² 没有对项目“success”或是“doneness”的度量，只是知道code 完成。（no accepted measure of success or “doneness” except “code complete”.这个是一个被经常忽略的一个问题）
² 太多的测试人员导致开发人员的松懈（death spiral(我不知道如何翻译，暂且认为是死螺旋，too many testers can cause developers to get sloppy)
² 多个team致力一个项目，导致整合问题的增加（integration problems）；
² 没有想过进行错误的预防。（little interest in finding patterns of mistakes（defect prevention））
产品因素（product factor）：
² 产品比较复杂；（complexity of product）
² 合并一些重用软件，第三方自定义软件或是现货供应的软件；（incorporation of reused software, third-party custom-written software or off-the-shelf software）
² 代码数量和缺陷数量是非线性的；
² 糟糕的代码是源于其它方面-糟糕的耦合或是糟糕的模块化；（poorly designed code inherited from others-highly coupled poorly modularized）
² 遗留的代码，开发人员没有完全弄懂；（legacy code, which is no fully understood by the programmers）
² 一个单独的设计缺陷引出几个bug（a single design fault can be multiplied into numerous failures ）
Ø 翻译或本地化问题
Ø 需要支持多个平台
Ø 需要同多个产品接口
过程因素（process factors）：
² 使用强大的编程工具并允许每个程序员生成很多的代码；（use of powerful programming tools which allow each programmer to generate more code）
² 配置，build工具或过程不满足需求；
² 糟糕的计划，导致开发过程的匆忙。（poor planning， resulting in developers in a hurry）
Defects found per Tester
每个测试人员发现的bug越少，需要的测试人员相对就会越多。
人的因素（people factor）：
² 测试人员的经验；（inexperienced or poorly trained tester）
² 工作态度；（poor attitude or moral）
² 测试技能的不足；(Exploratory testing, familiar with user domain, performance testing, combinational methods, or knowledge of a range of appropriate patterns for test design)
² 开发人员的代码很难进行测试。（developers do not know how to write code to easily testable）
组织的因素（organizational factors）：
² 同开发人员沟通存在障碍；（barriers to communication with development staff）
² 如有外包测试，没有充分利用资源，造成资源浪费；（inappropriate use of outsourcing of test）
² 公司的文化-不信任感（time is spent gathering data to protect oneself later）
² 过多的状态报告和metrics也没有提高测试效率，反而浪费了很多时间；（superfluous status report，metrics， and so forth that do not help make testing more efficient nor assist the programmers）
² 经常改组，导致team沟通问题和知识的交接和传承问题；(Teams are constantly reshuffled, leading to loss of knowledge and barriers to communication)
² 测试人员同时又多个项目进行，导致项目切换的过程中时间的损失；（Testers handle multiple projects simultaneously , leading to loss of time on task switching）
² 自动化测试脱离了项目的实际需要，投入太多产出很少。（automation group is disconnected from the needs of the organization and burns resources without corresponding return on investment）
过程因素（process factors）：
² 没有经过自测的代码就流入测试组，而造成有时候安装后并不能测试的时间浪费；（code is submitted before it works at all, wasting test time on installing broken code）(一个是要求开发人员必须经过自测，还有就是测试人员对新的building要有个接收的测试集，通过后在进行接下来的测试)
² 规定的环境需要很多额外的文档；（Regulatory environment requires a lot of extra documentation）
² 售出的产品要附带测试计划和用例，因此需要多花费时间让其看上去更好；（Test plan and tests will be sold along with the product, and therefore must look nice.）
² 毫无关系的组接管了测试，使得沟通需要很多时间；（testing will be taken over by totally unrelated group, requiring much greater communication time.）
² 没有合适的工具辅助测试；
² 重复无用的回归测试；（often due to misuse of metrics）
² 不归档用例，需要的时候可以再利用；(testing does not store tests and reuse them when possible)
² 代码完成后才开始测试，使得寻找缺陷的时间大大缩短；(testing does not start until code complete, which cuts amount of time to find defects, not efficiency of tester)
² 生成一些毫无用处的文档；（production of useless documentation of any kind）
² 缺少可以知道测试的文档；（lack of metrics that would guide testing more effectively）
² 没有测试计划去指导有效地测试；（lack of test planning to use time most effectively）
² 开发人员不熟悉bug跟踪过程和管理工具。（defect tracking process or tools not understood by development staff）（当前这个项目，也有遇到这个问题，有些开发人员竟然不知道如何使用管理bug的工具，并且对软件开发测试流程一点都不了解，让我始料未及）
产品因素（product factor）：
² 需要大量的自动化去执行测试；（no user interface）
² 没有测试的接口。（no test interfaces build in, or insufficient or unclear error logging）
Values of defects found
以下的因素增加发现的缺陷的价值，也相应的增加了测试人员和开发人员的比例。、
产品（Product）：
² 修复问题成本很大；（expensive to fix problems after release）
² 需求很迫切；（Regulatory requirements are stringent）
² 需要经常改变，维护很重要；(will be changed frequently, thus maintainability is important)
² 需要高可靠性和安全性；（has high need for reliability or safety）
² 售后支持周期长。（will have long support life）
用户期望（customer expectations）
² 用户可以选择使用或不使用这个产品，有竞争的同类产品存在；（has competition giving users the choice to user the product or not）
² 期待比较专业的产品；
² 是实际使用，不是demonstration或是样本；
² 客户群比较特殊；
² 客户希望晚些时候得到要个更好的产品而不是现在拿到一个问题很多的产品；(customers would rather have a good product later than a buggy product now)
² 竞争客户的产品相对问题要少。（competing products are less buggy than ours）
Tester time spent on other matters：
如果tester还要花时间做下面的工作，那么测试人员和开发人员的比例就会增加。
² 检查需求（Inspecting Requirements）（测试人员应该参与到需求的测试中）
² 检查code（inspecting code）
² 写需求说明书（writing requirements）
² 参与产品的首次展示（participating in rollout of Product）
² 撰写产品文档（writing product document）
² 接支持热线（taking support calls）
² 处理配置和build问题（handing configuration management and builds）
如何使用这个model去预估需要多少个测试人员
首先去收集baseline的数据
数据包括硬数据（hard date）也包括软数据（soft date）。硬数据就是测试人员和开发人员的人数-小时计算。软数据就是上面提到的影响测试人员和开发人员比例的各个因素。
估计需要的测试人员
² 选择baseline的project。文中列举了两个baseline的project
² 收集baseline 项目测试人员和开发人员比例的数据
² 首届model 所显示影响比例的各个因素的信息
² 基于第二步，初步估计所需要的测试人员
² 和baseline的项目比较各个相对应的影响测试人员和开发人员比例的因素
² 整合比较的结果
² 根据比较的结果，根据自己的判断，再次预估测试人员的所需的数量（如果可由多个baseline projects做参考，可以重复这些步骤，预估的数据会更准确）
这篇关于读书笔记《estimating tester to developer rations（or not）》的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
