我张张嘴，还没说话，老高打断了我：“没有是吧，那物质奖励，前面说测试资料准备的时候不是也提了准备零食吗，这时候得上啊。”
　　我皱皱眉：“老高，那个什么交叉结对测试是什么意思？我只听说过交叉测试。”
　　老高眯了眯眼睛，交叉结对测试，是指安卓和iOS两端的负责同一个模块的开发人员，组成队伍，相互测试对方的客户端。有点拗口，但很有用处：
　　1、由于是负责自己开发的模块，所以不需要学习，能够很快投入状态；
　　2、测试对方的模块，能够在测试的同时检查自己的错误，测试的时候能够心中有数；
　　3、既是合作也是竞争，同时由于测试必须同时进行，一个人不来，另一个人也没办法开展工作，所以时间被拖延，这样也是培养他们的责任心。
　　这样，使用交叉结对测试的方法，其实也很好地缓解了第二、三、五个问题。
　　我抢过测三通手上的酒，给老高满上：“高哥，这个我算明白了，你给我讲讲其他的吧。”
　　老高满意地点点头：“集中测试效率低下，很容易被打断。其实这个也很好理解，集中测试是发现一些重要、明显的BUG的嘛，不要指望它能够带来多大的效果，但是由于单独测试不可控，所以集中测试是很有必要的，你把集中测试当成一个测试的热身，调动热血与气氛的工具好了，可以适当地缩短集中测试的时间。”
　　我把手机调成的录音机，放在老高面前，生怕漏了一句。
　　老高顿了顿，说：“你说了许多集中测试的事，却不说单独对照测试，肯定不是因为单独测试很顺利，而是因为没人单独测试是不是。”
　　”是啊，除了我跟个别的开发，其他人都不照着测试用例测。”我如遇知己。
　　老高叹了口气：“这也难怪，我以前也遇到这种问题，原因无非以下几点：
　　1、BUG改不完，没有时间单独测试；
　　2、利用测试用例做单独测试的习惯未养成，同时也缺乏良好的监督；
　　3、认为自己的本职不是测试，所以对测试有排斥；
　　怎么破呢？我的建议是：
　　1、规范测试用例，以及单独测试的任务，甚至可以作为绩效指标；
　　2、招聘专业测试。”
　　我已经打开自己的笔记本在做笔记了:“
　　1、使用交叉结对测试；
　　2、在中午午休之前做集中测试，并减少集中测试时间；
　　3、做测试激励，规范单独测试的任务；
　　4、招聘专业测试。”
　　老高：“嗯，你这小产品，做整理的本事还是不赖的嘛。行，那我倾囊而出，下面讲讲测试流程的第三环--FIX任务流程。”
　　见我有些疑惑，老高点了根烟，狠狠抽了一口：“测试出问题，得归类、整理、分配嘛。我现在随便给它起个名字，叫FIX任务流程。自创的名字，不用回忆了。”原来如此，我对老高更崇拜了。我想我要是个女生，现在的样子肯定很花痴。
　　老高见我默认了他的命名，很高兴地继续讲了下去：“我按照任务的生命周期，把整个流程分成了四步：任务创建、任务处理、任务审核、任务归档。现在都是在线办公了，咱们也不能总用SVN这种传统工具不是，多不方便，如果公司没有开发自己的任务系统，那也可以用现成的。”
　　我急说：“是，我们公司用的是在线办公，还不错。”
　　老高得意地吐个烟圈：“看来我还没过时。那你觉得怎么好用了，有哪些不好用的地方吗。”
　　我说：“还不错，不过确实也有不对劲的地方。
　　1、任务创建的时候，有的开发把自己发现的BUG提交上去，但他们描述的任务的风格不一样，有的描述问题，有的描述正确的做法，让那些修BUG的人看不懂；有的开发把BUG给负责人，让他们去提交BUG，结果修BUG的人不知道这个BUG是谁提交的，到处找，遇到一个人描述一遍，费劲；
　　2、改BUG的时候，有时候需要跨部门合作，可能需要产品、设计、服务端、前端等部门的同事参与，周期太长，他们也不见得有时间帮忙，总是拖拖拖
　　3、有的问题，其实不是BUG，是产品设计上的问题，这时候要找负责该模块的产品确定，但是常常是一个客户端改了，另一个根本不知道，好麻烦；
　　4、任务太多的时候，需要归档，可是一个个归档特别耗时间，然后是归档任务之后不知道这个任务是怎么发现，怎么处理得了。”
　　老高笑道，这些简单，我教你几招：
　　第一招，集中测试时，每个人一张纸，将BUG写在纸上，然后署名，由负责人去记录，同时任务创建的同事需要关注BUG的发现人；单独测试时，创建的任务默认关注自己。这样有几个好处：
　　1、集中测试时，BUG多、乱，这时候做记录很麻烦，不如用笔记；
　　2、由负责人做记录，文风统一了，理解起来不困难；
　　3、关注了BUG的发现人，遇到不理解的，或者不能重现的，可以快速准确地找到发现人；
　　4、为BUG的修复检查做准备，须BUG的发现人去检查BUG是否被修复，之后才能做归档处理。
　　其实，还有个好处。”老高露出一丝与刚才骗酒喝一样的诡异笑容：“出了问题，可以追究责任。但真实目的是让大家更有责任意识。”我觉得老高真是个妙人，随便支了一招居然解决了五个问题。
　　老高接着说：“第二招，记录与通知。”
　　说完静静地看着我，我当然知道什么意思，赶紧顺着他的意思，装成傻子：“什么意思。”
　　老高看看杯中的酒，缓缓地晃晃杯子：“记录是时刻记录这些产品设计上的改动，不一定需要PRD，但一定要记着；通知是做了修改后通知两端的负责人，记住啦，别把别人当傻子，叙述好了，别过去傻愣愣地问别人改了没。”
　　我拼命点头。
　　老高：“这两招吧。跨部门的事情，其实你需要做的是：
　　1、处好关系；
　　2、把问题整理好，别找到了别人还说不出个所以然来；
　　3、把测试的重要性强调强调再强调。至于任务归档这件事，我建议你不要随便归档，好是等到新版本上线并稳定后，再归档。”
　　老高喘了口气：“后是文档了，测试日报、周报，目的是评估开发质量、对问题进行分析。你们既然用了在线工具，那么这个日报也不是问题。”

