敏捷测试与自动化
敏捷自动化问题
最近看到一篇文章，讨论敏捷开发模式下的自动化实施问题，看到里面有很多值得好好想想的地方。
首先，在一个追求敏捷开发的团队中，很多时候，测试工作都是放在整个项目的最后一个环节，尤其是Android应用项目，多数情况下，会出现很多个版本一起上线，这个时候，作为测试的压力明显是非常大，工作量巨大，纯手工进行测试很可能会忙于应付需求，这个时候正式自动化回归最大效率化的时候，然后现状很可能是，自动化连手工都不如，需要半天甚至一天才能出测试结果，每次运行都是全流程，自动化测试报告也需要大量时间进行分析，这无疑是很失败的敏捷自动化实施。
很多团队，可能也有专人进行了很长时间的专职自动化设计，搭建，但是效果一直不理想，原因可能是：
自动化人员与业务剥离，甚至不了解业务，所有用例需要业务功能测试人员提供；试想这样的情况下，自动化也不是纯框架设计，进行的也是涉及业务的自动化用例设计，那怎么可能设计出有效的自动化用例呢。
管理人员对于自动化预期过高，认为自动化测试可以实现所有的测试活动；自动化测试，说到底，也是在设计了断言的情况下进行验证，也就是已知结果的情况，很多时候，测试工作需要随机测试，暴力测试等等去发现很多非正常情况下可能出现的问题。
自动化测试没有专人，没有必要的时间和精力；有的公司可能实行的是固定测试开发团队进行自动化框架编辑搭建，后续的自动化用例是由产线的测试工程师进行编写维护；这样的做法，的确算是功能细分，但是有个前提，产线的测试有时间和精力去专门做自动化测试相关。很多团队有点搞笑，自动化用例让产线实施，并不给产线测试需要的时间去学习和练习自动化测试技能，最终的结果，可想而知。
其实测试人员也都知道，产品交接时间点临近时，产品功能交付的优先级肯定是高于自动化实施，测试人员需要确保的是那些即将交付的产品功能，而不是确保产品功能正常的自动化测试用例。但是长此以往的不断将自动化测试实施优先级降低，一次次的迭代发布日期指定，只会将产线折腾的异常忙碌，烦躁。造成这种情况的原因，可能是迫于市场和客户压力，需要一次次的制定满足于市场的新功能，短时间铺开市场，解决客户问题，但是这样的一次次的追求快，仓促发布功能，最终真的是在满足市场吗？守业更比创业难，不要等到最后市场诚信低至谷底时候才想起来，当然，追求快速IPO分钱走人就当没说。
插一句：敏捷工作方式的目的是以最小幅度增长的方式发布可供用户使用的功能，并且得到用户的即时反馈。
可能的解决办法
设定合理的预期，想清楚，为什么需要自动化，需要自动化做什么，怎么实施可以帮助现在的团队。有个很扯淡的想法，实施自动化是因为不想做手工。。。
给自动化分配专用的资源，公司需要关注的不应该仅仅是测试开发需要专门的资源，产线的自动化用例编写维护人员更需要专门的时间和精力去学习，练习，维护自动化，整天疲于应对功能迭代压力，最终结果是自动化夭折。
提高自动化关注度和优先级，这个需要在公司层面，宣传论证实施自动化的价值，试问如果团队都不知道自动化为何物，就提出要花大时间，聘请专员进行自动化，是不是有点扯。
将自动化测试看做软件研发对待，这点是对自动化测试工程师本身来说的，实施自动化测试之前，需要和产品研发一样，需求分析，方案论证，概要设计，详细设计等。
合理制定目标，也是针对自动化实施人员来说的，在经验没有那么丰富，或者时间没有那么充裕的情况下，是是不是可以考虑首先进行的是接口的自动化，而不是直接UI。
持续学习，既然敏捷工作模式下，产品都是一些快速迭代的过程，那身为自动化工程师的你，是不是应该为了适应不断增加的需求，去快递学习。例如自动化工具后续直接使用docker镜像化，自动化实施配合CI，构建完成直接Jenkins调度，无需手工执行，自动化实施过程中，关注测试右移，实施APM监控等等。
以上是看到的和自己的一点点想法，希望国内广大的测试同胞们可以不被自动化所累，知道自己想要的是什么，其实在我看来，追求系统的底层实现，开发语言的基本语法，高效实施等，才是更有效的方式，一味的追求工具，追求框架，很可能会迷失自己，毕竟做到后面，自动化也成了维护代码。
愿测试可以被温柔以待
突然想到个毫无关系的一句话：少年不知画中意，归来已成画中人