软件测试管理

文章依据《我是怎样做测试管理的？》，《测试管理的一点心得体会》，对测试管理过程做了简单的描述和总结。

情景再现

有方法与无方法

 公司现状：创业公司，误打误撞进了软件这一行当，但软件这行是否可以持续走，是否要持续走，BOSS还不确定，如果卖的不好就不做软件了，改做别的。现在是生存阶段，有项目就接上。上面有BOSS关系搞定，下面有老实的干活人努力加班，项目也就过得去。

 软件测试：公司发动了所有实施顾问来测试，只有他们通过，才能去实施。实施顾问大多来自刚刚毕业的应届毕业生，对企业管理，对软件，对行业领域，都一无所知。对测试更是一窍不通。测试并没有分工，每个人都测试软件。也没有什么测试方法，也没有什么测试计划，也不知道该测什么。反正也是对软件不了解，就当是深入学习软件。

 遇到问题：开始并没有测试报告，大家发现问题，就用电话或QQ或邮件，把问题发给开发人员。谁认识那个开发人员，就发给那个开发人员，如果不认识一个开发人员，就发给老板了。报告中尽是不好用，不能用的词汇。但什么功能不好用，是怎么操作导致不好用，不好用的具体表现是什么，都没有。老板急眼了，怎么这么多问题。

 原因分析：

1. 很多问题都是每个人都反映了，其实只有一个问题，只不过大家没有分工，都测试，于是都报告；
2. 不少人见一个问题发一个邮件，所以看起来很多；
3. 有的人测试只是随便乱点乱输入，咱们软件还没有做这种破坏性操作兼容防范；
4. 不少人不了解功能，不了解行业，不了解业务，本来是对的，按他的理解是错的；
5. 有些人偷懒，今天发的是这些问题反馈，后天又是同样。

 解决措施：

1. 分工测，几个人测试一块功能；
2. 不全部测，只测试那些很常用的重点功能；
3. 不要电话、QQ、邮件来报告给单独的开发人员，给我一个人发就可以了，我来判断衡量安排。也不要随时报告。每天下班的时候来统一发送，由各个测试小组的负责人来汇总自己组内的测试，并且把重复的问题合并掉；
4. 每个测试小组的每天的测试报告要连续在一起，不要今天发今天的测试EXCEL，明天是明天的测试EXCEL，这样没有连贯性；
5. 每个问题，要标好功能模块，有测试人，有测试版本号，有测试时间，有测试操作过程，有测试输入数据，有报错截图；
6. 先测试正常的数据输入，正常的操作流程，是否能全部流程走通，是否数据保存正常，是否保存后的数据还能正确的取出来。那些临界条件测试先不要做。对于功能不易操作、界面不好看、起的窗口标题是否得当，字体是否加粗这些需求不要提。咱们目前阶段的重点是测试问题，不要把需求和找问题混在一起。

巧妇难为无米之炊

 公司现状：第一批客户的实施终于启动了，实施顾问奔向了全国。随着项目的实施，公司渐渐拢回来不少钱，但是面临了一个瓶颈，这个大项目快做完了，以后有什么活能养活现在这么多人呢。所以，最好的做法就是把现在这个项目产生的软件改改，变成一个产品，卖给其他的客户，卖的越多越好。但是，其他客户我们有关系的并不多，所以要想销售给其他客户，必须拿产品说话。于是，研发部陆续加入了专职的测试人员、文案人员、美工人员，旨在提高产品的质量和包装，希望能卖个好价格。所以说，专职的测试人员是这么来的。

 软件测试：很多软件公司没有测试人员，其原因就是老板搞定关系，程序员老实干活，项目质量虽然不行，但也能将就把钱结了。既然能赚钱，干嘛要测试人员呢。除非由于质量问题，签不到单子。除非由于质量问题，客户不验收不给尾款。除非公司所有人都测试还是无法达到客户满意的质量。只有这样，才会招聘专职的专业的测试人员。测试人员一来了，开始工作。但怎么开展测试呢？文档在哪里？

 遇到问题：

