版权声明：本文可以被转载，但是在未经本人许可前，不得用于任何商业用途或其他以盈利为目的的用途。本人保留对本文的一切权利。如需转载，请在转载是保留此版权声明，并保证本文的完整性。也请转贴者理解创作的辛劳，尊重作者的劳动成果。
作者：陈雷 (Jackei)
邮箱：jackeichan@gmail.com
Blog：http://jackei.cnblogs.com
2007年8月13日，在刚刚开始我工作的第七个年头时，终于顺利的进入了M公司，并得到了一个测试管理方面的职位。虽然之前的六年工作中，我一直在偏技术和偏管理的角色中游移，自信自己在两个方面都有一些积累，足以胜任技术管理工作。可是在M公司的这一个半月，的确又真的让我重新开始思考自己的工作。
零零碎碎想到一些东西，先写下来，以后继续慢慢补充，也欢迎大家一起讨论。另外，虽然我的视角是从 Test Team 的角度出发的，但是也应该可以适用于其他想进一步提升自己价值的Team。
在大多数情况下，Test Team并不是以软件的直接生产者的身份出现的，而是作为一个附属的功能团队承担开发过程中的一部分职责。这也决定了Test Team 的工作并不不能直接的体现出价值，而是只有当Test Team的工作成果被其他人或Team所使用，为其他人或Team带来价值时，才能真正的体现出Test Team的价值。
换句话说，当我们的“产品”能够服务于他人时，我们的工作才有了价值；而当接受或使用我们的“服务”的组织越多时，则我们的Test Team的价值也就越大。
举个例子。当一个 Test Team 仅仅认为自己的工作只是“尽早的找到bug，并确认每个bug都得到合理的解决（这是对软件测试工作的经典定义）”时，一个Test Team产生的价值仅仅作用于某个Develop Team甚至某个Developer。这时，Test Team的大多数工作都属于Team内部的工作，与其他Team的接口可能仅仅限于一个bug tracking system，所产生交互的工作也仅仅限于对bug的讨论和状态的跟踪。这种情况下的 Test Team的工作甚至存在的理由都无法被项目之外或部门之外的人或组织所了解。
但是当我们留意到我们可以为整个项目中的多个Team，甚至整个部门的多个项目或者企业中的多个部门提供我们的“服务”时，一切都会变得完全不同了。例如
- 为项目团队提供每个版本的bug趋势分析数据，让项目中的每个人都了解项目当前的状态
- 通过分析bug数据来建立或完善各种Checklist，帮助项目团队更好的完成需求评审、设计评审以及代码评审，减少bug出现的机会。同时，可以定期将多个项目的Checklist进行合并，使单个项目的经验可以通过Test Team快速的流动起来，及时的作用于其他项目
- 主动为Architect Team提供每个项目的性能测试数据，帮助他们获取更多的实际项目信息，减少踏入“陷阱”的几率
- ……
我们可以做得事情还可以有很多，而关键在于我们是否有积极主动的与其他部门内或部门外的Team进行沟通，去努力了解他们的工作和需求，并开发我们已有的“产品”所能提供的价值。也只有当我们把自己成功的“推销”出去，并与更多的Team在工作上有了越来越深的融合，我们为别人提供的价值也越来越大时，我们自己的价值也才会变得越来越大，并且逐渐成为组织中无可替代的部分！
文章来源于领测软件测试网 https://www.ltesting.net/
