论坛徽章:: 0

电梯直达

1楼 [收藏(0)] [报告]

发表于 2008-07-31 16:27 |只看该作者 |倒序浏览

版权声明：本文可以被转载，但是在未经本人许可前，不得用于任何商业用途或其他以盈利为目的的用途。本人保留对本文的一切权利。如需转载，请在转载是保留此版权声明，并保证本文的完整性。也请转贴者理解创作的辛劳，尊重作者的劳动成果。

作者：陈雷 (Jackei)

邮箱：jackeichan@gmail.com

Blog：http://jackei.cnblogs.com

http://www.cnblogs.com/jackei/archive/2007/10/02/912789.html

文库|博客

knighter

大富大贵

论坛徽章:: 0

2楼 [报告]

发表于 2008-07-31 16:28 |只看该作者

成为无可替代，从提升自己的贡献开始！

在大多数情况下，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在工作上有了越来越深的融合，我们为别人提供的价值也越来越大时，我们自己的价值也才会变得越来越大，并且逐渐成为组织中无可替代的部分！

实战分享：从技术角度谈机器学习入门| 【大话IT】RadonDB低门槛向MySQL集群下战书 | ChinaUnix打赏功能已上线！ | 新一代分布式关系型数据库RadonDB知多少？

knighter

大富大贵

论坛徽章:: 0

3楼 [报告]

发表于 2008-07-31 16:32 |只看该作者

现在想来，软件测试的经典定义：尽早的找到bug，并确认每个bug都得到合理的解决——这确实是经常提到的

虽然很正确，但是确实有点误导，未能体现测试自身的价值

为项目团队提供每个版本的bug趋势分析数据，让项目中的每个人都了解项目当前的状态
通过分析bug数据来建立或完善各种Checklist，帮助项目团队更好的完成需求评审、设计评审以及代码评审，减少bug出现的机会。同时，可以定期将多个项目的Checklist进行合并，使单个项目的经验可以通过Test Team快速的流动起来，及时的作用于其他项目
主动为Architect Team提供每个项目的性能测试数据，帮助他们获取更多的实际项目信息，减少踏入“陷阱”的几率
……

这些是我做得不够的