前不久一年轻同事和我聊到团队的认可度和价值的问题，并例举出了他心目中的一些解决办法，我顿时觉得以他的从业经验和年限来说能有这样的高度来考虑问题实属难得，同时也恰逢寡人正思考这方面的对策，可谓是不谋而合。

　　通常情况下，测试团队并不是以软件的直接生产者的身份出现的，而是作为一个附属的功能团队来承担软件生命周期中的一部分职责。这在很大程度上也决定了测试团队的工作并不能直接的体现出价值，而是只有当测试团队的工作成果被别人使用、带来价值时，才能真正的体现出它的价值。换句话来说，当我们能够服务于他人时，我们的工作才有了价值；而当接受或使用我们服务的组织越来越多时，我们的测试团队的价值也就会越来越大。

　　举例说明一下：当一个测试团队仅仅将自己的工作定位于“尽早的找到缺陷，并确认每个缺陷都得到合理的解决（这是对软件测试工作的经典定义）”时，一个测试团队产生的价值仅仅作用于某个开发团队甚至是某个开发人员，此时测试团队的大多数工作都属于团队内部的工作，与其他团队的接口可能仅仅限于一个缺陷跟踪解决的过程，所产生交互的工作也仅仅限于对缺陷的讨论和状态的跟踪。这种情况下测试团队的工作价值很难被项目之外或部门之外的人或组织所了解，甚至会质疑这个团队存在的必要性。

　　但是，当我们留意到我们可以为多个项目，甚至是多个部门提供我们的服务时，一切都会变得不同！例如：为项目团队提供每个版本的缺陷趋势分析数据，让项目中的每个成员都了解项目当前的状态；通过分析缺陷数据来建立或完善各种检查单，帮助项目团队更好的完成需求评审、设计评审以及代码评审，在前沿减少缺陷出现的机会；可以定期将多个项目的检查单进行合并，使单个项目的经验通过测试团队快速的流动起来，及时的作用于其他项目；可以在某些技术、框架选型时提供充分的测试数据，以支持架构师在技术选型以及售前方面的工作；还可以主动为设计分析团队提供每个项目的性能测试数据，帮助他们获取更多的实际项目信息，减少后期出错的几率等等。

　　由此看来，我们可以做的事情其实有很多，而关键在于我们是否有积极主动的与其他部门内和部门外的团队进行沟通协作，去努力了解他们的工作和需求，并开发我们所能提供的价值。也只有当我们把自己成功的推销出去，并与更多的团队在工作上有了越来越深的融合、我们为别人提供的价值也越来越大时，我们自己的价值也才会变得越来越大，并且逐渐成为组织中不可替代的部分！