摘要: 我是一枚测试开发工程师，入职两年，或长或短，或深或浅，在多个项目打过游击，对，只是打游击干过接口测试，干过UI自动化，干过功能测试，干过框架开发，干过QA平台开发，对，只是干过组内一半童鞋的工号都落在 ...
| 我是一枚测试开发工程师，入职两年，或长或短，或深或浅，在多个项目打过游击，对，只是打游击干过接口测试，干过UI自动化，干过功能测试，干过框架开发，干过QA平台开发，对，只是干过组内一半童鞋的工号都落在了我后面，看起来应该似乎也许是个老运动员了？老运动员今天扯会淡（以下内容乱序排列，请读者自辩） 撤退的艺术 千古江山， 英雄无觅， 孙仲谋处。 舞榭歌台， 风流总被、 雨打风吹去。 斜阳草树， 寻常巷陌， 人道寄奴曾住。 想当年， 金戈铁马， 气吞万里如虎。 - 《京口北固亭怀古》 以上讲的是宋武帝刘裕。刘裕白手起家，底子薄，背景差，何以取天下？刘裕会打胜仗，更会打败仗。败而不溃，甚至在撤退路上给追击的敌人下些套，很好地保存了自己辛辛苦苦积蓄的实力，以图日后翻盘。 引申到我们的工作中，最典型的莫过于自动化了。 自动化不是包治百病的银弹，但也绝不是打不响的臭弹。我们订了计划乃至指标，辛辛苦苦投入人力及时间，写出那么多用例，有没有发挥预期中的作用？我们自己有没有从心底里重视自动化？自动化的结果有没有成为开发乃至项目发布的参考？如果以上都没有达到，我们也许就要考虑暂时撤退一下了。 撤退不是溃退，在决意收缩自动化工作的时候，可以想一想，自动化成效不佳的原因是什么：框架不行？用例冗余？用例质量欠佳？项目变动太大？自己水平欠佳？其它工作实在太忙？ 撤退不是溃退，用例太多维护不过来？删删减减留下核心功能，去除冗余用例；质量欠佳？加强review，严格把关；总是存在那么一个平衡点，过了这个点，自动化的投入产出是可以接受的；除此之外，为自动化配套搭建的测试环境等基础设施做好维护工作，等到有需求时，可以随时启用。 撤退是为了反击，现在不行，不代表以后不行，时刻准备好，物质上，更是心理上 关键时刻顶得上 这句话是大学军训的教官讲的，看一个兵行不行，光看平时训练不行，得看关键时刻，神马是关键时刻？董存瑞炸碉堡，黄继光堵抢眼。 引申到工作中，什么时刻最关键，上线前半天，这半天，我希望：测试环境不能挂，挂了也及时修复 or 使用备份环境 or 干脆自己电脑上搭环境；基本功能不能挂，挂了影响测试执行与心情；需求不能变，谁变我跟谁急，回到QA自身，在这半天，我希望：可以迅速回归主干功能；关注上线新功能的测试；便捷地造一些测试数据；第一时间获取开发最新提交的代码的信息；等等 为了这关键时刻，在平时多投入时间进行一些准备是完全值得的 QA也是工程师 最痛恨开发往QA正在进行工作的分支上提交半成品，QA发现问题了，就推说还在开发，浪费QA的时间与感情 据小道消息，自采用了scrum以后，部分QA的工作状态有些苦逼，咱是不是也该爆一声：QA也是工程师! 伤其十指，不如断其一指 毛主席用兵真如神和，这是句P话，但上面那句话还是很有借鉴意义的。看准了目标，就投入重兵（额外的时间和人力，或许就只是一个全职的人力），狠狠地迅速地干他一票。成了，既可以一劳永逸，又可以立起标杆，先富带动后富；败了，至少知道此路不通，又可以迅速做出调整，不至于虚度时间 耐得住寂寞，坐得住板凳 工作不容易，钞票不好赚不得不承认，在工作中，想要做出一些改进确实很难，原因是多方面的；这也反过来说明想要做出点改进，风险是必然存在的，砸时间是必须的，不成功是完全可能的。如果怕失败、怕浪费时间，就不敢下决心；如果在做了，但耐不住寂寞、沉不住气，那也难有成效 |
