选择测试之路-路上的迷茫

2010年12月31日，由于部门搬迁至北京，选择了离开网易，当时作为技术主管负责整个体育频道赛事系统产品线。

在网易从事多年开发，还是依依不舍离开了，面临的是完全从零开始的职位：SQA，tester。

当时非常迷茫，毕业后工作目标是：架构师。怎么就突然画风转变了呢？

Raymond跟我说是团队需要，但对于为什么被选择做软件质量保证，而不是继续在研发上进取，我持有保留态度：凭什么要我转型，不是别人？于是Raymond把我的优点暴露出来了：认真、心细、负责；基于以上几点，只有“我行”，话都说到这份上了，只能给力了，安慰自己船到桥头自然直。

那时塞人到每个岗位，而我的优点可以胜任新岗位。

打心底对质量管理、SQA等概念，无从入手，没啥概念，脑子里面没有太全面的认知，即使Raymond讲过一些（觉得他也是半桶水有木有），还是觉得不够全面，不知道业界是如何做的？所以心里多多少少有点担心！担心什么呢？担心做不好，搞砸了。

几个人成立一个新团队，什么都是从零开始，关键还是要有一些流程，这几年开发中也积累了些经验，总结了些问题。在12月底，我提交了《软件质量保证第一季度计划》，这个计划后来也成为了整个质量保证体系的核心，大概 纲要如下：

1、搭建项目管理平台

2、搭建持续集成平台

3、规范开发流程

4、制定软件质量保证规范流程

5、建立缺陷管理

6、建立风险管理库、经验教训库（长远计划）

2011年1月25日，苦于没有规范的流程，做起事来还是不够顺畅，在奋战多日之后，制定了《产品研发质保流程手册》，简单来说划分了：需求、开发、发布三个阶段，每个阶段定义验收的产物。

为什么要制定这个？必须有章可依，否则步伐不稳健，走的再远，也会乱。

另外在调研期间，我意识到持续集成很重要，并按照当前的需求，重点关注以下几点：持续测试、持续审查、持续反馈。

 图：早期的开发、测试流程原型图。

期间发生的一些故事，顺带提一下。

个人方向感出现偏差，Raymond指出（感觉有人知道自己工作的重点，偏离方向的时候拉一把是好事，遇到一个靠谱的leader是很幸运的），于是我反思总结：

首先：个人这阵子存在一定问题，心态方面，在一个新的道路上，没有学会爬，就想跑，是非常不切实际的做法，应该学习《热血教练》里面的卡特教练的方式，先把基本功练扎实了，才能有胜算。不然，就得做很多次“俯卧撑”和“自杀”。

其次：个人价值应该迎合集体价值，不应该存在分歧，更不应该夸大个人形象。如果想做的更高、更有成就，就得付出的更多，这个我非常认同。

再次：我相信，圆圈，已经画好了，只要认真实施决策，圈将会被填充成饼图，即使填充过程中遇到困难，也是可以沟通解决的。而这个填充的力度，在于每个人的付出程度。

为什么这个时期容易发生偏差？刚开始做测试有点浮躁、摸不清思路，看不见远景，并且很着急找到成就感！

下了狠心：既然选择了测试，就必须突破它！！！发动封闭式的助攻。

终于到了春节，可以缓一口气了，感觉自己还没有ready，需要充电，赶紧追上去，为了摸清楚业界是如何去做，2011年春节，我放弃了一切活动，呆在家里，认真研读之前买的几本书：质量管理、缺陷预防、软件测试、持续集成等等之类，并且通过互联网了解一些公司是如何开展测试和质量管理的。可能有很多人不理解，难得放假，何不好好玩玩，放松呢？

牺牲了一个长假期，是多么可贵，反而收获更大，懂得人自然会get到。

或许大家会觉得到这个时候都很顺利，其实不是，春节期间，再一次迷茫了，凭什么放弃了开发的乐趣，测试的乐趣究竟在哪里？如果继续研发道路，会越来越接近架构师；而现在，完全从零开始折腾了。（后来证明，如果你坚持了一件事情，你不能证明它是对的，那你就是错的），后来跟Raymond在电话进行了争论，最终把目标定了下来，也许是这个时候，更加坚定了决心。

这件事，让我想起：

人的一生有许多难以取舍，

    困惑不已的锁事所纠缠着，

    这时所需的就是断然的舍弃与明智的抉择，

    唯一会限制我们的，

    是我们自己的决心。

从业的道路上，难免遭遇坎坷，要不断提升自己，也有三点切身体会：