1. 对测试，对软件，对业务的理解肤浅。过去发现的问题都是小儿科，真正复杂的问题根本没有测试到。给客户一讲解，客户一问，发现原来很多功能细节没有理解，不知道怎么给客户解释；
2. 文档只有很老的设计文档，现在软件和文档已经毫无关系；
3. 测试人员硬着头皮，开始学习软件，什么是正确的什么是不正确的，测试人员也不知道，当然也不知道BUG究竟是什么样。软件质量仍然没有改进。
4. 帮助在哪里？没有？因为没有写帮助文件的人。只有打单的时候讲解的PPT；
5. 改进初期，测试来测试去，其测试结果和实施人员的测试没多大区别，都还是在门外转。
6. 老板问：这个测试人员是不是没啥能力？要不要裁掉？

 原因分析：

1. 实施顾问对软件本身的理解思路和自身的理解层次，其次是用户（客户）理解能力的高低及要求；
2. 都是程序员，谁来专门写文档。为了公司生存，我身兼数职，到处开会做项目经理或做售前，还管开发人员，还有实施人员给我打电话问软件中某个功能怎么回事，我也分身无术；都是根据实施人员、客户、销售人员、老板反映的需求和BUG修改。那些BUG和需求EXCEL表格倒是有，但没法作为测试案例编写的根据。
3. 没有写帮助文件的人。只有打单的时候讲解的PPT。
4. 由于几年发展，软件加入了大量客户的需求，很多细节的东西在帮助中也没有看到，测试人员也不知道有这个功能。

 解决措施：

1. 一方面仍然要求他们按照过去的测试问题报告流程和方法来报告实施现场中发现的问题，另一方面我自己写了FAQ给实施顾问发出去。但是实施顾问仍然问，一个问题重复的问。我说你看FAQ的第XX行。他说他看了，但没看明白（其实是对客户业务不了解，所以也不明白功能）。我就给他再解释。经过多次解释，我也了解了实施顾问的理解思路和理解层次，于是不断修正FAQ，使FAQ1.0、FAQ1.1.1这样不断发布，几乎天天发布。我现在回过头来想，帮助文件写的好不好，不能你说你自己已经写的很明白了傻瓜才看不懂，不要这样认为，这样根本不解决问题。唯一的方法就是用户理解能力有多低，你就要把帮助写的有多低，让他理解是目的，要不你还能怎样呢，就这样的人，问题还得解决。
2. 文案人员也不了解软件，她写出来的也是自己猜测，所以我已经分出来一个开发人员做项目经理，他目前专门负责把帮助文档建立起来，但是他开发人员出身不擅长写文档，但他熟知软件，所以只有他们两个人搭配才能搞定。但这种磨合，需要时间。
3. 测试人员硬着头皮，一边测试人员瞎学习瞎测试，一边项目经理和文案人员不断讲解不断编写不断审核不断修改。
4. 巧妇难为无米之炊。果不其然，测试人员有其独到的软件测试方法、软件理解方法。很快，测试人员对软件的理解不亚于那些多年的实施顾问，也不亚于程序员。找问题也越来越准确，越来越深入。
   当然，其原因也在于这个团队的成长，有专职的项目经理开始书写现有功能需求修改的设计文档。过去的，没有的，就让它过去，就让它缺失吧，但未来，不要成为过去。现在也有专职的文案，不断在修改帮助，加深了许多。测试人员现在比文案人员理解功能更细，更深入，经常提醒文案人员应该把某句话写进帮助中，否则容易被用户忽略，是个不小心就会绊倒的坑。

各司其职。对症下药

 遇到问题：在过去，服务部小姑娘老把电话转给开发人员，本来就几条枪，被客户电话吵的无法安心开发。而且客户发现开发人员接听电话处理问题更有效，所以很多客户都是直接给开发人员打电话，服务部成了虚架子，而开发人员的开发进度被拖累，叫苦不迭。

 解决措施：为了使测试人员更快速的了解客户应用操作方法，更细节的了解特个性的功能，我让测试人员也兼任研发部的技术支持。现在有了测试人员兼任技术支持，这下解放了开发人员。开发的质量和速度提高许多。

 引发问题：测试人员并没有做技术支持的经验，过了段时间就来和我诉苦，说现在服务部小姑娘啥也不干，都直接把电话转到他这里来，所以他现在已经无法测试了，成了专职的服务支持人员。如果再这样下去，软件质量无法保证，以后的技术支持压力更重，开发部就会成为开发+服务部门。

 解决措施（针对测试）：

