测试工程师职责

ET/User-Story/System测试(负责人：有经验的/高级测试工程师)
在敏捷测试中，这几种测试的重要性也是不言而喻的。像探索性测试在敏捷测试中，甚至超过了系统测试的重要性，是敏捷测试面向系统和业务的核心测试类型。探索性测试的特点是测试人员可以事先对被测系统没有任何的了解，通过一边学习一边测试，快速地在有限时间内根据优先级最大限度地发现系统中存在的问题，所以说效率非常高。当然，同时对测试人员的要求也就非常高。它可以没有测试用例，但一定有很多引导测试人员思考的testidea，只有测试人员自身经验非常丰富的情况下，他才有可能根据最少的线索，猜测最有可能发现bug的地方。并且快速学习和总结能力是个不可或缺的条件，这就注定了只能由经验丰富的高级测试工程师才能hold住。User-story分析要求测试人员具备良好地沟通和理解能力，能够将客户表达出来的或者潜在的客户需求转换为我们的用户故事和业务逻辑的描述，供开发人员进行参考。系统测试就不说了，大家都很了解，要做好需要对被测系统有深入全面的了解。所以在这几个测试类型中，是对测试工程师能力的一个综合考验，虽然没有涉及到代码以及自动化，但必须要求测试经验丰富，测试方法掌握扎实，对业务精通的人员来进行。

BAT/Regression(负责人：初级测试工程师)
估计没人会反对我们在项目里要最大限度地利用自动化测试来开展BAT和regression测试，这是由自动化测试的特点和对ROI的考虑来决定的。敏捷测试中不可避免地要用到自动化测试，不然一切敏捷都是扯蛋了。而要想提高自动化测试的复用率和降低维护的难度，我们最好能够考虑根据业务更多地使用测试框架，将业务逻辑、测试数据和测试脚本高度解耦，例如使用关键字+数据驱动的混合型框架。这里实际上为什么说BAT和regression只需要没什么测试经验的人去做呢？实际上前提条件就是我们要合理利用框架，像关键字框架等等，用这些框架的人不需要去学习编程，他们只需要能够利用已有的关键字根据测试的需要去组合测试用例即可。所以并不是每个做自动化测试的人都必须具备编程能力的，他们在没有太多测试经验的情况下，做探索性测试是不合适的，但他们可以利用这些关键字练习和设计测试用例，又可以帮助组织执行自动化测试，充分发挥他们应该有的价值，同时自身也可以得到提高。

Test framework development(负责人：自动化测试开发工程师)
测试框架的应用在敏捷测试中也是举足轻重的，因为它涉及到自动化测试的复用性和可维护性的问题。脚本的复用性低和维护性差往往成为很多组织自动化测试失败的根本原因。辛辛苦苦开发的测试脚本不能复用，一点小小的功能改动都涉及大批脚本的改动，实在是伤不起。而不管是利用现成的测试框架，如robot或者是自己根据产品的需求开发的测试框架，其本身实际上都是一个完整的开发项目，所以需要负责框架开发的人非常熟悉软件设计方法和扎实的编程技能，这样的要求通常只有对技术狂热爱好的人才有可能达到。他们可能不需要太关心产品业务层面的东西，那不是他们关注的重点。他们需要的产品方面的知识往往可以从其他测试人员那里了解到，这就足够了，如需要开发哪些关键字，都可以由其他人告诉他们即可。他们应该关心地如何使得测试框架本身可以灵活适应产品需求的变化，如何提高框架的复用性。所以归根结底就是对编程和程序设计方面的要求较高，他们具备这些能力后，可以专门关注测试框架方面的工作，从而为BAT和Regression测试的工程师提供有力的帮助。