1、如电影《热血教练》中卡特教练所说，先把基本功练扎实了，才能有胜算。既然从零开始，就不要被困惑不已的琐事所纠缠着，下决心突破，可以研读：质量管理、缺陷预防、软件测试、持续集成等书籍，并且通过互联网了解一些公司是如何开展测试和质量管理的方方面面。

2、个人价值迎合团队价值，果断取舍，为团队利益着想。

3、坚定信念，避免浮躁，把握远景，不要急于寻求成就感。

无悔选择测试之路-路上的抉择、进取

有了流程规范，接下来是实施和持续改进。这些规范运用在一个项目上，先做了三个月，不停地测试，编写功能测试用例，也走了2条弯路：

用例花了大量时间编写，就连打开浏览器、输入xx、点击登录，这些也记录了（这种是早期状况）。 我居然还请缨加入开发，因为看到一些任务完成不了。后来雷叔也指明，测试做测试应该去做的，如果我当时帮忙做开发，那么很多测试都完成不了，一样保证不了质量。

测试人员除了要了解业务，使用简单、清晰的语言结构来进行测试之外，还应该准确定位自己，明白自己在整个版本迭代中，控制质量的位置！

事后想想，那段日子锻炼了什么？那三个月无法忘记，每天高强度测试，用的最多的就是：功能测试（边界值、场景法），白盒测试。其实就是锻炼了测试的基础技能和流程管理。

后来测试管理流程逐步建立起来，但是在测试过程中，应当如何提高代码质量？这个阶段我们参考了敏捷开发中高质量 Java 代码开发实践，做了一些适合团队的改进，见下图：

这种迭代版本中java代码质量提升的模式，已经采用了将近一年，非常有效。

同年Q2，我们对测试管理进行了改进，其中是受到@段念-段文韬《组织敏捷测试》影响，采用类似“一页纸计划”的测试文档（在此要感谢@段念-段文韬）在redmine进行管理。之前每次整理测试计划，发送给开发人员，实际上耗费了一些时间，并且成效不大，现在的任务：需求、开发、测试，全部交给redmine管理，所有事情一目了然，对任何人都是可见的，有没有完成，进度如何，非常清晰。

为了规范整个开发测试流程的管理，包括开发、测试的交互，我们又制定了轻量级的 SQA框架，见下图：

图 最初制定的SQA框架（2011年3月31日）

不过此后这个框架也发生了比较大的变化，做得更好、更轻量级。无独有偶，我偶然的机会买了一本@朱少民老师的：《全程软件测试》，发觉这个SQA框架也是渗透到目前的每个环节，更适合目前团队的scrum模式，在此也要感谢@朱少民老师，真是相见恨晚，不然可以少走很多弯路！！！

大家可能会问：Scrum模式、用户故事，测试人员怎么利用？为什么想到这个？如果遗漏了测试场景，团队会很不爽，怎么避免呢？结合@Aullyxiao的《软件测试之魂》提到分层测试的想法，想了想，还可以这么整：

对于目前的开发架构来说，一个用户故事，涉及这四个点，可以从这四个点入手来进行质量保证。如何做呢？单元测试就开发人员处理了；代码审查，测试人员可以参与和监督，其实就是要保证：将开发任务与提交到SVN的代码进行关联。这样一来，当测试人员检查开发任务的时候，就可以找到改变过的代码。我曾经试过从这些代码里面查看逻辑，找到分支场景，补充到测试用例里面。

另外在此期间，还看过@架构师Jack原创的《功能测试用例基础设计模型》，这个文档2天转发已超过150次，我也向所有同行推荐该测试设计模型实例化的测试用例，供大家消化该设计模型。也借鉴了@季哥来自淘宝的《探索式测试》系列文章，包括：《探索式测试的秘密——记在淘两年》、《组合测试法中的全对偶测试法》、《探索式测试实践之缺陷大扫除和结对测试》。

当然这么多东西，我觉得自己还需要时间来消化。

继续测试之路-路上的风景

也许会有人问：有没有后悔做tester？

我过去也常问自己：做得开心吗？产品质量提升了吗？看到自己的前景了吗？找到high点了吗？

现在我可以回答：OK，我做到了，并且还可以持续做得更好。

可能有很多测试人员会问：测试人员的价值到底何在？在这里，我套用和整合朱少民老师的一些术语，给出我的回答。

我认为，Scrum中测试人员价值应当体现在：

1、预防缺陷的手段，提高洞察力，增强业务知识。

