Lead测试项目

         进入软件测试行业快一年了，第一次完成Lead一个测试项目，四个人的小组。因为项目本身是将先前发布的产品做平台的迁移，大的功能点没有非常大的变动，只是出于性能等其它诸多方面因素的考虑，做了一些修改和优化，因而整个测试项目的任务其实算不上很重。期间感悟和感触颇多，在此项目接近尾声之时，作以总结，以利自身成长！

 

         “不在其位，不谋其职”，对于软件测试，今天看这句话，才真正深刻的体会到其中含义。在过去一年中参加的两三个项目中，一直不解测试项目Project Leader工作的内容，安排自身做的case也不多，为什么看到他们还是处于非常忙碌的状态中。现在仔细想想自己在过去的两周中的工作内容，才有了真正深刻的体会：

n   测试版本的控制：

l   开发每完成一个版本，负责从服务器抓取软件安装包并向测试小组内发布，一并提供与上一版本的修改区域，以用于Heavy Testing。

l   组员手上各自都有分配好的Case需要运行，时间比较紧的情况下，修改区域的先行测试由你进行，以求快速进行回归测试并发现易暴露的缺陷。

n   外部资源的协调：

l   当现有人力资源无法完成测试目标时，向经理提出需求。是加班？是加人？

l   当硬件设备环境当前条件无法满足时，是租借？向谁租借；是购买？报价，供货渠道，到货时间，影响到测试进度吗？有其他替代方案吗？

n   项目组与测试的桥梁：

l   开发经理，PM等向项目组或测试组内传达的信息（Email，聊天记录），你需要深刻理解并在组员有疑惑的时候能加以明确回复。

l   开发安排给测试的弹性任务，你是第一接口。

l   你是将测试组进度、状态、安排、疑惑、疑问向项目组传达的责任人。

n   测试策略的制定：

l   哪些区域要测试、哪些可以不测试、哪些需要重点测试。

l   制定待测模块测试用例的优先级。

l   不同区域之间不同测试方法，是随机测试加探索性测试，还是严格执行Case。

n   任务分配的制定：

l   这个功能模块谁最熟悉，最快需要花多少时间。

l   谁的缺陷敏感性强？安排其测试关键区域。

l   谁的逻辑思维性好，安排其测试业务场景。

l   谁有自身特殊情况，如请假、女同事的怀孕妊娠反应。由于其测试的非连贯性，安排其测试非关键性区域。

n   风险规避与进度的控制：

l   熟知关键区域的测试状态。

l   熟知临界区域的测试状态。

l   熟知高等级缺陷的修改状态。

l   熟知当前的进度。

l   软件真的可以发布了吗？

n   内部沟通协调：

l   回答组员的疑惑、疑问。

        

         项目快接近尾声，收益良多的同时也体会到些许遗憾和自身的不足：

n   对组员的疑惑、疑问有些没能做到正确而又完整的解答

l   对Spec理解的还不够透彻。

l   对业务流程了解得还不够透彻。

l   和开发沟通的还不够充分。

n   组内信息没有做到真正而又充分的共享

l   为什么有些问题出现多人次的重复向开发提问？

发现比较疑惑的问题时，组内同事间的相互沟通，询问一下别人有没有遇见此类的问题；看看缺陷报告；自身作为Project Leader对于问题的收集和汇总有时似乎也很有必要。

l   开发经理：为什么都是第二个发布版本了，还有人在问很基础的问题？

在项目阶段结束后，做好个人和团队的总结。组内分享，学习，交流。当然，这需要环境和习惯。当然，平时的记录是做好此总结的基础。

l   为什么以前提过的问题，现在又重复提出？

因为没有做好个人的信息备份，时间长了，对同一问题的解答忘记了，疑问再次成为疑问。这不仅使我想起了高中时同一道数学题问了同一个老师三次，亦属同一性质问题。用文档记下这些问题的答案吧，在项目开展的期间时常看看。项目的知识也是需要学习和记忆的，开发不是数学老师！

n   没能推动开展自动化测试

n   多做一个聆听者

少一点自己观点的表达，多一些仔细的聆听。当对方的观点与自己的相抵触时，多一些理性的思考。

n   加强口述表达的逻辑性与严密性

当阐述自身观点时，注意条理性，忌重复！至少要使自己很清楚自己在说什么！

        

         还记得去年年初转软件测试这一行当的时候，去一家外包公司面试的时候，面试官问我：现在有个软件需要测试，给你两个人，你该怎么安排他们的工作呢。当时的回答显得苍白而又无力，现在想来，或许有些明朗起来。