风语者---走出软件作坊：三五个人十来条枪 如何成为开发正规军（二十九）
我们公司开始也是没有测试的。
公司是创业公司，我空降的时候连卖什么东西都不确定。公司的创业仅仅出于老板对原公司的一口气，觉得还不如自己单干快活，公司要成为什么公司，可能想法很多。咨询？培训？认证？通信？数据挖掘？我从老板的书架上找到过这些书。但是真正卖什么？卖这不好卖，卖那不好卖。误打误撞就进了软件这一行当，但软件这行是否可以持续走，是否要持续走，老板还不确定，如果卖的不好就不做软件了，改做别的，现在是生存阶段，就顾不了许多了，有项目就接上。上面有老板关系搞定，下面有老实的干活人努力加班，项目也就过得去。
没想到，软件这条路，居然走下去了，还接了一个大活儿，安装的点很多，涉及的用户很多，从海南到新疆，从深圳到山东枣庄。
公司发动了所有实施顾问来测试，只有他们通过，才能去实施。
实施顾问大多来自刚刚毕业的应届毕业生，对企业管理，对软件，对行业领域，都一无所知。对测试更是一窍不通。
测试并没有分工，每个人都测试软件。也没有什么测试方法，也没有什么测试计划，也不知道该测什么。反正也是对软件不了解，就当是深入学习软件吧。
开始并没有测试报告，大家发现问题，就用电话或QQ或邮件，把问题发给开发人员。谁认识那个开发人员，就发给那个开发人员，如果不认识一个开发人员，就发给老板了。报告中尽是不好用，不能用的词汇。但什么功能不好用，是怎么操作导致不好用，不好用的具体表现是什么，都没有。
老板急眼了，怎么这么多问题。
我说有五个原因： 1很多问题都是每个人都反映了，其实只有一个问题，只不过大家没有分工，都测试，于是都报告 2不少人见一个问题发一个邮件，所以看起来很多。 3有的人测试只是随便乱点乱输入，咱们软件还没有做这种破坏性操作兼容防范。 4不少人不了解功能，不了解行业，不了解业务，本来是对的，按他的理解是错的 5有些人偷懒，今天发的是这些问题反馈，后天又是同样
我说，基于现状，我给大家一个测试方法： 1分工测，几个人测试一块功能 2不全部测，只测试那些很常用的重点功能 3不要电话、QQ、邮件来报告给单独的开发人员，给我一个人发就可以了，我来判断衡量安排。也不要随时报告。每天下班的时候来统一发送，由各个测试小组的负责人来汇总自己组内的测试，并且把重复的问题合并掉 4每个测试小组的每天的测试报告要连续在一起，不要今天发今天的测试EXCEL，明天是明天的测试EXCEL，这样没有连贯性 5每个问题，要标好功能模块，有测试人，有测试版本号，有测试时间，有测试操作过程，有测试输入数据，有报错截图 6先测试正常的数据输入，正常的操作流程，是否能全部流程走通，是否数据保存正常，是否保存后的数据还能正确的取出来。那些临界条件测试先不要做。对于功能不易操作、界面不好看、起的窗口标题是否得当，字体是否加粗这些需求不要提。咱们目前阶段的重点是测试问题，不要把需求和找问题混在一起。
方法执行下去，问题少了许多。
前几天大家还在抱怨这样的软件简直是烂软件，让他们拿给客户，肯定会被客户打死。
现在呢，才几天功夫，实施顾问已经觉得可以去实施了。
这就是有方法和没方法的区别。
第一批客户的实施终于启动了，实施顾问奔向了全国。
到了真实的客户那里，才发现自己的测试，自己对软件，对业务的理解是多么的肤浅。过去发现的问题原来都是小儿科，真正复杂的问题根本没有测试到。给客户一讲解，客户一问，发现原来很多功能细节没有理解，不知道怎么给客户解释。于是纷纷打电话回来问。而能回答的人只有我，我成了接线生。
我当然不能成为接线生。我一方面仍然要求他们按照过去的测试问题报告流程和方法来报告实施现场中发现的问题，另一方面我自己写了FAQ给实施顾问发出去。但是实施顾问仍然问，一个问题重复的问。我说你看FAQ的第XX行。他说他看了，但没看明白（其实是对客户业务不了解，所以也不明白功能）。我就给他再解释。经过多次解释，我也了解了实施顾问的理解思路和理解层次，于是不断修正FAQ，使FAQ1.0、FAQ1.1.1这样不断发布，几乎天天发布。我现在回过头来想，帮助文件写的好不好，不能你说你自己已经写的很明白了傻瓜才看不懂，不要这样认为，这样根本不解决问题。唯一的方法就是用户理解能力有多低，你就要把帮助写的有多低，让他理解是目的，要不你还能怎样呢，就这样的人，问题还得解决。
随着项目的实施，公司渐渐拢回来不少钱，但是面临了一个瓶颈，这个大项目快做完了，以后有什么活能养活现在这么多人呢。所以，最好的做法就是把现在这个项目产生的软件改改，变成一个产品，卖给其他的客户，卖的越多越好。但是，其他客户我们有关系的并不多，所以要想销售给其他客户，必须拿产品说话。于是，研发部陆续加入了专职的测试人员、文案人员、美工人员，旨在提高产品的质量和包装，希望能卖个好价格。
所以说，专职的测试人员是这么来的。
很多软件公司没有测试人员，其原因就是老板搞定关系，程序员老实干活，项目质量虽然不行，但也能将就把钱结了。既然能赚钱，干嘛要测试人员呢。除非由于质量问题，签不到单子。除非由于质量问题，客户不验收不给尾款。除非公司所有人都测试还是无法达到客户满意的质量。只有这样，才会招聘专职的专业的测试人员。
测试人员一来了，开始工作。但怎么开展测试呢？文档在哪里？
文档只有很老的设计文档，现在软件和文档已经毫无关系。为什么？原因有二：
1都是程序员，谁来专门写文档。为了公司生存，我身兼数职，到处开会做项目经理或做售前，还管开发人员，还有实施人员给我打电话问软件中某个功能怎么回事，我也分身无术。 2都是根据实施人员、客户、销售人员、老板反映的需求和BUG修改。那些BUG和需求EXCEL表格倒是有，但没法作为测试案例编写的根据。
测试人员硬着头皮，开始学习软件。
帮助在哪里？没有？
对，没有，因为没有写帮助文件的人。只有打单的时候讲解的PPT。
测试员晕倒。
晕完继续学习软件，什么是正确的什么是不正确的，测试人员也不知道，当然也不知道BUG究竟是什么样。软件质量仍然没有改进。
老板问：这个测试人员是不是没啥能力？要不要裁掉？
我说：不是他能力不行，而是咱们过去为了生存欠了太多东西。我们这会是在补过去的课。现在的文案人员正在补帮助。有了帮助，就有了什么是正确的标准。但现在的问题是，文案人员也不了解软件，她写出来的也是自己猜测，所以我已经分出来一个开发人员做项目经理，他目前专门负责把帮助文档建立起来，但是他开发人员出身不擅长写文档，但他熟知软件，所以只有他们两个人搭配才能搞定。但这种磨合，需要时间。
就这样，一边测试人员瞎学习瞎测试，一边项目经理和文案人员不断讲解不断编写不断审核不断修改。
测试人员终于可以编写测试案例了。但他对软件也是初步了解。由于几年发展，软件加入了大量客户的需求，很多细节的东西在帮助中也没有看到，测试人员也不知道有这个功能。所以测试来测试去，其测试结果和实施人员的测试没多大区别，都还是在门外转。
老板又开始沉不住气了，旁敲侧击想裁掉测试人员，觉得他的存在没多大意义，还是实施人员测试好。但是由于专职测试员的招聘是我提出来的，也是我的直接手下，而且这个测试人员也老实，干活勤勤恳恳，老板实在找不出什么把柄把这位开掉。
我说：他来自著名的外包公司，专职做测试，我相信他是专业的。只不过咱们过去缺的太多，所以他想测试，也是巧妇难为无米之炊。咱们可以继续看看。
果不其然，测试人员有其独到的软件测试方法、软件理解方法。很快，测试人员对软件的理解不亚于那些多年的实施顾问，也不亚于程序员。找问题也越来越准确，越来越深入。
当然，其原因也在于这个团队的成长，有专职的项目经理开始书写现有功能需求修改的设计文档。过去的，没有的，就让它过去，就让它缺失吧，但未来，不要成为过去。现在也有专职的文案，不断在修改帮助，加深了许多。测试人员现在比文案人员理解功能更细，更深入，经常提醒文案人员应该把某句话写进帮助中，否则容易被用户忽略，是个不小心就会绊倒的坑。
为了使测试人员更快速的了解客户应用操作方法，更细节的了解特个性的功能，我让测试人员也兼任研发部的技术支持。有服务部的小姑娘无法解决的问题，转到你这里解决。否则，在过去，服务部小姑娘老把电话转给开发人员，本来就几条枪，被客户电话吵的无法安心开发。而且客户发现开发人员接听电话处理问题更有效，所以很多客户都是直接给开发人员打电话，服务部成了虚架子，而开发人员的开发进度被拖累，叫苦不迭。现在有了测试人员兼任技术支持，这下解放了开发人员。开发的质量和速度提高许多。
但测试人员并没有做技术支持的经验，过了段时间就来和我诉苦，说现在服务部小姑娘啥也不干，都直接把电话转到他这里来，所以他现在已经无法测试了，成了专职的服务支持人员。如果再这样下去，软件质量无法保证，以后的技术支持压力更重，开发部就会成为开发+服务部门。
我给测试人员出了三个方法： 1经常遇到的问题，就做成FAQ。下一次还有小姑娘问，直接让她看FAQ，拒不回答。 2交给他们方法和思路，不替他们亲自做。亲自看着她，让她服务支持客户。一次不会，再继续这样做第二次，必须让她自己亲自会了。 3每个星期六定期培训，疑问解答。并且考试。如有讲过后考试还不会者，扣钱。
另外，我也对服务部下了一个考核（当时我已经统管的服务部）：你接待了多少客户问题，解决时间多长，多少个问题转给开发部技术支持了，这些问题的难度级别多高。根据这些指标来衡量服务部小姑娘们的技术解决问题能力。能力差的就辞退。
这几招后，服务部的技术支持能力蹭蹭的提高了。真是没有鞭子不干活。测试人员兼任技术支持越做越轻松了。
我还把版本管理、打包发布交给了测试人员。起源在于有时候客户报告了某个BUG，程序员一看好改就直接改掉了，改完后就直接联系客户更新了，但是并没有更改软件版本号，也没有做新的打包。于是出现了同一个版本号软件功能表现却不同。而且，由于项目组多了，每个项目组组长都各有各的原因，有时候自己就打了一个包给了客户，随便定个版本号，起的都稀奇古怪，有的叫beta版，有的叫6.0.20050203。这种情形导致了测试人员做测试的时候，开发人员说改了，测试人员说没改。开发人员说已经没有问题了，测试人员说我这里还能重复出来。于是两个人一起查，耗费了两天时间，才查出来测试人员手里的和开发人员手里的不一致。
我又下了几招： 1开发人员绝对不能接触客户，不能接听客户电话，也不能解决客户问题，更不能给客户更新 2开发人员不能没有任务分配和设计文档就擅自修改软件，否则记过处分 3大家一致使用版本管理工具、BUG管理工具、需求管理工具、任务管理工具。用工具把项目经理、开发人员、测试人员、文案人员绑定在一起，按固化流程推进流转。 4打包发布统一交给测试人员来做，测试人员来控制是否可以发布，发布的版本号的命名。质量达不到，有权不能发布。
现在，我们的测试已经能做边界测试、版本兼容性测试、系统兼容性测试、压力测试、安全测试、集成测试、破坏性测试。也已经在项目中应用全程测试，测试人员主要参与需求验证、设计验证、代码验证、文档验证、打包验证。
但是，我们现在还没有实现单元测试，开发人员就这些人，项目却多。而且测试人员没有编程能力。我们也没有做更多的回归测试，毕竟测试人员数量配备太少，而项目并行太多。
看机会吧。老板越从软件上赚钱，他才会越舍得投入软件。成本永远嫌多，利润永远嫌少。
如果你是一名开发主管，你的老板还没有从你负责的软件中赚钱，而且是很快乐的很大规模的赚钱，而不是他靠他的人际关系和送礼吃饭支撑着，我想，他不会给你一毛钱的。你抱怨也没有用，因为你没有价值，所以投入也是没有意义。
先去证明你的价值吧。
公司是创业公司，我空降的时候连卖什么东西都不确定。公司的创业仅仅出于老板对原公司的一口气，觉得还不如自己单干快活，公司要成为什么公司，可能想法很多。咨询？培训？认证？通信？数据挖掘？我从老板的书架上找到过这些书。但是真正卖什么？卖这不好卖，卖那不好卖。误打误撞就进了软件这一行当，但软件这行是否可以持续走，是否要持续走，老板还不确定，如果卖的不好就不做软件了，改做别的，现在是生存阶段，就顾不了许多了，有项目就接上。上面有老板关系搞定，下面有老实的干活人努力加班，项目也就过得去。
没想到，软件这条路，居然走下去了，还接了一个大活儿，安装的点很多，涉及的用户很多，从海南到新疆，从深圳到山东枣庄。
公司发动了所有实施顾问来测试，只有他们通过，才能去实施。
实施顾问大多来自刚刚毕业的应届毕业生，对企业管理，对软件，对行业领域，都一无所知。对测试更是一窍不通。
测试并没有分工，每个人都测试软件。也没有什么测试方法，也没有什么测试计划，也不知道该测什么。反正也是对软件不了解，就当是深入学习软件吧。
开始并没有测试报告，大家发现问题，就用电话或QQ或邮件，把问题发给开发人员。谁认识那个开发人员，就发给那个开发人员，如果不认识一个开发人员，就发给老板了。报告中尽是不好用，不能用的词汇。但什么功能不好用，是怎么操作导致不好用，不好用的具体表现是什么，都没有。
老板急眼了，怎么这么多问题。
我说有五个原因： 1很多问题都是每个人都反映了，其实只有一个问题，只不过大家没有分工，都测试，于是都报告 2不少人见一个问题发一个邮件，所以看起来很多。 3有的人测试只是随便乱点乱输入，咱们软件还没有做这种破坏性操作兼容防范。 4不少人不了解功能，不了解行业，不了解业务，本来是对的，按他的理解是错的 5有些人偷懒，今天发的是这些问题反馈，后天又是同样
我说，基于现状，我给大家一个测试方法： 1分工测，几个人测试一块功能 2不全部测，只测试那些很常用的重点功能 3不要电话、QQ、邮件来报告给单独的开发人员，给我一个人发就可以了，我来判断衡量安排。也不要随时报告。每天下班的时候来统一发送，由各个测试小组的负责人来汇总自己组内的测试，并且把重复的问题合并掉 4每个测试小组的每天的测试报告要连续在一起，不要今天发今天的测试EXCEL，明天是明天的测试EXCEL，这样没有连贯性 5每个问题，要标好功能模块，有测试人，有测试版本号，有测试时间，有测试操作过程，有测试输入数据，有报错截图 6先测试正常的数据输入，正常的操作流程，是否能全部流程走通，是否数据保存正常，是否保存后的数据还能正确的取出来。那些临界条件测试先不要做。对于功能不易操作、界面不好看、起的窗口标题是否得当，字体是否加粗这些需求不要提。咱们目前阶段的重点是测试问题，不要把需求和找问题混在一起。
方法执行下去，问题少了许多。
前几天大家还在抱怨这样的软件简直是烂软件，让他们拿给客户，肯定会被客户打死。
现在呢，才几天功夫，实施顾问已经觉得可以去实施了。
这就是有方法和没方法的区别。
第一批客户的实施终于启动了，实施顾问奔向了全国。
到了真实的客户那里，才发现自己的测试，自己对软件，对业务的理解是多么的肤浅。过去发现的问题原来都是小儿科，真正复杂的问题根本没有测试到。给客户一讲解，客户一问，发现原来很多功能细节没有理解，不知道怎么给客户解释。于是纷纷打电话回来问。而能回答的人只有我，我成了接线生。
我当然不能成为接线生。我一方面仍然要求他们按照过去的测试问题报告流程和方法来报告实施现场中发现的问题，另一方面我自己写了FAQ给实施顾问发出去。但是实施顾问仍然问，一个问题重复的问。我说你看FAQ的第XX行。他说他看了，但没看明白（其实是对客户业务不了解，所以也不明白功能）。我就给他再解释。经过多次解释，我也了解了实施顾问的理解思路和理解层次，于是不断修正FAQ，使FAQ1.0、FAQ1.1.1这样不断发布，几乎天天发布。我现在回过头来想，帮助文件写的好不好，不能你说你自己已经写的很明白了傻瓜才看不懂，不要这样认为，这样根本不解决问题。唯一的方法就是用户理解能力有多低，你就要把帮助写的有多低，让他理解是目的，要不你还能怎样呢，就这样的人，问题还得解决。
随着项目的实施，公司渐渐拢回来不少钱，但是面临了一个瓶颈，这个大项目快做完了，以后有什么活能养活现在这么多人呢。所以，最好的做法就是把现在这个项目产生的软件改改，变成一个产品，卖给其他的客户，卖的越多越好。但是，其他客户我们有关系的并不多，所以要想销售给其他客户，必须拿产品说话。于是，研发部陆续加入了专职的测试人员、文案人员、美工人员，旨在提高产品的质量和包装，希望能卖个好价格。
所以说，专职的测试人员是这么来的。
很多软件公司没有测试人员，其原因就是老板搞定关系，程序员老实干活，项目质量虽然不行，但也能将就把钱结了。既然能赚钱，干嘛要测试人员呢。除非由于质量问题，签不到单子。除非由于质量问题，客户不验收不给尾款。除非公司所有人都测试还是无法达到客户满意的质量。只有这样，才会招聘专职的专业的测试人员。
测试人员一来了，开始工作。但怎么开展测试呢？文档在哪里？
文档只有很老的设计文档，现在软件和文档已经毫无关系。为什么？原因有二：
1都是程序员，谁来专门写文档。为了公司生存，我身兼数职，到处开会做项目经理或做售前，还管开发人员，还有实施人员给我打电话问软件中某个功能怎么回事，我也分身无术。 2都是根据实施人员、客户、销售人员、老板反映的需求和BUG修改。那些BUG和需求EXCEL表格倒是有，但没法作为测试案例编写的根据。
测试人员硬着头皮，开始学习软件。
帮助在哪里？没有？
对，没有，因为没有写帮助文件的人。只有打单的时候讲解的PPT。
测试员晕倒。
晕完继续学习软件，什么是正确的什么是不正确的，测试人员也不知道，当然也不知道BUG究竟是什么样。软件质量仍然没有改进。
老板问：这个测试人员是不是没啥能力？要不要裁掉？
我说：不是他能力不行，而是咱们过去为了生存欠了太多东西。我们这会是在补过去的课。现在的文案人员正在补帮助。有了帮助，就有了什么是正确的标准。但现在的问题是，文案人员也不了解软件，她写出来的也是自己猜测，所以我已经分出来一个开发人员做项目经理，他目前专门负责把帮助文档建立起来，但是他开发人员出身不擅长写文档，但他熟知软件，所以只有他们两个人搭配才能搞定。但这种磨合，需要时间。
就这样，一边测试人员瞎学习瞎测试，一边项目经理和文案人员不断讲解不断编写不断审核不断修改。
测试人员终于可以编写测试案例了。但他对软件也是初步了解。由于几年发展，软件加入了大量客户的需求，很多细节的东西在帮助中也没有看到，测试人员也不知道有这个功能。所以测试来测试去，其测试结果和实施人员的测试没多大区别，都还是在门外转。
老板又开始沉不住气了，旁敲侧击想裁掉测试人员，觉得他的存在没多大意义，还是实施人员测试好。但是由于专职测试员的招聘是我提出来的，也是我的直接手下，而且这个测试人员也老实，干活勤勤恳恳，老板实在找不出什么把柄把这位开掉。
我说：他来自著名的外包公司，专职做测试，我相信他是专业的。只不过咱们过去缺的太多，所以他想测试，也是巧妇难为无米之炊。咱们可以继续看看。
果不其然，测试人员有其独到的软件测试方法、软件理解方法。很快，测试人员对软件的理解不亚于那些多年的实施顾问，也不亚于程序员。找问题也越来越准确，越来越深入。
当然，其原因也在于这个团队的成长，有专职的项目经理开始书写现有功能需求修改的设计文档。过去的，没有的，就让它过去，就让它缺失吧，但未来，不要成为过去。现在也有专职的文案，不断在修改帮助，加深了许多。测试人员现在比文案人员理解功能更细，更深入，经常提醒文案人员应该把某句话写进帮助中，否则容易被用户忽略，是个不小心就会绊倒的坑。
为了使测试人员更快速的了解客户应用操作方法，更细节的了解特个性的功能，我让测试人员也兼任研发部的技术支持。有服务部的小姑娘无法解决的问题，转到你这里解决。否则，在过去，服务部小姑娘老把电话转给开发人员，本来就几条枪，被客户电话吵的无法安心开发。而且客户发现开发人员接听电话处理问题更有效，所以很多客户都是直接给开发人员打电话，服务部成了虚架子，而开发人员的开发进度被拖累，叫苦不迭。现在有了测试人员兼任技术支持，这下解放了开发人员。开发的质量和速度提高许多。
但测试人员并没有做技术支持的经验，过了段时间就来和我诉苦，说现在服务部小姑娘啥也不干，都直接把电话转到他这里来，所以他现在已经无法测试了，成了专职的服务支持人员。如果再这样下去，软件质量无法保证，以后的技术支持压力更重，开发部就会成为开发+服务部门。
我给测试人员出了三个方法： 1经常遇到的问题，就做成FAQ。下一次还有小姑娘问，直接让她看FAQ，拒不回答。 2交给他们方法和思路，不替他们亲自做。亲自看着她，让她服务支持客户。一次不会，再继续这样做第二次，必须让她自己亲自会了。 3每个星期六定期培训，疑问解答。并且考试。如有讲过后考试还不会者，扣钱。
另外，我也对服务部下了一个考核（当时我已经统管的服务部）：你接待了多少客户问题，解决时间多长，多少个问题转给开发部技术支持了，这些问题的难度级别多高。根据这些指标来衡量服务部小姑娘们的技术解决问题能力。能力差的就辞退。
这几招后，服务部的技术支持能力蹭蹭的提高了。真是没有鞭子不干活。测试人员兼任技术支持越做越轻松了。
我还把版本管理、打包发布交给了测试人员。起源在于有时候客户报告了某个BUG，程序员一看好改就直接改掉了，改完后就直接联系客户更新了，但是并没有更改软件版本号，也没有做新的打包。于是出现了同一个版本号软件功能表现却不同。而且，由于项目组多了，每个项目组组长都各有各的原因，有时候自己就打了一个包给了客户，随便定个版本号，起的都稀奇古怪，有的叫beta版，有的叫6.0.20050203。这种情形导致了测试人员做测试的时候，开发人员说改了，测试人员说没改。开发人员说已经没有问题了，测试人员说我这里还能重复出来。于是两个人一起查，耗费了两天时间，才查出来测试人员手里的和开发人员手里的不一致。
我又下了几招： 1开发人员绝对不能接触客户，不能接听客户电话，也不能解决客户问题，更不能给客户更新 2开发人员不能没有任务分配和设计文档就擅自修改软件，否则记过处分 3大家一致使用版本管理工具、BUG管理工具、需求管理工具、任务管理工具。用工具把项目经理、开发人员、测试人员、文案人员绑定在一起，按固化流程推进流转。 4打包发布统一交给测试人员来做，测试人员来控制是否可以发布，发布的版本号的命名。质量达不到，有权不能发布。
现在，我们的测试已经能做边界测试、版本兼容性测试、系统兼容性测试、压力测试、安全测试、集成测试、破坏性测试。也已经在项目中应用全程测试，测试人员主要参与需求验证、设计验证、代码验证、文档验证、打包验证。
但是，我们现在还没有实现单元测试，开发人员就这些人，项目却多。而且测试人员没有编程能力。我们也没有做更多的回归测试，毕竟测试人员数量配备太少，而项目并行太多。
看机会吧。老板越从软件上赚钱，他才会越舍得投入软件。成本永远嫌多，利润永远嫌少。
如果你是一名开发主管，你的老板还没有从你负责的软件中赚钱，而且是很快乐的很大规模的赚钱，而不是他靠他的人际关系和送礼吃饭支撑着，我想，他不会给你一毛钱的。你抱怨也没有用，因为你没有价值，所以投入也是没有意义。
先去证明你的价值吧。