挨踢项目求生法则——测试篇

摘要：

直到最后几天，测试工程师们才能见到软件的“庐山真面目”，但是不见不知道一见吓一跳，软件的问题巨多，甚至很多功能没有实现，然则距离“项目死期”（交付日）已经没有几天了！难道测试仅仅是项目后期的事情？曾经何时作为程序员的我是看不起测试的，不少程序员也不屑于去做测试这个职位，难道测试工程师真的比程序员低人一等？

 

说明：

这是“挨踢项目求生法则”系列文章，之前已经为大家分享了战略篇、团队建设篇、需求篇、设计篇、编码篇，这篇是测试篇。

什么叫挨踢项目？

IT项目，特别是软件开发项目，都属于“挨踢”项目的范畴。挨踢项目的几大特点：
1.需求不确定。
2.技术不确定。
3.工期限死。
4.预算限死
两大不确定和两大限死，你想不“挨踢”都难！

 

测试之囧

我曾经招聘了一名美女测试，面试的时候我问：为什么离开原来的公司？

美女测试答曰：原来公司测试流程不规范，给一页纸的需求就要我来测试，我希望到更规范的公司工作。

我听了后表示淡定，其实这位美女测试运气算比较好的了，很多公司的测试工作场景是这样的：

测试是没有书面化的需求的，对需求或者软件有不少不懂和困惑的地方，你可以找项目经理或某程序员寻求答案，但得到的回答是：这个你不用管，那个你也不用管，你这样测就可以了！

 

程序员 VS 测试工程师 谁更重要？

下面做个调查：

1）如果你是程序员，请回答这个问题：让你转职做测试，你愿意吗？（假设工资不变。）

估计100%会回答：不愿意！

2）如果你是测试，请回答这个问题：让你转职做程序员，你愿意吗？（也假设工资不变）

估计部分测试会回答：愿意！

如果你的回答是“愿意”，请继续回答这个问题：你觉得你能做程序员吗？