1. 经常遇到的问题，就做成FAQ。下一次还有小姑娘问，直接让她看FAQ，拒不回答。
2. 交给他们方法和思路，不替他们亲自做。亲自看着她，让她服务支持客户。一次不会，再继续这样做第二次，必须让她自己亲自会了。
3. 每个星期六定期培训，疑问解答。并且考试。如有讲过后考试还不会者，扣钱。

 解决措施（针对服务部门）：你接待了多少客户问题，解决时间多长，多少个问题转给开发部技术支持了，这些问题的难度级别多高。根据这些指标来衡量服务部小姑娘们的技术解决问题能力。能力差的就辞退。

统一战线，旗帜分明

 遇到问题：于有时候客户报告了某个BUG，程序员一看好改就直接改掉了，改完后就直接联系客户更新了，但是并没有更改软件版本号，也没有做新的打包。于是出现了同一个版本号软件功能表现却不同。而且，由于项目组多了，每个项目组组长都各有各的原因，有时候自己就打了一个包给了客户，随便定个版本号，起的都稀奇古怪，有的叫beta版，有的叫6.0.20050203。这种情形导致了测试人员做测试的时候，开发人员说改了，测试人员说没改。开发人员说已经没有问题了，测试人员说我这里还能重复出来。于是两个人一起查，耗费了两天时间，才查出来测试人员手里的和开发人员手里的不一致。

 解决措施：

1. 开发人员绝对不能接触客户，不能接听客户电话，也不能解决客户问题，更不能给客户更新；
2. 开发人员不能没有任务分配和设计文档就擅自修改软件，否则记过处分；
3. 大家一致使用版本管理工具、BUG管理工具、需求管理工具、任务管理工具。用工具把项目经理、开发人员、测试人员、文案人员绑定在一起，按固化流程推进流转；
4. 打包发布统一交给测试人员来做，测试人员来控制是否可以发布，发布的版本号的命名。质量达不到，有权不能发布。

有的放矢，步步为营

  我们的测试已经能做边界测试、版本兼容性测试、系统兼容性测试、压力测试、安全测试、集成测试、破坏性测试。也已经在项目中应用全程测试，测试人员主要参与需求验证、设计验证、代码验证、文档验证、打包验证。

  但是，我们现在还没有实现单元测试，开发人员就这些人，项目却多。而且测试人员没有编程能力。我们也没有做更多的回归测试，毕竟测试人员数量配备太少，而项目并行太多。

  看机会吧。老板越从软件上赚钱，他才会越舍得投入软件。成本永远嫌多，利润永远嫌少。

  如果你是一名开发主管，你的老板还没有从你负责的软件中赚钱，而且是很快乐的很大规模的赚钱，而不是他靠他的人际关系和送礼吃饭支撑着，我想，他不会给你一毛钱的。你抱怨也没有用，因为你没有价值，所以投入也是没有意义。

  先去证明你的价值吧。

测试管理总结

　　1、组间合作

　　与开发、实施等组间良好的沟通与配合是非常重要的。这需要大家对目标认识的一致性及相互的理解与包容。实施人员直接面对的是用户，他们提出的任务不多，但都是比较重要的，需要直接交付于用户的。往往也是比较紧急的，所以沟通时必须确认好交付时间，以最高优先级来处理并以高质量来完成。

　　测试负责人不仅仅是关注测试那部分的工作，也需要关注整个项目的动态。实时了解项目的进度，了解每个阶段用户使用相对较多的模块，以了解本阶段的主要工作，把握本工作的重点，也能提前作好准备工作。同时发现项目在哪方面存在问题时，也可以用巧妙的方式来提醒，让他知道你是好意而不是对他工作的否定。如果经常能帮助到他们，我想对方也会欣然接受。