缺陷在需求、开发前期就已经存在了，关键是用什么手段去挖掘出来预防。在sprint前获取到的需求，测试人员可以站在客户角度上来阐述自己的观点，与开发人员进行充分交流和讨论，使自己在用户体验、业务逻辑等等方面的经验充分体现出来。   

2、开发过程的质量反馈

在开发过程中，测试人员除了站在客户的角度进行测试，还应当提供更全面的质量反馈，包括代码质量的检查，这个可以通过redmine与SVN双向关联来做检查依据。目前整个过程测试人员尚未参与代码编写，应当参与并推进代码评审，将代码问题及时反馈出来；并且参与或者推进单元测试，检查单元测试状态（确保单元测试达到80%以上覆盖率，帮助开发人员开发出具有良好可测试性的代码），自始至终将质量问题及时反馈出来，保证在sprint的整个过程中质量受到足够的关注，提高质量改进的持续性和可视性。

3、随着版本任务的增加，每个版本回归测试的成本增加，可以适当考虑部分稳定功能进行自动化测试。当然，这是远景。

4、持续改进、反馈，充分发挥每个版本统计报告的作用，对缺陷进行分析，总结出一些规律，帮助开发人员建立良好的习惯，改进代码的质量。

测试人员，应当在自己的道路上看到风景，以前作为开发，写好一个功能，很high；测试人员也要有这种心境，提高了产品质量，预防了缺陷，很high。找到自己的high法，才可以把测试玩得更爽 ，我知道@朱少民老师、@季哥来自淘宝、@段念-段文韬、@架构师Jack，都玩得很爽，但是有一点：要爽得靠自己，多跟高手交流，有利于提升自己，但是不要刻意复制别人成功的经验，因为每个团队的模式和环境不大相同。

测试路上总结

每个人离开自己熟悉的领域，投入到新的领域中（说实在软件测试也囊括了开发领域），必然存在一些迷茫，不知如何入手，身边如果有一个靠谱的高手，指点一下，眼前将会一片明亮。可惜，现实总是残酷的，往往很多时候，都要靠自己去摸索，只有经历了、深刻体会了，才知道如何改变，以及如何迎接新挑战，调整到恰到好处的心态。这样子，才能够稳健进入转型的轨道。不要害怕改变和投入，一定要坚定信念，在前进的道路上，多参考同行的成功经验：@朱少民老师、@段念-段文韬、@季哥来自淘宝、@架构师Jack、@Aullyxiao等等，迎合团队价值，不断修正自己的偏差，走出一条华丽的直路！

我很庆幸，经历了一个测试团队从无到有的创建，同时也帮助开发人员掌握了一些测试的基本技能，用于推进质量保证，让整个团队达到共识。现在的我，只是刚过了转型的痛苦期，测试工作也仅仅是刚刚开始，还有很多有意义的事情需要去做。

路漫漫其修远兮，吾将上下而求索！

多年后小结

1、靠谱的领导和团队很重要

我跟Raymond吵过不止一次，对于目标、方向不清晰，纠结的时候可能会大干一场，这也是很多团队创业初期会遇到的问题，目标不清晰、信任度低。优秀的人组成一个靠谱的团队，可以省去很多麻烦事情。另外还有一点，愿意给你时间试对、试错，并不是说浪费资源投入去试。

2、开发=测试，越到后面越没有边界

当初的目标是架构师，后来从业中逐步打破了开发测试的边界，才领悟到：开发就是测试，测试就是开发，架构师实际在两者之上汇集了。需要站在一个更高角度看问题，开发的功能是否合理，架构如何，在此架构下的功能带来何种体验，用户体验是否愉悦呢？

3、敏捷开发测试是必然趋势

所谓的敏捷，不要生搬硬套，要适合团队能够本土化的才是好。过程中有个环节要重视：沟通。现在分工太细化了，反而沟通成本高了，大家有没有想过这个问题，为什么呢？以前全栈（除了切页面）：后端+前端+运维+测试，都是自己弄，根本没啥沟通成本，反而效率更高，提交的功能甚至有些文档都没有。这个问题留给大家思考。

4、产品方向、面向市场的快慢程度也决定成败

开发个小功能，厉害咯；测试没问题，厉害咯，其实开发再多、再好，测试投入的再多再好，产品没市场，没人用，都是失败的。有些时候，开发、测试太纠结于细节，尽快把产品推向市场，试对试错才是硬道理，当然是在一定的质量基础之上去推市场。

5、刚起步切勿浮躁

一开始就是成功的话，可能就没有领悟到过程。不管总结反思，改进，切勿害怕进入一个新领域的陌生感，投入实战，是对是错还看当下。