测试管理工作之问题分析和解决方法

    作为从项目经理转变为测试经理，我本身的优势就是我对这个产品很了解，我对客户很了解。我对流程也很了解。那么测试的症结在哪里？ 分析原因有以下几点：

1.测试内容和测试时间不确定性，导致测试被动。

2.开发人员本身测试能力不够或者测试态度不对，造成测试版本过多。

3.测试人员本身测试专业水准不够，导致测试质量不高。

4.测试管理**和组织不够专业，导致测试流程不明确，怎奈测试慌乱一个字了得。

   基于以上几点，我决定先从客观原因入手。 也就是第一个和第四个，这两个原因完全可以规范化。虽然不能保证每次计划不会改变或者随着客户流程的改变，也会对测试管理起到相应的影响，但是至少保证相对规范。不至于让测试陷于被动。

   针对测试内容和测试时间不确定性的问题，我们做了以下事情：

step1.我特意自行发起了项目组内部先对去年遗留问题进行了整理，并发给了开发人员和甲方项目管理人员这两个干系人。

step2.甲方项目经理补充了今年已完成任务，并发起了会议，把系统出现的问题提出来看其他系统（相同框架）是否有类似问题。从而完成了一个未升级任务的列表。 

step3.我建议开发经理让开发人员写出未升级任务列表中已经完成，但是未升级的内容。

step4.组织开会，确定下个月设置下下个月升级的内容。以便于测试人员开始编写测试案例。

   值得一提的是：有些内容可能还牵涉到甲方业务人员测试之后才能升级的。那意味着我方测试完后，可能还不升级。这就要求我方测试人员先打好基线。然后把测试内容放到测试环境进行测试，再交给甲方业务人员测试。可以确定升级的，不需要甲方人员测试，我们可以自行测试，并优先订好升级时间。

   针对测试管理**和组织的不专业，我特意制定了测试人员的工作内容一览表。以及他们测试过程需要交付的文档和代码等。另外还需要增加一个时间表，并在每次升级前做好测试计划安排。

   这些客观因素解决之后，就是后续长期的过程，测试人员和开发人员的测试水平可以通过长期的组织培训来实现。另外相应的考核起到监督和激励作用。

   事情当然不会像我想的那么一帆风顺，但是至少我在想办法，我今天比昨天进步了。