首页>测试团队的价值项目管理者联盟
这样看来，敏捷开发的质量保证问题，都被发开团队解决了，测试团队的价值何在?项目管理者联盟
这个可以从第一个项目组后来的发展来分析。项目经理圈子
在整个程序团队大力保证产品质量的同时，项目组也一点点显露出一些问题。
比如每个模块的质量都还不错(有些模块甚至有一些原始的自动单元测试脚本，每次都能对模块进行回归测试)，但是整个产品最终集成后，是否能如期完成业务要求，却是未知的。因为各个模块的测试都集中在各模块的质量上，对于所有模块凑在一起的工作结果，却无法验证。而且在原来的团队体系下，师徒团队各自负责一个模块，居然没有人为此负责。项目管理者联盟
所以我们很需要一个人来团队里边，把整体集成及集成后的测试抓起来。这种工作，与其说是传统的面向质量的测试工作，不如说是一种面向验证的测试工作。就是只要能告诉我们集成在一起是可以工作的，目的就达到了。blog.mypm.net
测试团队的“发展”项目管理者联盟文章
这里边有很多戏剧性的过程。项目管理者联盟
首先过了一段时间，测试经理(虽然测试组当时只有2个人)想招几个人，原因是要写很多介于代码和脚本之间的语言，来仿真业务。项目管理者联盟
为什么说是仿真?原因是我们的产品之外，还有一个“订户管理系统”，这个系统的数据，是我们的业务。但由于他们部门的产品也在开发中，所以我们不得不先手工形成一些仿真业务。项目管理者联盟
这个问题，后来被开发组的人解决了。因为他们编写了一个文本的脚本语言，只需要手工写一些人眼很容易看懂的英文缩写和数字，就能仿真一些业务。club.mypm.net
这个脚本语言及其编辑、调试器后来越做越复杂(但因为开发它的开发人员对内部业务很熟悉，所以只花费了前后2周左右的时间)，能够自动运行、单步运行、设置断点调试。项目管理者联盟
有一次，两个测试人员在2天里用脚本编辑器编写了144个测试用例，每个测试用例包含5～128个购买和分组行为，来仿真和测试他们认为可能的各种排列组合。这些测试用例不是我们常常遇到的写在Word或Excel里边的那种，而是用那个脚本编辑器打开，按F5，就会自动执行并吐出结果的那种。service.mypm.net
这个工作如果由人力来完成，无论是编写测试用例，还是执行以查看结果，都是几乎不可想象的。项目管理者联盟
两个测试人员有一次希望大干一番，以便验证一些不是有意构建的用例是否可以通过测试。但最终结果是，这个编辑器和调试器后来被发展成能自动生成测试用例，乃至将用例发给真实机顶盒+IC卡系统和一个仿真的机顶盒+IC卡系统(一个友好的可以F5调试的VC++系统)，如果发现区别则自动记录，并继续产生下一个用例。项目管理者联盟
这段代码因为走的时候没有留下文档而失传了，不过在7年后的一次老同事聚会中了解到，团队在后续的几年中按照这个原理，把很多不同层次的硬件(数字电视里边的，大约有10种之多，个个都是黑底绿字乃至干脆没有屏幕的，非常难缠)都做了纯软件仿真，每个模块做好了，都可以扔进去和仿真硬件集成一番，这些工作大大缩减了最后真枪实弹时候经常出现的莫名其妙的问题，大大缩减了集成和测试时间。项目管理者联盟
这些程序人员的工作成果，保证了在团队有25人的时候(峰值曾经到达30人)，只要两个测试人员就能完成整个系统的功能测试，这个团队发展十分“缓慢”;但是从另外一个角度看，那些为测试团队编写测试代码的人，到底算是开发人员还是测试人员呢?项目管理者联盟
启示项目管理者联盟
一个优秀的团队，应该受到关注的应该是质量的高低问题、集成的效率问题、功能验证的效率问题……这些有人买单的问题，而不是开发与测试的分工、如何明确责任、如何对双方进行绩效考核等没人买单的问题。项目管理者联盟
所以尽管2001年那个时候敏捷开发的概念还不太清晰，但是本着“无我无人”的精神(详见般若敏捷系列之四)，很自然地创立了自己的敏捷方法。项目经理圈子
这件事情让我回忆起最近正在与很多业界人士合著一本“敏捷开发案例集”，中间有一个讨论时：“到底什么案例是敏捷案例，什么案例不是敏捷案例?”项目管理者联盟
最后的结论是：“第一个很松：大致有点和敏捷沾边就行;第二个很严：开发方法一定要被证明是优秀的”，换言之如果大家对优秀的开发方法视而不见，而到处找“敏捷开发方法”，就是舍本逐末了。项目管理者联盟
项目管理者联盟
整体上有两种测试团队的模型，既然都有存在，自然是各有各的道理。城里城外的人倒不必互相羡慕，只是要观察对面的优点，分析自己的缺点，尝试做点事情补偿一下。
所以，下面多说一点各自的坏处。项目管理者联盟
独立的测试团队项目管理者联盟
这个就是著名的与程序团队打架的测试团队。项目管理者联盟
•好处项目管理者联盟
独立团队，还是能保证一定的“公正性”的，比如在测试的最终，横竖有人能不屈从于程序团队的要求隐瞒产品质量，而是的确会客观地评价质量。项目管理者联盟
•坏处项目管理者联盟
当测试团队完全独立于开发团队的时候，常常有几个误区。项目管理者联盟
1. 程序团队是用来开发功能的，测试团队是用来查找缺陷的bbs.mypm.net
有了这个认识，要让两者打架就不难了。项目管理者联盟
2. 更多的测试人员=更高的质量项目管理者联盟
很多公司拥有惊人的测试人员比例，程序和测试基本上能到1：1，这个已经接近了造航天飞机的水平(50：80)，但是质量……一般缺陷率都能达到航天飞机的一万倍左右。项目管理者联盟
1和2是互相促进的，一旦拥有了1的认识，程序团队就对质量不太在乎了，因为后面有人负责测试，有Bug漏掉还要承担责任，所以自己只管按自己的兴趣编写代码就是了;而留下的缺陷越来越多，自然就需要更多的测试人员来解决。项目管理者联盟文章
分散的测试团队项目管理者联盟
•好处training.mypm.net
每个团队都有测试人员，自然测试活动会被当作家里的事情来看待，有机会在很早的时候就启动测试活动;由于没有后继的测试活动了，也没有人可扯皮了，所以组内的测试活动的效果会比较好。talent.mypm.net
•坏处项目管理者联盟
常常有这样几个误区。service.mypm.net
1. 人员不能共享，测试人员不足项目管理者联盟
基本出发点，还是认为这几个测试人员是来帮助解决缺陷问题的，因此他们极有可能成为局部的捡垃圾者。项目管理者联盟
由于只能调用自己的测试人员，当然逐渐地几个人就不够用了，也需要更多的测试人员。项目管理者联盟
2. 缺少总体质量的把关者www.mypm.net
由于所有测试人员都被当作小组的负责质量的人，产品最终所有模块集成在一起的时候，质量由谁负责，就成了个问题;集成后如何验证整体业务(而非技术)，也是个问题。项目管理者联盟
F型测试团队项目管理者联盟
这是本人“次喜欢”的一种模型。项目管理者联盟
如果历史问题已经形成，或者说不可能拆分掉专业测试团队，可以考虑这个形状。
F的两个横线，代表分散的测试团队，就是整体上测试团队的人员在项目成立时，分别被指派到程序团队中，协助在早期就提升质量。项目管理者联盟
而竖线，则表明他们定期向测试经理报告各小组的的进展，分散到各小组的几个测试人员之间也可以频繁通气，以便做好集成准备;并在几个小组都完成了内部的工作时，很方便地接管集成和整体测试工作。项目管理者联盟
•好处training.mypm.net
是当团队使用敏捷开发的迭代交付的时候，这几个测试人员还是可以进行很好的持续支持的，比如完成一个版本，就测试一个版本。项目管理者联盟
由于他们长期在项目组内工作，而且定期通气，所以接管系统测试会变得非常顺畅。club.mypm.net
•坏处转自项目管理者联盟
这个模型有些矩阵式的团队的确在用，不过需要很好的管理，确切说是文化，才能做好。项目管理者联盟
个人感觉在操作这种团队的时候，整个大项目的经理(同时管理开发和测试的)，必须要有很强的管理能力，并随时防止程序团队和测试团队分化。项目管理者联盟
实际上在很多时候，领导的作用都不再是管事，而是管人，就是如何管理好多个团队之间的关系。service.mypm.net
小型测试团队service.mypm.net
个人感觉最容易驾驭的团队。项目管理论坛
比如有20个人，4～5个程序团队外加1个测试团队。项目管理者联盟
每个程序团队都各自负责自己的质量(不派驻测试人员)，而那个测试团队则只负责业务层面的测试或称为验证，不负责质量。service.mypm.net
•好处项目管理者联盟
这种团队基本上是前面那个案例1(参考I和II)中的团队模型，由于当年的团队非常成功，所以非常推荐。项目经理博客
这种团队的集成活动是由开发团队和测试团队一起完成的，两者都为此负有责任;但完成集成后，由测试团队自己做系统级的业务测试。PgMp.mypm.net
整体上，是一种很“无我”的敏捷团队。
•坏处项目管理者联盟
这种团队只在上面提到的那个公司见过一次，之后的团队似乎都没有采取这个形式的，表明这种形式不容易自然形成。pmp.mypm.net
不过，鉴于当年的效果如此之好，本人一定会在自己未来的团队中采用这个模型。service.mypm.net
而实际上每个公司，与其在那些很容易组建但同时很难做好的团队模型中挣扎，不如去尝试一下真正效果好的团队模型。项目管理者联盟
很多人都很希望找到一种很容易做到，效果又好的模型(以及任何其他东西)。如果这种模型存在，全国人民都别炒房了，都来开软件公司吧。项目管理者联盟
来源：敏捷开发实践项目管理者联盟
项目管理者联盟
这样看来，敏捷开发的质量保证问题，都被发开团队解决了，测试团队的价值何在?项目管理者联盟
这个可以从第一个项目组后来的发展来分析。项目经理圈子
在整个程序团队大力保证产品质量的同时，项目组也一点点显露出一些问题。
比如每个模块的质量都还不错(有些模块甚至有一些原始的自动单元测试脚本，每次都能对模块进行回归测试)，但是整个产品最终集成后，是否能如期完成业务要求，却是未知的。因为各个模块的测试都集中在各模块的质量上，对于所有模块凑在一起的工作结果，却无法验证。而且在原来的团队体系下，师徒团队各自负责一个模块，居然没有人为此负责。项目管理者联盟
所以我们很需要一个人来团队里边，把整体集成及集成后的测试抓起来。这种工作，与其说是传统的面向质量的测试工作，不如说是一种面向验证的测试工作。就是只要能告诉我们集成在一起是可以工作的，目的就达到了。blog.mypm.net
测试团队的“发展”项目管理者联盟文章
这里边有很多戏剧性的过程。项目管理者联盟
首先过了一段时间，测试经理(虽然测试组当时只有2个人)想招几个人，原因是要写很多介于代码和脚本之间的语言，来仿真业务。项目管理者联盟
为什么说是仿真?原因是我们的产品之外，还有一个“订户管理系统”，这个系统的数据，是我们的业务。但由于他们部门的产品也在开发中，所以我们不得不先手工形成一些仿真业务。项目管理者联盟
这个问题，后来被开发组的人解决了。因为他们编写了一个文本的脚本语言，只需要手工写一些人眼很容易看懂的英文缩写和数字，就能仿真一些业务。club.mypm.net
这个脚本语言及其编辑、调试器后来越做越复杂(但因为开发它的开发人员对内部业务很熟悉，所以只花费了前后2周左右的时间)，能够自动运行、单步运行、设置断点调试。项目管理者联盟
有一次，两个测试人员在2天里用脚本编辑器编写了144个测试用例，每个测试用例包含5～128个购买和分组行为，来仿真和测试他们认为可能的各种排列组合。这些测试用例不是我们常常遇到的写在Word或Excel里边的那种，而是用那个脚本编辑器打开，按F5，就会自动执行并吐出结果的那种。service.mypm.net
这个工作如果由人力来完成，无论是编写测试用例，还是执行以查看结果，都是几乎不可想象的。项目管理者联盟
两个测试人员有一次希望大干一番，以便验证一些不是有意构建的用例是否可以通过测试。但最终结果是，这个编辑器和调试器后来被发展成能自动生成测试用例，乃至将用例发给真实机顶盒+IC卡系统和一个仿真的机顶盒+IC卡系统(一个友好的可以F5调试的VC++系统)，如果发现区别则自动记录，并继续产生下一个用例。项目管理者联盟
这段代码因为走的时候没有留下文档而失传了，不过在7年后的一次老同事聚会中了解到，团队在后续的几年中按照这个原理，把很多不同层次的硬件(数字电视里边的，大约有10种之多，个个都是黑底绿字乃至干脆没有屏幕的，非常难缠)都做了纯软件仿真，每个模块做好了，都可以扔进去和仿真硬件集成一番，这些工作大大缩减了最后真枪实弹时候经常出现的莫名其妙的问题，大大缩减了集成和测试时间。项目管理者联盟
这些程序人员的工作成果，保证了在团队有25人的时候(峰值曾经到达30人)，只要两个测试人员就能完成整个系统的功能测试，这个团队发展十分“缓慢”;但是从另外一个角度看，那些为测试团队编写测试代码的人，到底算是开发人员还是测试人员呢?项目管理者联盟
启示项目管理者联盟
一个优秀的团队，应该受到关注的应该是质量的高低问题、集成的效率问题、功能验证的效率问题……这些有人买单的问题，而不是开发与测试的分工、如何明确责任、如何对双方进行绩效考核等没人买单的问题。项目管理者联盟
所以尽管2001年那个时候敏捷开发的概念还不太清晰，但是本着“无我无人”的精神(详见般若敏捷系列之四)，很自然地创立了自己的敏捷方法。项目经理圈子
这件事情让我回忆起最近正在与很多业界人士合著一本“敏捷开发案例集”，中间有一个讨论时：“到底什么案例是敏捷案例，什么案例不是敏捷案例?”项目管理者联盟
最后的结论是：“第一个很松：大致有点和敏捷沾边就行;第二个很严：开发方法一定要被证明是优秀的”，换言之如果大家对优秀的开发方法视而不见，而到处找“敏捷开发方法”，就是舍本逐末了。项目管理者联盟
项目管理者联盟
整体上有两种测试团队的模型，既然都有存在，自然是各有各的道理。城里城外的人倒不必互相羡慕，只是要观察对面的优点，分析自己的缺点，尝试做点事情补偿一下。
所以，下面多说一点各自的坏处。项目管理者联盟
独立的测试团队项目管理者联盟
这个就是著名的与程序团队打架的测试团队。项目管理者联盟
•好处项目管理者联盟
独立团队，还是能保证一定的“公正性”的，比如在测试的最终，横竖有人能不屈从于程序团队的要求隐瞒产品质量，而是的确会客观地评价质量。项目管理者联盟
•坏处项目管理者联盟
当测试团队完全独立于开发团队的时候，常常有几个误区。项目管理者联盟
1. 程序团队是用来开发功能的，测试团队是用来查找缺陷的bbs.mypm.net
有了这个认识，要让两者打架就不难了。项目管理者联盟
2. 更多的测试人员=更高的质量项目管理者联盟
很多公司拥有惊人的测试人员比例，程序和测试基本上能到1：1，这个已经接近了造航天飞机的水平(50：80)，但是质量……一般缺陷率都能达到航天飞机的一万倍左右。项目管理者联盟
1和2是互相促进的，一旦拥有了1的认识，程序团队就对质量不太在乎了，因为后面有人负责测试，有Bug漏掉还要承担责任，所以自己只管按自己的兴趣编写代码就是了;而留下的缺陷越来越多，自然就需要更多的测试人员来解决。项目管理者联盟文章
分散的测试团队项目管理者联盟
•好处training.mypm.net
每个团队都有测试人员，自然测试活动会被当作家里的事情来看待，有机会在很早的时候就启动测试活动;由于没有后继的测试活动了，也没有人可扯皮了，所以组内的测试活动的效果会比较好。talent.mypm.net
•坏处项目管理者联盟
常常有这样几个误区。service.mypm.net
1. 人员不能共享，测试人员不足项目管理者联盟
基本出发点，还是认为这几个测试人员是来帮助解决缺陷问题的，因此他们极有可能成为局部的捡垃圾者。项目管理者联盟
由于只能调用自己的测试人员，当然逐渐地几个人就不够用了，也需要更多的测试人员。项目管理者联盟
2. 缺少总体质量的把关者www.mypm.net
由于所有测试人员都被当作小组的负责质量的人，产品最终所有模块集成在一起的时候，质量由谁负责，就成了个问题;集成后如何验证整体业务(而非技术)，也是个问题。项目管理者联盟
F型测试团队项目管理者联盟
这是本人“次喜欢”的一种模型。项目管理者联盟
如果历史问题已经形成，或者说不可能拆分掉专业测试团队，可以考虑这个形状。
F的两个横线，代表分散的测试团队，就是整体上测试团队的人员在项目成立时，分别被指派到程序团队中，协助在早期就提升质量。项目管理者联盟
而竖线，则表明他们定期向测试经理报告各小组的的进展，分散到各小组的几个测试人员之间也可以频繁通气，以便做好集成准备;并在几个小组都完成了内部的工作时，很方便地接管集成和整体测试工作。项目管理者联盟
•好处training.mypm.net
是当团队使用敏捷开发的迭代交付的时候，这几个测试人员还是可以进行很好的持续支持的，比如完成一个版本，就测试一个版本。项目管理者联盟
由于他们长期在项目组内工作，而且定期通气，所以接管系统测试会变得非常顺畅。club.mypm.net
•坏处转自项目管理者联盟
这个模型有些矩阵式的团队的确在用，不过需要很好的管理，确切说是文化，才能做好。项目管理者联盟
个人感觉在操作这种团队的时候，整个大项目的经理(同时管理开发和测试的)，必须要有很强的管理能力，并随时防止程序团队和测试团队分化。项目管理者联盟
实际上在很多时候，领导的作用都不再是管事，而是管人，就是如何管理好多个团队之间的关系。service.mypm.net
小型测试团队service.mypm.net
个人感觉最容易驾驭的团队。项目管理论坛
比如有20个人，4～5个程序团队外加1个测试团队。项目管理者联盟
每个程序团队都各自负责自己的质量(不派驻测试人员)，而那个测试团队则只负责业务层面的测试或称为验证，不负责质量。service.mypm.net
•好处项目管理者联盟
这种团队基本上是前面那个案例1(参考I和II)中的团队模型，由于当年的团队非常成功，所以非常推荐。项目经理博客
这种团队的集成活动是由开发团队和测试团队一起完成的，两者都为此负有责任;但完成集成后，由测试团队自己做系统级的业务测试。PgMp.mypm.net
整体上，是一种很“无我”的敏捷团队。
•坏处项目管理者联盟
这种团队只在上面提到的那个公司见过一次，之后的团队似乎都没有采取这个形式的，表明这种形式不容易自然形成。pmp.mypm.net
不过，鉴于当年的效果如此之好，本人一定会在自己未来的团队中采用这个模型。service.mypm.net
而实际上每个公司，与其在那些很容易组建但同时很难做好的团队模型中挣扎，不如去尝试一下真正效果好的团队模型。项目管理者联盟
很多人都很希望找到一种很容易做到，效果又好的模型(以及任何其他东西)。如果这种模型存在，全国人民都别炒房了，都来开软件公司吧。项目管理者联盟
来源：敏捷开发实践项目管理者联盟
项目管理者联盟
粤公安备案 44010602008731号