大多还未踏入或者刚刚踏入测试这一行的小伙伴都会经历一个迷茫期，那就是测试到底是干什么的。甚至有些步入测试已久的老鸟们也会时时的质疑自己正在做的事情。觉得自己就是在找茬，打杂甚至觉得自己做的事没什么意义。所以我们今天就来唠叨唠叨吧。我有幸经历了我们公司最重要的项目诞生的过程，并一直坚持到了现在。所以我以我的经历为背景跟大家探讨一下 QA 这个行业。当然我也有很多做的不好的地方，大家可以当做借鉴。这里我就不说什么测试用例设计什么的这些初级阶段了，咱们直接上核心的。
在很多公司，很多小伙伴都会迷惑一个 QA 应该干什么，有些事你觉得是打杂，有些事你觉得技术含量太高应该开发和运维做。那么 QA 到底该干什么？ 一句话总结出来就是凡是能提升质量和效率的工作，你都可以做。当然很多事情不一定要你亲力亲为，但你要有能力组织这件事情，找到合适的人去做细节。你要成为那个牵头的人，跟踪进度的人，掌控风险的人，协同各部门一起完成目标的人。说白了，你牛逼你就自己搞定。你不牛逼就组织大家一起搞定。 这其中的沟通能力和在项目中的影响力大家应该明白。我有个习惯，就是每做一件事之前都问问自己做了这件事能提高生产力么？ 如果是能，那就做。不能，那就一边去，等小爷闲的蛋疼的时候再说。我建议大家也这样，免得做了很多无用功。
举个例子，之前项目刚开始没多久的时候所有开发人员的配置都是散落在很多不同的文件里，每个模块的配置文件也都散落在不同的位置。 加之系统很复杂所以部署一个环境极其困难，当初我是废了九牛二虎之力才把项目中所有的关键配置梳理清楚，写出了自动化部署方案，这是提升效率的一个点，我能力尚可自己搞定了。但这也就造成了当时只有我能单独搭建起一套环境的窘境。我连个假都不敢请，因为公司所有的开发环境，测试环境的命脉都掌握在我一个人手里。而且这以后上线的时候，进场部署的时候得多痛苦。所以一个配置管理方案的诞生迫在眉睫，这个事情我就麻爪了。小爷我就是个二手的开发和运维，这方面菜的很没啥经验，让我自己设计一个好的配置管理架构基本是扯淡。所幸开发人员中有人做过专业运维，以前搭建过 ZK 做配置管理。所以我直接叫上他和所有模块负责人一起讨论一个配置管理方案。他写 config server，另一个人写 config client 其他模块负责人做整体迁移配置。 最后我来一个部署测试。计划基本就是这样，然后大家就各自行动。我统一排期，跟踪进度，提前把问题暴露出来等等工作。可以看到在这里我除了最后测试一下没干什么具体的事情。事情都是大家做的，我只是牵头和打杂的。就像之前说的，自动化部署这事我牛逼，所以我做。配置管理这事我不牛逼，所以我求着别人做。
影响力是 QA 的命脉。QA 在团队中一定要有足够的影响力，这样你在推行任何策略和流程的时候人家才不会把你当成个屁不理你。简单来说就是你得能让人家服你，让人家觉得你推行的东西是靠谱的。就像上面组织配置管理方案一样，我要是之前没积累出点影响力，你当他们会理我么。那怎么提升 QA 的影响力呢？我的经验是解决其他人最痛的痛点，他们会感谢你，会觉得你是有水平的。会觉得你跟他们理解的只会随便点点的 QA是有本质区别的。
举个列子，一般开发和产品最痛的痛点是什么呢？ 答案是环境，越是复杂的系统，环境越是让开发和产品人员痛苦的欲罢不能。就拿我们这来说吧，系统比较复杂。而且是多语言开发的。什么 NODE.JS，java，python，scala，c++。还得有一套 hadoop2.0 集群跑任务。搭建一套环境的成本之高令人发指。当时开发，测试，产品都用同一套环境。是各模块的开发人员临时糊出来的，每个模块的开发人员各自搭建自己的模块，然后拼成了这样的环境。大家都用一个环境的痛点就是互相影响，踩踏。这边 QA 正测呢，开发重启 server 了。 那边前端的开发人员正调试呢，后端又要重启 server 了。 产品人员内部演示呢，这边一个模块的开发又说要重启 server 了。所以当时每次开会的时候大家都在抱怨环境的互相踩踏最影响效率了，开发人员希望有自己的环境不被他人影响，产品希望有稳定的环境随时演示，QA 也希望自己的测试环境不会被开发随意重启改动。 所以那时候我就把自动化部署这个任务承接起来了。 开始引入 docker，跟每个模块的开发确认部署细节，约定部署路径，还要沟通分配专门的网段，服务器等等。然后就在某一天，10 几套环境就在 server 上拔地而起。每个开发和测试都人手一套环境，部署简单，并且每个环境都保留了 git 目录，定制了拉代码和重启服务的脚本，自动开启 ssh，mysql client 等等等等。开发可以随时在自己的环境里编辑源文件，直接在环境上开发。自此开发很 happy 了，QA 在测试的时候也不会有开发人员跑来重启环境，QA 也很 happy。 我们还专门给产品人员搞了一个稳定环境，这个环境里功能永远是可用的。所以产品也很 happy。直到现在已经在 docker 服务器上启动了 20 多套环境，开发人员反映生产力翻倍，闲聊开玩笑的时候说谁离职了你也别离职啊，你走了环境怎么办啊。虽然是开玩笑吧，这年头缺了谁地球都照样转。但是听到了以后我自己还是蛮开心的。
QA 应该是最了解项目的人，不仅是业务上的，还有产品架构，当前迭代的进度，可能的风险和问题都要了然于心。当然有广度就行了不一定要有多深。但是你一定能把握的住当前的节奏，在团队过于发散的时候负责把他们拉回来，在团队遇到问题和风险时及时告知甚至提前告知团队的成员们，在团队效率不高时引导他们。你不是项目的管理者，但你是项目的监控者。你要确保项目能如期按质保量的将产品带上线。而且大多数的时候是要权衡利弊，互相妥协的。开发和产品和 QA 之间永远在互相妥协。但如果等到快发布的时候才让大家知道问题，这时候再妥协已经来不及了。在你的列表里一定要有这么一份报告。它记录了本轮迭代所有要提测的 feature，feature 的 owner 是谁。提测的 deadline 是哪天，开发过程中有问题么，有没有提测延期的风险，提测后遇到过什么问题，测试的 QA 是谁，当前的测试进度怎么样。以及当前有多少 bug，其中 p1 和 p2 的有多少，p3，4，5 的 bug 有多少，当前的 bug 情况有可能危及到发布么。还有本轮迭代是否有非功能性的重构，优化，是否对性能有要求，如果有，性能测试的计划和用例的也要跟踪。还有兼容性，部署等等。掌控住所有的信息后你方可作出判断，对当前的情况作出风险分析，列出优先级。然后跟开发和产品一起讨论，如果都能解决当然最好。不能全都解决的话，就要根据你列出的数据和优先级，开始互相妥协了。需求该砍砍，bug 也要妥协。严格定义 bug 的严重级别。高优的修完便可，低优的妥协掉，放到下个迭代再说。
再举个例子，项目第一次发布前两个礼拜，我统计 bug 的时候发现 bug 过多，而当前仍然有很多 feature 没有开发完，预计在发布当周才能开发完。我判断以当前未完成的 feature 和 bug 量对与发布来说是一个严重的风险。于是找来产品和开发的 leader，讨论一下当前的优先级，每个模块出一个人进小黑屋修 bug，务必在下一轮测试前把 bug 量降下来。于是每个人好吃好喝供着，全都进了小黑屋修 bug 了。 还有一次在验收测试之前的那一轮测试中。第一天 QA 就发现问题比较多，这样很可能影响验收的结果。而如果验收不通过，就需要修 bug 重新验收。而我们在时间上根本没有给再跑一轮测试的 buffer。所以这时候 QA 必须站出来发出声音，把风险都提出来，于是又一堆人进了小黑屋了，没开发完的 feature 也砍了。QA 是那个总在质疑的人，我们天性使然。
我举的例子不是说有风险就要砍需求，而是各方权衡，妥协的结果。如果发布时间不可动摇，解决不了的必然就得砍。而如果需求是不可妥协的，那发布时间就得延后。就像我上面说的，一切都是三方权衡，妥协的结果。
QA 以提升产品质量为天职。找出产品的 bug 是直接的提升方式，这里面就有测试计划，测试用例的设计等等，这里我们不详说了。 但我们有一些间接的方式，一般分为两种。第一是提高生产力，就像上面的部署自动化。节省了工程师的时间成本，就是间接的提升产品质量。一般提搞生产力都是通过工程自动化，或者开发一些工具来提升效率。像我们搞得 CI，自动化测试什么的都是这一套。第二种是过程改进，通过改进当前迭代的各种流程，规范标准以减少我们不必要的人员浪费。
改进力的例子就太多了，就像刚才说的我们做的各种自动化其实就是一种改进。而在创业团队中，过程改进更为常见。一开始大家都是个人战，小团队中大家凭借优秀的个人能力就能 hold 住所有事情。但团队越来越大，产品越来越大，已经不是每个人都那么优秀了，而且即使大家都很优秀但一个人一个工作习惯。个体的不同已经给团队带来了很大的麻烦。这时候大家要开始互相妥协，统一一个相同的步调。这就是无规矩不成方圆。开发产品 QA 要经常总结，对各种流程达成一致，并全力推行下去。每个团队的情况不一样我就不举例子了。
软件行业有一句很有名的话，叫做唯一不变的事就是需求永远在变。尤其是风口浪尖的互联网行业，变化是家常便饭。 敏捷开发模型的口号也是拥抱变化。记得我之前在测试开发之路 -- 喷喷埋雷的事，吵吵代码的情中讲过在自动化测试中的应变，这依赖良好的设计和丰富的经验。有兴趣的看看之前的帖子吧。 除了在自动化中的应变，其实我们还有别的。 例如万一有个人离职了怎么办， 某件事情的 key person 请假了怎么办。提测延期，测试时间不够怎么办，服务器 down 掉，短时间内无法恢复怎么办。这些都要提前想到，免得到时候手忙脚轮的。QA 是质疑一切怀疑一切的人。千万别以为事情会按部就班的照你的意思进行下去，据我的经验，几乎没有一个项目是那么顺利的。起码排期的时候你要留 buffer，项目开展的时候前紧后松，人员上互为 back up，如果依赖集群记住一定要留个单机版的集群以防万一，掌控项目的所有信息，获得第一手信息并立刻思考解决方案。好了这点就说到这吧，这些都是经验上的东西了。我也还欠缺很多，也是时常有手忙脚乱的时候。
这个更不用说了，你再敏捷开发团队中，执行力是根本。一个字，快。没有那么长时间让你慢慢思考设计了，随着工作经验的增长你要总结出一套可用的方法论，框架，工具。关注你使用语言的各种开源项目很重要。我之前的帖子写过，能用开源的就用开源的，千万别装逼自己写。等你写出来，黄花菜都凉了。我为什么喜欢用 docker？ 因为快，搭什么服务下个官方镜像我就用，搭个 mysql 撑死 5 分钟（还是网慢的情况）。只要你对这些东西不陌生，像 test link，Jenkins，jira，wiki 等等这一套基础服务从无到有撑死也就一下午的事。抛弃你那颗想研究细节，想研究原理的心，等你空余时间再研究吧，记住项目质量优先，它永远都是最重要的。
终于说到这个了。我就不发散的说别的了。。。又要啰嗦一大堆了。 技术能力。。。是以上六点的基础，没有技术能力以上六点均为扯淡。可以看到我把技术能力列为最后一项了，因为确实当你负责一个项目的质量的时候你需要用到的技术能力越来越少，因为你需要关注的东西更多，更广。很多细节的事情，例如写自动化脚本，写测试框架可能已经交给你的同事来做了。但你千万别以为你可以不用拥有技术能力，当一个纯的 manager。那是扯淡，扯淡中的扯淡。举个例子你啥时候听说过 CTO 可以不懂代码的了？虽然他已经不用再苦逼的当码农了但是没有高超的技术能力他怎么带领技术部？同理如果你技术为 0，完全的外行领导内行。你怎么理解产品架构，怎么制定测试策略，你怎么把技术能力转变成生产力，同事在走上歧路的时候你怎么及时发现并更正。退一万步讲，你没技术能力怎么服众，怎么防止其他人糊弄你。反正如果我领导完全是个技术白痴的话我糊弄他跟糊弄孙子一样。
最后说一句，一定的技术实力是基础。。。真真的是基础。。。不要把懂技术当做很高大尚的事情。也就测试圈子觉得会写代码会搭架构就是大牛了，要知道软件这行里高手到处都是，你测试圈子里的技术人家根本不看在眼里。
好吧我又啰嗦了一堆，以上均为我个人见解，不代表广大群众。有错的有对的都请轻喷。