　　我没想到今夜居然有如此大的收获，三谢老高，准备离开。
　　测三通不知道什么时候已经冷冷地站在我背后，看我要离开，冷冷地来了一句：“你没有把话讲完。”
　　我跟老高都看着他。
　　他好不容易有点存在感了，又在哪里卖关子：“我看不惯你们这些做产品的，有什么话讲.......“
　　我跟老高同时冷冷地道：“有话说，没事滚。”
　　测三通彻底蔫了：“你们都避着人的事情不说，我当初是处不好人情才出来做酒保的。”
　　我心一惊，没想到这衰货居然还有这种思考深度。
　　老高也把脸对着我，他的墨镜后面深邃的眼睛也一定盯着我看。
　　我喝了口酒：“好吧，人的确是很大的问题。除了前面的责任感与专业程度外，还有几个麻烦：
　　1、不可控的外界原因，比如紧急事件处理、测试场所被占、测试机不足等都会影响测试，甚至让测试停止；
　　2、人员的不可控，紧急任务的人员抽调，请假、离职都会导致人员不足；
　　3、非测试人员的参与，由于不了解测试的进展，胡乱创建任务、归档任务，导致了大量的重复任务，甚至有些人还直接来询问产品和开发，一个个都要讲清楚才行。增加了开发的负担，归档任务的更麻烦了，直接找不回来了。”
　　“还有在测试的时候集中提需求的。”测三通补充道。我看着老高，老高沉默良久，说：“这件事情，是解决不了了，只能缓解：
　　1、尽量做足准备，比如预约多个会议室，向公司多申请些测试机，或者让同事们借出等，做好备用方案；
　　2、强调，提升测试的重要性，不能因为周期长而认为测试不紧急；
　　3、尽可能地调整人员调派的时间，不予固定的测试时间冲突；
　　4、提高人员出借的难度，如果有人要借人，那么需要找负责人说明原因
　　5、尽量控制非测试人员的权限，不允许直接向测试项目组添加、修改、归档任务；
　　6、非测试人员创建的人员，需要测试审核通过后，才能由测试负责人创建任务；
　　7、BUG修复审核完成后，应该先归类到特别的任务组中，等到产品上线并稳定后才可以归档；
　　8、由项目负责人整理测试日报、周报发送给非测试人员，打消他们对测试进度的疑惑。”
　　我设置的零点闹钟响起，我必须回家了，明天还有许多工作去做。我再谢了老高，也辞别了测三通，离开酒吧。
　　出了酒吧，寒风袭来，我被酒染红的燥热的耳朵，感受到今年入冬以来刺骨的寒意，但我还很兴奋，我的手机收到一条短信，原来是老高送我的十六字箴言：写好用例，处好关系，做好沟通，招个测试。
　　我回头看看这家不起眼的酒吧，霓虹灯上的有些灯泡已经熄灭，但我还是能够辨认：测马奔腾。
　　再会，离场不散场。我心说，然后扭过头，疾步离开。