从软件测试看挨踢项目求生法则(2)

　　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 的。

原文转自：http://www.cnblogs.com/umlonline/p/3485631.html