你的定位
它应当是保证快速发布版本的手段, 而发布的标准正是测试检验的结果是否达成市场预期. 例如, 互联网产品BUG容忍度高,可以带一些非功能性BUG, 这时也可以先发布; 但一个网关设备, 要求不能有任何宕机问题.
做什么事情
测试先行, 在需求阶段中, 将需求细化成测试点;
在设计阶段, 一起进行设计与架构, 重点就可测试性进行评估与设计. 可测试性是隐性的客户需求, 至关重要, 关乎接下来测试的难易程度与开发DEBUG效率.
在编码阶段, 同步细化测试点, 参与开发代码评审, review, 完成测试代码, 检视需求点
在集成阶段, 用例提交( 手工, 自动化 ), 开发同步参与用例的评审. 检视自己代码是否有需求遗漏 系统测试中, 重点是发散性测试, 场景级测试, 以及用户级测试.
本来开发测试不分家, 这样20:1, 甚至比0的情况都是可以的.
为什么这样说呢? 可以说, 未来的开发人员即测试人员, 测试人员即开发人员. 不会编码的测试人员不是好的测试人员, 同样不会测试的开发人员不是好的开发人员. 制造跟发现BUG永远是一对兄弟, 开发不能等着测试发现问题,而是在开始就想到如何避免出现问题. 测试不能等开发把东西做好了才测, 应该一开始就分析如何保证在设计一开始就避免引入BUG.
这么一来, 理论上, 顶级的开发人员就不需要多少测试人员, 因为BUG会很少, 测试起来也容易, 版本发布当然快.
好的测试人员能顶住很多重复工作, 利用自动化, 利用编码能力, 利用强有力的预防手段, 防止大量无用功.
你的模式
我依稀记得前不久,WPS测试团队提出并实践的从互联网上爬取DOC文档来自动验证wps的稳定性的解决方案.
我想,这是一个多大的创新,于此, 我又相信wps的稳定性在未来会超出微软的办公套件了.
你需要我上面说的模式吗? 不一定.
视情况而定. 测试与开发的比例说明不了任何问题, 能够说明问题的只有是否按市场预期完成整个项目活动, 成本 是否控制在合理水平, 每个人是否得到自己想得到的东西, 例如技术水平提高, 管理能力.
但一旦能力上去了, 一定要往这个方向走.
敏捷不算啥, 更为直接的可以算是"持续交付", 达到这点其实非常easy:
1. 以自动化为核心, 一切工作皆自动化.
2. 团队有共同的目标, 遵循: 先测试,后开发; 保持主线clean; 重构,测试,交付;
如果大家都是这样的理想主义, 必然可以成功.
至于真的需要这么"敏捷" 吗? 看情况,你喜欢精英型团队,它是非常好的模式, 如果是传统型, 一定不适合你.
最后, 无论测试成什么样, 最终还是要看市场需求, 借用一句话: "台风来了, 是猪也能飞起来的".
一旦找到合适的测试模式, 它可能就是你的"敏捷"模式.