　　2、测试负责人的工作职责

　　沟通协调工作也必须做好，当多个任务同时提交时，一定要问清楚紧急程度，系统是否要急于发布，文档是否急于交付。不急于发布的也可以让先发布好环境，因为往往发布系统都需要一定的时间，在其它系统没发布好前可以先进行测试。每项任务都需要了解范围，预计需要投入的工作及计划安排的人员。同时要做好突发性任务的准备。

　　测试负责人要有计划性和预见性，根据之前项目的经验判断出在某个阶段会有哪些工作要做，在任务不是很繁忙的时候要提前去做，这个是非常重要的。像文档能准备的尽早准备，交付前稍做检查更新就好了。在上线前一般系统会非常忙，根本没时间去修改文档等其它工作。

　　重要的任务需要亲自把关，或安排信得过的人去检查。对于客户交付的文档对于内容和格式都务必要正确。像用户手册等是用户需要使用的，所以内容的正确性与现有系统的一致性就比较重要。对于测试用例、缺陷记录、出厂测试报告等文档的内容用户不是太关心的，格式则比内容更重要。对于发布前的那次测试一定要进行整体测试。不要相信因开发说哪些地方没改不会存在问题的说法，对于修改的模块或功能，与之相关的功能进行重点测试，未涉及到修改的模块也要把每个功能简单测试一下。开发修改缺陷时经常会把关联的地方没关注到，还有经常作了一些小的改动没有提交测试，时间久了就忘了哪些地方作了修改了。

　　把合适的人放在合适的位置。团队的每一位成员特长不可能都会一样，每个方面不可能同样的优秀。有些可能是技术方面强一些，有些在业务方面要强一些，有的可能在管理方面要强一些；有的性格开朗善于沟通，有的不善言辞但敏于思考，能耐得住寂寞。前者可以多做些沟通及工作协调的事，后者可以多安排些技术研究或检查文档等需要细心一点的工作。当然也要让组员明白，不是自己想要做什么就能做什么，一切必须以当前的任务情况来做安排，在条件许可的情况下会优先考虑。自己可以利用业余的时间去学习，充实自己，一旦机会来临才能去胜任。

　　要善于观察组内成员的工作状态，及时发现哪些人状态不好，及时沟通及协助解决。

　　要定期向上级领导汇报工作情况，让领导了解组内的工作情况，同时当需要申请资源时也会容易些。同时也需要让组员了解一下自己的工作情况，他们可能只了解你参与测试的这部分工作，其它工作并不了解。不要让组员认为什么事都让下面人做，自己却没做多少事。

　　3、组内管理

　　一个好的团队必须有良好的团队氛围，必须要有共同的目标，这点很重要。如果经常意见不一致在喋喋不休地争论，这样什么事情都不可能做好。当然这并不代表大家不能发表自己的意见。讨论问题时大家都是平等的，要尽情开放的地讨论，把大家的建议都发表出来，最后采取的方案也要取得大多数人的认同，但一旦确定一个执行方案后大家都要按照来执行。

　　要合理安排资源，以免部分人员工作强度很高，部分人员又会有空闲时间。这样也会引起忙的人心里不平衡。这个是有点难度，但需要尽可能地安排好。每个项目的测试人员要多考虑一两个备份人员，具体人数视项目情况。每个阶段每个项目的工作量都不一样，安排时根据每个项目进度情况来合理备配人员，尽量做到大家的工作量不会出现太大的差异。当任务少时，可以多安排一些研究性的工作为一个阶段的工作做准备，多安排业务交流，文档走查的工作等，也可以对前段时间的工作总结。像年初年末，工作状态可能也不会很好，此时就可以做一下总结，计划一下来年的工作。

　　每个小组的测试项目越来越多，可以采用分级管理模式，每个项目设立一位负责人，既提高了大家的责任感，提高了自己的管理能力。同时也让大家从工作中学会了换位思考，体会到做组员和负责人的立场与想法，也分担了组长的工作。