绝大部分测试是不会写程序的，所以这个问题的回答就会变成：不能:(

当然你会说有测试懂开发的！确实是有这样的情况，但这些懂开发的测试之所以懂开发，是因为他们最开始是做程序员的，后来发现自己不太喜欢技术，所以才转做测试滴。

俺从高中的时候就写代码了，非常喜欢做程序员。刚大学毕业想到北京某建筑结构软件公司做程序员，但发现人家要求是精通C++。很不好意思，我精通的是Basic，所以我退而求其次，那我应聘测试吧，希望通过测试这个跳板将来转做程序员！我心目中已经将程序员和测试工程师的重要性排了位置了，刚开始工作的几年我心里面是“鄙视”测试的，后来发现自己这个想法很有问题，特别是自己成为项目经理和公司管理者后。

如果你来做一个选择，你觉得程序员更重要，还是测试工程师呢？

 

我兼任测试主管的一个项目

我是项目经理，项目组中配有测试工程师，当时并不觉得自己兼任测试主管，后来总结一下才发现原来我干了很多测试应该干的活！

我做的几个测试的活有：

1）我每天检查程序员们开发的东西有没有偏离需求方向。
2）我对测试工程师给出很多指导，让他能规划出符合项目需求及技术特点的测试方案。
3）我会让开发也参与测试，让开发之间交叉测试，这样增加了测试的人手，保证了测试的充分度。另外一个好处就是让程序员从测试的角度思考问题，提升程序员的编程素养。
4）测试并不是后期才做的，我们当时每周六都要加班，这天干的事情就是测试和修复缺陷。

这个项目工期是3个月，我们居然提前两周搞定！ 

测试的工作其实相当重要，帮助整个项目小组始终在正确的方向上工作，减少返工和犯错。我当时能做以上的工作，一方面是我具备了权力（我是项目经理），另外一方面是因为我具备了做好测试工作的几方面的技能。

作为项目经理的我，因为正好满足下面你将要看到的技能要求，所以我才能完成上述的4个测试工作。下面我们来看看测试工程师应该具备什么技能？

 

测试工程师应该具备怎样的技能？

废话不说，请看图：

图1：测试人员应该具备的技能

不少测试只懂“测试理论和方法”，对业务一知半解，对“IT基础架构知识”、“数据库知识”、“开发知识”、“软件设计知识”的认知几乎为零。如果作为测试的你掌握的知识这么少，你能有多大的能量呢？你能在项目中干多少活呢？这样你就不能怪程序员歧视你，也不能怪所谓的公司不重视测试。

当然这个图列的要求好像太多了，如果我满足这些要求，我干嘛还做测试这个岗位呢？你说的太好了！不要急，后续为你慢慢拆解……

 

软件公司真的不重视测试吗？

有些公司配置的测试人员很少，有些项目测试时间不够就直接给客户用，美名其曰：给客户测试！

某公司老板的想法更加牛逼，他认为公司根本就不应该配备测试这个岗位，因为如果存在测试的岗位，会降低程序员的工作质量！（程序员会因为有人在后面测试，工作质量会更低）

项目出现了严重缺陷，管理者第一反应是测试质量不过关！但我们可怜的测试往往是在被缩减的时间，去内完成不可能完成的测试任务，质量又如何保证呢？

测试阶段所爆发的问题，其实80%的原因并不在测试本身，而是前期的工作没有做好。要改善这些问题，需要包括测试人员在内的全体成员一起努力！

其实很多公司并不是不重视测试，所有老板都希望软件能赚钱、项目能验收，那么一定的质量要求是必须的，测试就是保证质量的一个重要手段。下面为你分享一些求生法则，希望对你能有一些帮助。

 

法则1：测试必须具备“基本技能要求”和“进阶技能要求”

先举两个测试人员因为不具备相应的技能而导致问题的例子。

1）例1：我无法开展测试

某测试人员的工作一直不能开展，我很郁闷，他解释：这个“增加”功能一直没有做出来，虽然“修改”和“删除”功能做出来了，但因为没有“增加”功能可用，所以……

听了后我有点恼火：为什么你不能到数据库中添加一条记录，然后你不就可以去测“修改”和“删除”功能罗！

他不好意思地说：我没玩过数据库……

2）例2：需要程序员帮忙的测试

我有事找某程序员，但他不在座位不知道干嘛去了，后来我了解到原来他去帮助美女测试了，他帮忙设置测试环境，包括：安装服务器的操作系统、安装数据库、安装程序、设好配置文件等等。

我觉得他做得挺好的，大家就应该互相帮忙嘛。但下一个版本，他又重复做类似的事情。

我问：上次你没有教会她吗？这次让她自己搞定就行了。

他说：她好像不太愿意学……

类似的事情我遇到的不少，由于测试人员掌握得知识太少了，以致很多工作都需要别人准备好安排好他才能做。而更让我气愤的是，有些测试学习的欲望很弱，而且对测试工作的认识很肤浅。一些测试认为：测试工作就是软件做好能见到界面后，我在界面上点鼠标和敲键盘就可以了，高级一点的测试工作就是能用LoadRunner之类的工具来做性能测试。

其实大部分测试都是追求进步的，“学习欲望弱”很可能是没有认识到自己需要学什么，没有打牌自己固有的思维框框，没有能发挥自己的强大潜力。要改善测试工作，作为测试人员的你首先应该自我检讨，看看有什么可以改善的地方。

“图1：测试人员应该具备的技能” 中列出的要求，你必须至少要达到“基本技能要求”和“进阶技能要求”这两个层次。只要你有心去学，只需要3-6个月你就可以基本满足这两个层次的要求。而“高级技能要求”难度有点大，一般没有3年以上的相关工作经验是很难满足的，你可以考虑将这方面列为你的发展方向。只要你达到“基本技能要求”和“进阶技能要求”，你的能量将会成几倍爆发！

 

法则2：拒绝二手需求

“二手需求”就是项目经理获取需求后，将需求传达给测试，这样就变成二手需求了。

但这只是理想境界，通常是项目经理将需求传递给开发，然后开发告诉测试你怎样测就可以了。所以实际情况是，我们测试得到的是三手甚至三手以上的需求！

让测试获取一手需求的做法：

1）测试人员参与到需求调研中来，甚至让测试成为需求负责人；
2）需求文档不要等全部写好才给测试看，每写一部分就要与测试沟通。

 

法则3：测试至少要成为第二熟悉需求的人

项目中最熟悉需求的人通常就是项目经理，或者是需求分析师（产品经理）。

测试至少要成为第二个最熟悉需求的人，并且要争取成为第一位，将项目经理“干掉”！

 

法则4：拒绝半个人

不少项目后期才安排测试人员进入，而且测试人员还需要同时负责另外一个项目的测试，你最多只能得到“半个测试工程师”。

测试需要从项目的一开始就介入，并且每个项目至少要配备一名“完整”的测试。

 

法则5：是不是缺陷，测试说了算！ 

有一个缺陷，测试认为是缺陷，但开发认为不是，并且用一堆测试听不懂的话来解释这不是缺陷。

这种状况很常见，你们会用哪种方法裁决？

A）测试因为听不懂，所以最终被开发“说服”，这个不是缺陷。
B）交项目经理裁决，项目经理通常是开发出身的，所以最后就会变成这个不是缺陷。
C）交客户裁决。
D）少数服从多数。测试一定是少数，所以结果你懂的……

我以前的做法就是交项目经理裁决，后来觉得可以做得更好，我将做法改成：其他人可以提建议，但是不是缺陷的决定权在于测试！

我这样做是因为：

1）测试的角度更接近客户，他的判断更靠谱。
2）测试因为有这样的一个责任和权力，他工作会更投入，会更加努力提升水平。
3）“是不是缺陷”和“能不能按时发布”，两个问题要分开处理。不能因为要按时发布而掩盖质量问题，有质量问题也可以按时发布的嘛，但如果缺陷被掩盖掉了，就相当于埋下定时炸弹。

 

法则6：测试获取开发代码

请先看一个案例。

案例：需要界面规格说明的测试

某测试提出这样的要求，希望开发人员能提供界面的详细规格说明，以便可以开始准备测试用例，为正式测试做好准备。

开发人员反对这样的要求，因为这事情太浪费时间了，而且界面经常会变和调整的，这个文档我岂不是要天天改！

这是事情解决起来很简单，每一位测试的电脑上都装上开发工具，每天测试就好像开发一样去获取代码，测试每天干这些事情：

1）编译代码，检查是否编译通过。如果发现编译不通过，项目小组发达了，今天有人请吃饭，请客的人就是让代码编译不通过的代码提交者。
2）如果编译通过，那就进行“冒烟测试”。冒烟测试干的事情就是将主干业务流程走一遍，将所有能点的按钮和菜单走一遍，看看会不会出错。如果出错，那恭喜你，又有人请吃饭了！
3）对照需求检查程序是否在正确的轨道上，及时提出易用性方面的改进建议。

这样干其实就已经做到测试前置了，这样做就不会出现直到正式测试阶段才能见到软件庐山真面目的情况，问题不会在最后才爆发出来，前期已经发现并避免了。

要做这个事情，测试并不需要懂开发，会用开发工具，会编译软件就可以了。有条件的时候，测试还可以去学习代码，甚至逐步开始写一些测试代码呢！

 

法则7：人人都是测试

一般软件公司开发与测试的人数比例，大概是 4-8:1，当然也会有比较悲剧的公司是 20+:1 的。

我觉得比较合理和比较符合现实的比例也就是 4-6:1。我们就是按这样来配置的，但仍然会出现测试人数不够的情况，那是不是需要招聘更多测试呢？

如果已经做到法则6，测试的工作已经前置，那么到正式测试阶段，测试工作量峰值将会下降不少，但仍然是不够人数做测试的，这个时候本法则“人人都是测试”就适用了！

测试要实现做好测试方案，到正式测试阶段，将测试方案中的工作分派给开发，让开发也带上测试的帽子进行测试，记住基本原则就是不要让开发测自己负责的模块就行了。

 

法则8：测试设计的难度不亚于软件设计

我将测试方案及工作的规划，称之为“测试设计”。

如果测试只懂业务是很难胜任测试工作的，请看以下案例。

案例：某技术要求高的系统

该系统有几个技术难点和测试难点：

1）B/S架构，但界面的易操作性要求很高，写了很多JS脚本。系统需要在IE6、7、8上能正常运行。
2）系统需要部署在网络负载平衡的环境上。
3）系统有很多Windows Service服务，要定时生成很多数据。
4）系统需要满足一定的并发访问量要求。

如果不具备“图1 测试人员需要具备的技能”中的“进阶技能要求”和“高级技能要求”，你将会对这些测试难点素手无策。

当时我们的测试没有这么厉害，我相信很多项目的测试也不会这样厉害，而很多项目其实是有很多技术要求和测试难点的，那我们该怎样办？

记住“法则7 人人都是测试”，项目经理或项目的技术大牛就应该承担起测试设计的工作，但要注意要带上测试一起来做，训练测试逐步掌握这些技能。

 

法则9：不需要写面面俱到的测试用例 

曾经见过某领导对测试的要求很“苛刻”，他要求测试无论事无大小必须写出面面俱到的测试用例。比方说一个登陆系统的功能，如果按照该领导的要求，要将所有测试数据都写清楚，那么写出来的测试用例至少需要10页以上的A4纸。

这是一个比较极端的真实案例，稍微没有那么极端的情况是，要求所有的需求都需要对应有文档化的测试用例。

在软件开发工作当中，其实有些工作是属于“常识性”的，你闭着眼睛也会做的，这些内容就没有必要文档化。

比方说我让你写一个吃饭说明，你会这样写吗？

1）用一只手拿起筷子；
2）用另外一只手捧起碗；
3）用筷子将碗中的饭扒到嘴中，记得要张大口噢；
……

你看了上面这段描述，不知道吐血了没有？

我们只需要对比较复杂的、容易出错的、有难度的地方，写出相应的测试用例，测试用例的描述在于描述清楚测试思路，不需要事无大小都写下来。

当条件成熟的时候，公司可以逐步建立测试用例库，对常见的情况建立测试指南，让所有的测试人员去学习和参考，项目中遇到类似的情况就可以直接参照用例库了，不需要再写一次测试用例。

 

法则10：测试也是开发，开发也是测试

当我是一个人写程序的时候，我就是按照“法则10”来干的；当我和另外一位程序员负责一个软件的时候，那三年时间我们基本上也是按照“法则10”来干的。

当我做的项目的人数是几个人以上后，这个“法则10”就很难实施了，不是我不想实施，而是因为各种客观条件并且我的领导不同意。

我的观点是：一名优秀的测试同时也应该是一名优秀的开发，一名优秀的开发同时也应该是一名优秀的测试！

但目前常见的现状是：

1）能做好测试的优秀开发有，但数量不多；更多的是没有测试意识，代码质量很差的程序员。
2）测试大部分是不懂开发的，我们认为优秀的测试往往也是不懂开发。

我曾经想尝试这样的管理模式：

1）开发必须每年有一段时间换岗做测试工作。
2）测试也需要每年有一段时间换岗做开发工作。
3）干脆就不招聘测试，只招聘开发，但要求该岗位也要负责测试工作。

第1）点很难实现，因为开发基本不愿意去做测试。

第2）点基本无可能，因为测试编码基本功通常为零，而且很多测试是因为不喜欢编码才做测试的，悲剧！

对于第3）点，我承认，我是在“痴心妄想”！

现实可行的做法可能是这样的：

1）让有培养潜质的开发带上测试的帽子，负责某些项目的测试工作。该方法能提升开发的编程素养，也可以培养综合性人才。
2）让具备条件的测试在某项中带上程序员的帽子，让他写代码。

我一直没有能在我管理的公司中尝试这样的管理模式，但我相信这样的管理方法一定会极大的提升公司的生产力和战斗力，看你敢不敢和能不能去尝试了？

 

小结：

要改善测试工作首先要从思想上重新定位：

1）测试并不是一个低技术含量的工作，相反，测试工作重要性和难度并不亚于软件设计。
2）测试并不是项目后期才开展的工作，而是从头到尾都需要的工作，是保证项目始终在正确轨道上的重要工作。

如果你是测试工程师，提升你的水平，发挥你更大的能量，这是你的当务之急。想别人和公司重视你，是靠你自己的实力去争取的！

如果你是项目管理者，你要注意的是：

1）项目管理者最优先要做的事情就是保证大家都在做正确的事情，你要从测试的角度从项目一开始就进行监控。
2）给测试工程师权力和成长机会，帮助他们成长，让测试工程师分担你更多的工作。
3）测试其实是一种帽子，其实谁都可以戴，要善于安排测试人力资源。

如果你是程序员，你需要多从测试的角度来检验自己的工作，你的工作目标就是不让测试工程师测出任何缺陷，将测试工程师“废掉”！

 

 

如果本文对你有帮助，麻烦点一下“推荐”啦，谢谢！

 

 

作者：张传波

创新工场创业课堂（敏捷课程）讲师

软件研发管理资深顾问

CMMI首席专家

《火球——UML大战需求分析》作者

软件知识原创基地创办人