也谈测试的进度控制和团队管理
在很多时候，产品（或项目）总不能如期地发布（或结项），发布期总在不断地推延，推延。大的产品有时会延迟一个月，几个月，甚至半年以上。这是个普遍现象，因为每个软件的测试过程都会受到诸多不定因素的影响。
近日，和业内同行聊起过如何控制产品的测试进度问题。我认为，延迟问题是无法避免的，但这种风险却可以尽量地降低。我不做测试已经8年了，但还是有一些深刻感悟。
一、制定切实可行的测试计划，制定和执行计划时，注意几个原则：
1、务实原则
即，没有把握的事情，不轻诺；已经答应的事情，不失信。
测试计划应依据功能设计书制定，明确测试范围和发布条件，合理地分配和调度测试资源。并考虑版本的复杂度，和功能的成熟度，以及预期发布时间，实事求是地划分测试阶段，且对各种突发情况进行风险预估。
2、前紧后松原则
对于接手的任务，要做到“前紧后松，赶早不赶晚”，尽力地按时、甚至提前完成。Bug的发现也尽量密集在集成测试阶段和系统测试初期。
3、重者为先的原则
各种事务“按类别”、“分优先级”处理。分清轻重缓急，重者为先。Bug的处理也以功能性错误、死机死锁、致命等优先级为高，边缘死角问题为低的原则。
4、提前进入原则
国内很多软件企业，由于受测试人手、测试人员的编码水平、以及公司对测试的认知程度等因素影响，很难做到由测试人员来做单元测试和白盒测试，更甭说从设计阶段开始了。但是，测试经理应该尽可能地参与到设计阶段，及早地了解需求动向，为测试前期做准备。测试团队则应提前进入到集成测试阶段，而不是从系统测试才开始。
因为，做过单元测试后，集成测试再由研发人员来做的话，则很容易产生懒散心理。集成测试阶段，测试人员的进入，则能和研发有效地互动起来，把许多明显的bug拦截在提交系统测试之前。早在1998年，我提出这一想法并亲身实践。结论是，测试进入得越早，对后期的进度把控越有效。
二、辅助自动化手段
自动化测试框架，虽然优点很多，但由于时间、人力、物力成本投入太大，以及企业对测试的重视程度、不同软件的不同特性等诸多因素，还有相当长的一段路要走。起码从目前来看，完全采用自动化还不太现实。
所以，可以把自动化测试作为一种辅助手段。对于有规律的、重复性强的、大数据量的，可批处理的，以及压力测试等，采取自动化测试。
三、处理好团队之间（研发和测试）的关系，做好团队的内部管理
1、走出误区
必须要走出测试的误区??即解除测试和研发的对立观念。
明确测试的目的、测试经理的职责、以及测试和研发两大团队的关系。测试的目的包括，验证产品符合需求的程度；发现存在的问题进行风险预警；衡量所测版本所处的状态。测试经理的职责包括，掌控产品（或项目）的测试过程；团队内外的协调沟通；测试资源（人员、工具）的安排调度等。
测试过程是两个团队的协作，而不是两大阵营的对垒。测试经理和开发经理，是两个团队之间沟通的桥梁和纽带，而不是障碍。所以，作为测试经理必须要先走出误区，并对成员加以引导。
2、强调沟通
很多单位都赋予测试方面很大的权力，集测试、品质保证一身，这也是研发和测试存在矛盾的诱因之一。在黑盒、手动测试中，测试人员的业绩与个人素质，以及情绪有很大关系；而在测试人员和开发人员交流时，研发人员的情绪也非常重要。
所以，要强调沟通。
动之以情，晓之以理，使研发和测试双方都消除对立的观念，要统一战线。各种不同意见，应尽力地通过沟通、讨论的方式去说服，而不是通过行政命令的手段去压服。
3、取长补短，经验共享，做同事的良师益友
想办法调动成员的积极性。如适当放权，在工作中兼顾员工的成长，以给成员以成感和满足感。
每个人的技术都并非全能，要善于利用资源，善于发现和运用各成员的优势能力，取长补短，协作互助地把事情做到好。如，调度各模块之间的负责人员进行交换、交叉、综合测试。鼓励成员经验共享，引导大家相互学习，并在他人思路基础上更深层次地发掘问题；促进测试与研发成员之间的交流等等，使彼此成为工作中的良师益友。
四、注重收尾阶段
收尾阶段的几个版本，我们通常称之为稳定期版本。此时，前期发现的重大bug已基本排除。产品进入稳定期后，测试方法和测试范围，应更注重客户思维，多站在用户的角度去验证产品符合需求的程度，去衡量版本所处的状态。测试工作需要更加缜密，容不得一点儿马虎和粗心大意。
进入稳定期的版本，应尽可能地减少改动，且版本间隔加长，以保证有足够时间进行全面测试。稳定期内发现的，不影响正常功能的问题，甚至边缘死角中存在的较重大问题，不要死咬不放，而应和开发经理、产品经理等相关人员进行讨论、评估风险。因为很多时候，牵一发而动全身，改掉一个旧bug却会引起好多新bug。除非修改有的把握，否则不应该冒险，可把发现的问题写在说明文档里，引导用户避开，留给下一版本解决。
产品的稳定期期间，测试经理起到至关重要的协调作用。
