在以往的团队测试软件产品时，有了可以提高效率的新想法，往往可以快速、轻松地得到变现，开发出相应的小工具，并能在团队内部迅速推广。自己十分熟悉业务，有想法，知道最缺的工具是什么，又有编码技能，轻松开发工具不是个事儿。但是测试工作任务很重，缺少时间和精力，不能专职做工具，很多想法并不能得到实现，真的很可惜。

　　在目前的公司，测试部门拥有专门的测试工具开发部门，聚集了一批优秀的测试开发工程师。尽管工具文化已渐渐深入人心，成为发展趋势，这样高瞻远瞩的规划在国内的测试团队还是不多见。但成立专门的工具开发部门，又很容易带来新的问题：对业务知识的理解不能及时更新，缺少和工作在测试一线同事的沟通，自发主导的工具研发往往没有应用市场……一些同事曾经提出过很好的想法，因为各种各样的原因，没有认真被对待过。真担心，若想法不能被认真对待，以后就不会有更多的想法提出来。优秀的测试开发工程师必须能掌控测试业务知识！

　　如果我们有完善的工作流程，上述问题就很容易被解决。有了工具需求，知道走什么样的流程；有了想法，知道去哪里倾诉，什么问题不能解决呢？任何好的流程，都会深入人心，而不会给人、给自己添麻烦。

　　当流程顺畅、新想法可以作为工具需求提出来，还有新的问题。软件测试工程师提出的需求的可操作性非常差，每次拿到需求的时候，让测试工程师描述详细一点时，他们往往不知所措。测试开发工程师面对测试工程师的需求和需求工程师面对最终客户的需求，其痛苦可能并无二致。优秀的测试开发工程师不能被测试工程师的需求描述所羁绊，多和开发工程师沟通，了解软件产品愈多，在架构设计测试工具的时候，越能灵活！

　　测试开发工程师、测试工程师、开发工程师三方之间的沟通更需要畅通。三方要保持良好协作：测试开发工程师从测试工程师那里了解测试工具需求，从开发工程师那里了解软件产品的知识；测试工程师借助测试开发工程师开发的辅助测试工具检验产品的质量；开发工程师设计开发软件产品，对测试工程师进行技术支持！

版权声明：本文出自 lobster 的51Testing软件测试博客：http://www.51testing.com/?194329

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。