这一个月，断断续续在看《敏捷软件测试：测试人员与敏捷团队的实践指南》这本书，看的中文版，看了四分之三了，这里大概记录一下自己的感受和受益。 之前一直听说敏捷这个词，但从来没有在项目中实施过，一直觉得这个东西势在必行，但又不知道从何下手。这本指南给出了很多实际操作上的指导，再结合今年的公司项目敏捷实践，深深觉得理想和现实的鸿沟如此之深，吐槽中……
感受最深的，是对于其中融汇的敏捷思想。在我看来，敏捷不光是软件行业，简直是为人处世中的方法论，其中提到的面对未知的勇气，Just do it，成功最重要的因素在于尽快动手去做，争取持续的回查来改进策略而不是从一开始就要找出最完美的方法，这些不光是自己今后做事，还是以后教孩子，都是妥妥的素材。过去几十年的经历，加上工科思维和职业习惯，让我习惯了去计划，有时也很困扰自己的完美主义，习惯了计划好一切，再开始去做，面对现实的庞杂，有些时候简直是自己把自己吓住了。在这个时候，所幸看到了敏捷的微光，step by step，一次一小步，增量式地去处理问题，等完成的时候，才会感慨于自己的能力，竟然把这样一件毫无章法和头绪的事情做完了。人生，只要不是生老病死，还真没什么办不成的难事。
说回书中对实际工作的指导，强调了测试人员从项目之初就要绝对的参与度，之前的工作总是跟随研发的节奏走，觉得自己人微言轻，说了别人也不听，但其实，尊重是相互的，也是自己挣回来的。没有什么比实际的数据和作出的成绩更有说服力的，要说服别人同意你的提案，可以先从简单入手，哪怕找到一个支持者，让他（试用），如果好用，自然会推广，毕竟没有人会放弃省时省力还高效的方法。这比起一味抱怨自己所在的单位体制，吐槽领导的刚愎自用要有效多了，至少这是自己现阶段能做的。 到了敏捷阶段，要弱化文档和规程，保持灵活和敏捷，一切都是为了产品，如果一个东西摆明了不具备指导意义，后期也不会去维护，为何要花大力气去做它呢，这有些类似中国武侠小说中提倡的无招胜有招了，但无招并不是心中无招，相反，心中是有大丘壑的，一切都是为了赢，至于用什么招数制敌，根据需要变通，比起还没出招之前，把所有的武功招数演练一番，那是有效多了吧！
书中提到了测试矩阵和测试表格，这个东西在之前看google软件测试之道的时候，也出现过，尤其是测试矩阵，能够知道目前测试的广度和深度，知道目前产品的局限在哪里，个人认为是很有必要的，但是，通信行业的复杂度，比起纯软件行业，那是高了不少等级，其中还牵涉到协议和信号的编解码，如何绘制这个测试的地图，如何控制地图的边界而不失控，如何平衡测试成本和产品质量，都是需要考虑的问题。问题很多，但考虑一下敏捷的思路，持续迭代，增量式开发，从最简单的做起。先就某一个功能把这个地图绘制出来，再考虑一个模块，再考虑到小的系统，最后考虑联合所有组件组成的大系统。
关于自动化测试，这块是这两三年我一直在从事的工作。用例写了不少，工具也了解了很多，但对于自动化测试没有什么大局观，更谈不上设计。什么情况下要自动化，什么情况下不宜自动化，自动化的阻碍是什么，决策层希望看到的自动化成果是什么，很少去独立思考。这次的书里提供了一些答案，仔细品味一下，觉得很有道理，事实也确实如此。如为何要自动化，我们需要自动化来提供安全网、提供基本的反馈、保持技术债务的最小化并帮助驱动编码。应自动化回归测试，在自动化构建过程中运行它们，并修补产生缺陷的根源，这可以减少技术债务并增加健壮的代码。将回归测试和单调乏味的手动任务自动化，可以让团队有时间做更重要的工作，例如探索性测试。若没有自动化的回归测试，手动的回归测试的范畴将会增长，最终结果可能只是被忽略。有自动化和自动化构建过程的团队可以保持稳定的速度。这些话真是说到了我的痛处，由于前几年，公司的部分产品处于维护阶段，早期也并未考虑过自动化测试和敏捷开发，更没有考虑过可测试性，到了后期，回归测试简直让人疲于应对，也产生了一堆一次过的用例。这两年，有的项目已经开始重视自动化测试，但仍然是浮于表面，做的是自动化测试金字塔中最顶层的工作，如书中所说，这部分的ROI是最低的，因为涉及到GUI表现层，是最不建议自动化的，对于接口测试、组件测试和单元测试，我们并未深入，越往下，尤其是单元测试，投入产出比才是最高的。
由于研发代码资料库不共享，距离敏捷测试，仍然有一段路要走。 目前看了书的感受大致是这些，不知是否是翻译的原因，这种本来是实践指导的书，一般外国人都是写得很通俗易懂的，但这本书的某些部分读起来还是比较拗口，有些段落会让你认得起字，读不懂文。
又感慨一次，当今世界，英语真是太重要了！以后小孩的英语教育要严抓！！