时间线：

1. 2019 年 3 月：在前东家（某游戏公司）工作 3 年半后，终于决定要换个新的环境。
2. 2019 年 4 月：更新并开放简历，收到猎头推荐，面试通过，接受 offer，提出离职并开始交接。
3. 2019 年 5 月：入职新公司，至今已一年半。

关于前东家

前东家是我非常珍惜的一段时间。

1. 虽然入职是测试主管头衔，中间也曾带着两位测试组员，但最后随着公司业务调整，最后还是变成了光棍司令。巅峰时一个人同时应付 Android、iOS、H5、web 四个前端，以及接口、管理后台、数据收集、监控系统，和一个大数据统计后台，以及公司内外接近 10 个游戏的对接相关的测试工作，居然也抗了下来。
2. 前后两位领导对我的管理都非常自由，也非常支持我对质量管理方面的工作。这让我有充分的自由先后把 web 自动化、Android 自动化、接口自动化、各种大数据模型的造数脚本都做了起来，后来还捣鼓了一个自动化平台，让我在完成自己工作之余，也有了非常大的成长。
3. 也是这段时期，让我接触到了社区，见识到了很多新的工具和测试理念；也鼓励了自己有机会把收获的内容分享到社区中。

可以说这段工作经历的成长对于后续在新公司能快速上手并且发挥自己的作用有很大的帮助。

关于跳槽

1. 既然下定了决心离开，就没有给自己留下来的后路：面试完后就和领导坦白自己的离职决定，不想因为自己的仓促离开而影响交接。可惜的是，到离开的那天也没招到新人入职，最后只好都交接给了领导。
2. 一开始有点担心自己的英文水平是否应付不了外企的面试，没想到平时看美剧看英文 stand up 的爱好帮上了不少忙，蹩脚的口语在我在黑板上列出的平时工作要点和流程的帮助下，居然也愉快地和面试官交谈了一个小时，并得到一个满意的评价。这个经历也打消了自己原本对外企英文沟通的担忧。
3. 非常相信自己的第一感觉，所以和前几份工作一样，都是只面试了一家公司就接受了 offer；也许是命中注定要劳碌不停，所以也和前几份工作一样，离职日期和入职日期无缝对接，没有选择休息一段时间。

工作总结

入职之后工作很快上手和忙碌起来：

1. 参与第一个项目，领导交代需要用自动化的方式去覆盖多语言的测试。快速了解需求之后很快有了大概的方案并且执行起来，得到领导的认可，并安排了一次部门内的分享和答疑，效果很不错。
2. 参与部门新的自动化测试框架的推广和支持工作。
3. 把部门的 API 自动化从零搭建起来，并在项目中推广使用。
4. 把今年部门的重头项目接了起来，经过一段时间的努力，把团队的开发测试流程梳理清楚，使项目得以顺利进行。也通过 UI、API 的自动化覆盖以及各种造数脚本，提升了整理的测试效率。
5. 尝试将项目的模式和经验推广到整个部门。

关于如何提升效率

1. 梳理团队的开发流程。
   项目的进程中有什么效率低下的障碍？ 找出痛点和责任人去推动整改。开发的效率提升了，其实反过来是减少了对测试时间的压缩。

2. 复杂的事情流程化。
   需要多方参与协作的任务很容易陷入各方踢皮球的情况，没有人去主导和做决策。这时候需要把这种事务的流程确定下来和决策。找对的人（有权力做决策，和有能力做出好决策的人），做对的事（对项目有利，对我们的测试有利）。

3. 重复的事情自动化。
   -- 每个人准备账号都需要浪费一定时间？ 那就写好脚本建好一批账号给团队所有人使用。
   -- 每次联调和测试都要临时去造数据？ 那就写好脚本每天建好大量的数据给大家使用。
   -- 每次发版都要等开发打包，而且配置经常弄错？ 那就放到 Jenkins 上自动打包。
   -- 每次发包都要手工验证回归？ 那就做好 UI 和 API 的自动化去快速验证。
   大家都说要做自动化，但一定要知道的是： 自动化只有在项目进行中一直在做一直在跑，才会发挥最大的效用。

4. 遇到问题，快速反映，快速沟通，快速解决。
   -- 遇到有阻碍测试的问题，马上通知对应的人去查原因；半小时不能解决，马上反映到团队负责人；
   -- 注重沟通效率：邮件不如聊天工具沟通快；打字不如打电话沟通快。 半小时在聊天工具上说不明白的事情，其实一个五分钟的电话可能就已经解决。

关于如何把自动化做进项目里面去

在给部门的同事们分享我们项目的自动化工作时遇到以下一些问题：

1. 我们对这个项目预估的工时是一个人/月，如果要做 UI 和 API 的自动化，工时是否要增加？

答：自动化的工作其实不是独立于项目测试之外的，而是把传统模式下手工测试和回归测试中的一部分或者大部分，转化为自动化脚本。
例如手工测试一轮需要 3 天，项目过程中需要测试 3 轮加上最终的回归测试，就可能需要 3*4=12 天；
如果我们在项目过程中把其中一半的用例甚至更多转化为自动化脚本，后续的测试和回归测试实际上有很大部分会被自动化测试给替代，总的时间不会增加，而且如果自动化脚本足够稳定的话，甚至会缩短整体测试的工时。

2. 我每天在项目里已经有各种杂事，怎么能抽出时间去做自动化？

答：正如我在上面所说，如果你把一些重复性的杂事，比如数据准备，比如手工回归等通过自动化脚本去替代，就可以把测试人员从其中解放出来。这不是理想形态也不是传说，而是经过大家实践后的成功经验。

3. 我想要在项目里做自动化，但是一来没接口文档，二来 UI 界面不稳定，做不起来。

答： 没有条件的时候需要主动去争取条件。 没有接口文档就要求开发整理和提供；界面不稳定就去质疑为什么要变，为什么不及时通知测试。所以对项目质量无益甚至有害的习惯都得及时挑出来去改正。

4. 我们敏捷开发过程中，有些需求经常变来变去，自动化的维护成本太高了。

答： 在项目过程中自动化要注意控制范围：

• 优先覆盖主要的业务流程。 这部分流程肯定是每天要跑的，而且能发现重要的问题，即使是经常要维护也是值得。
• 有余力的情况下覆盖部分分支业务流程。
• 不建议覆盖太多的异常流程。 异常流程往往实现的成本比较高，维护难度也大；而且即使这些流程出问题了，也不是高等级的 bug，所以可以选择性忽略。

关于沟通和情绪管理

前几天和领导做年度面谈的时候谈到的一点，自己也在反省。未来会尽力多去考虑场合和情绪的控制。

关于分享

因为新公司的网络管理比较严，所以在公司电脑上不能登录外部网站，所以最近一年多基本上都是用手机偶尔刷一下论坛的帖子；二来现在没什么时间像上一份工作一样去试用和研究不同的工具，所以最近一年都没什么分享，公众号也几乎是半年更的状态。
希望新的一年还是能抽点时间写点总结吧。