测试自动化小组尝试过另一款芬兰同事开发的新型框架，名字叫做robotframework，如今已经开源。这个框架本身使用Python语言开发完成，用来开发可接受性测试，是关键字驱动的测试自动化框架，支持多种测试用例的格式，我最喜欢的是使用表格的HTML文件格式。框架非常好用，各方评价都非常高，但是由于核心的开发者都在芬兰，杭州本地需要有人能够进行培训、辅导，才有可能做到快速地推广使用。于是测试自动化小组的同事参加了该框架的高级培训，以及如何进行入门级培训的培训，然后向杭州研发中心的其他同事提供培训，帮助他们使用这个框架实现测试用例的脚本化。
测试框架的使用推广很快，该产品线决定全面采用此框架来实现测试自动化，包括手工测试的用例也需要使用此框架来撰写和管理。并且还专门成立了一个团队为产品线开发库函数，封装操作命令，以便于测试人员们可以不必担心太多库函数编程的问题，快速地实现测试用例的脚本化。
但是测试自动化并不只是将测试用例实现脚本化而已，它是一个复杂的活动，同样包含测试用例的设计、测试方案的选择、测试验证手段的选择等等步骤，而且还必须考虑到在自动化执行的情况下，机器和被测对象的之间的交互方式和人不同，观察被测对象反应的方式也不同。更不用提到脚本本身也是一种代码，而代码如果质量不高就会产生大量的技术债务。在缺乏编程经验的测试人员手中就更是一场灾难，他们会复制、粘贴现有的测试脚本，再做相应的修改，重复的脚本片段或是无关脚本片段的残留物可谓是司空见惯。测试人员也渐渐地从欢迎转变到了叫苦连天的态度，抱怨他们需要花非常多的时间调试出错的脚本，根本就没有时间去进行“真正的”测试。
为了能够更好地推广测试自动化，也为了能够解决测试自动化所带来的这些问题，管理层决定设立测试自动化教练的角色。我是被选定的两位教练之一。我们所服务的对象不仅仅是参加过Scrum试点项目的那批人，还包括刚刚进行敏捷转型不久的数百人大组织。
在培训师和教练的工作中，我发现一些常见的问题：
● 不愿意花时间去熟悉工具：很多测试工作者参加完基础培训之后就不再花时间去查看工具的相关文档，不愿意去熟悉其操作技巧以及库函数开发，连一些非常简单的小技巧也不知道，开发出来的测试用例很臃肿，使用的测试操作往往要耗费很多的CPU或者内存资源以及执行时间。
● 不愿意去阅读现有的用例：由于种种原因，一些测试用例本身就非常难读懂，导致后续接手的测试人员不愿意花时间去理解用例的设计思路，或者是去理解其中的每一步操作，往往满足于用例运行通过即可，用例失败时也只是以修改后用例通过为目的。
● 需求和用例间断裂的联系：敏捷转型给测试工作带来了一系列的挑战，首当其冲的就是从需求到测试用例的整条线索如何延续。以往会比对软件模块的功能需求条目和测试用例，衡量测试的覆盖率，而Scrum模式下开发的粒度是特性，无法沿用此做法。于是在此时，我们提出了Robot Case as Requirement的想法，也即利用robotframework测试用例本身描述性强的特点，来承载需求文档的作用，而测试用例自身就是可执行的自动化脚本。
● 测试工作者失去的归属感：在Scrum模式下，测试工作者散布于每一个跨职能特性团队中，很可能孤单一人，团队里最多也就2~3个做测试的。相比以往单独的测试部门，大家没有了归属感，也不知道该找谁问问题、在哪里获取测试相关信息以及如何提高自身的测试能力。我们也为此成立了测试社区Test Community，定期聚会，邀请大家来分享自己的心得体会，互相学习提高，还有在线论坛供大家交流，社区已经可以自我推动着持续发展壮大。
● 缺乏测试自动化理论知识：测试自动化（Test Automation）和自动化测试（Automated Test）其实是两个不同的概念，测试自动化是包括测试计划、测试用例设计、执行、分析、报告各个阶段在内的一系列活动，而自动化测试可以看做是仅仅把测试用例的操作实现成脚本而已。缺乏测试自动化理论知识会累积测试技术债务，难以维护、脆弱易损的测试脚本就像是低质量、漏洞百出的代码，后期的维护、修复开销远超过鲁莽自动化所带来的那一点点效益。
● 软件本身低下的可测性：可测性可谓是测试自动化的关键，可测性不高的软件本身就难以进行测试，测试自动化则更加依赖软件的可测性。机器不像是人，可以通过眼睛观察多处信息，并且找到其中的联系，或是在脑中进行逻辑分析，从蛛丝马迹间找到问题。测试自动化需要采取适合于机器的脚本执行、信息收集、结果分析的测试方法，一定程度上这都依赖于软件本身要提供准确的、适量的信息。
● 测试工作者不熟悉Scrum：Scrum模式要求团队是跨职能特性团队，应该着手培养出通才化专家（Generalizing Specialist），通过加强团队内的交流，开发、测试以及其他职能人员通过合作和沟通互相学习，摸索出适应迭代增量模式的工作方法。但多数测试工作者依然是按照类瀑布模式的方式工作，在Sprint前期空闲后期忙碌，来不及完成测试。当然，这也和不了解测试自动化，或是可接受性测试驱动开发有关系。
相关链接：
我的软件测试之旅：（1）起点——作为软件开发人员
我的软件测试之旅：（2）转变——作为专职测试人员
我的软件测试之旅：（3）同期——加入测试自动化小组
我的软件测试之旅：（4）并行——自动化回归测试
我的软件测试之旅：（5）难点——功能改进的测试
我的软件测试之旅：（6）跳转——追逐新鲜事物的探险者
我的软件测试之旅：（7）启程——Scrum中的测试工作者
我的软件测试之旅：（8）困难——没有现成的测试工具
我的软件测试之旅：（9）行动——简化测试文档和流程
我的软件测试之旅：（10）贡献——开发项流程
我的软件测试之旅：（11）尝试——Scrum Master