软件测试经理10条成功进阶之路
这几天一直在一家公司做Team Building，一直想一个问题，是如何为一个中小型公司建立测试部门。如何在这样的公司做测试经理，也是在实际工作中如何从整体上把控一个测试项目，这个可能也是我们共同面临一个问题。
对于小公司，建立测试部门重要的是什么？重要当然是公司领导的支持，公司的CTO、项目经理、以及开发人员认识到测试的重要性，并给予支持。
一、下面我们进入我们讨论的话题，在小公司测试一个项目是从何开始的？
尽快的熟悉公司的业务流程，通过项目经理交流或培训了解公司的体系结构，然后要求公司项目经理派公司内专门懂业务的人（比如说技术支持，测试人员）与我们交流业务细节方面的知识。这是非常重要的，这是测试的开始部分。为什么这么说呢？我们以前不是说根据公司的需求文档，生成软件测试需求文档，然后根据需求文档再写测试计划，测试用例。现在软件公司特别是中小型软件公司的现状根本不允许我们这样做。可以说如果这样做，黄花菜都凉了。
进公司后，尽快的熟悉公司的业务流程，尽量每个细节都要了解。然后一边了解公司的业务流程，一边使用公司的软件。通过这种方式，我们在作什么呢？我们是了解公司的需求，现成的软件，现成的公司业务流程，是客户的需求。因为既然软件已经成型了，已经能够使用。（这是我对需求的理解：公司的现有产品是需求，但具体的实现可能有错误，而我们只需要找出这样的错误即可）如果我们再从需求规格书开始进行测试，那根本不太可能。有如下理由：
1、根据我对这家公司了解，软件的需求是通过产品经理得到客户的需求后，把需求告知给开发经理，开发经理在原来产品的基础上，添加新功能来满足客户新的需求的。这样的需求产生以及实现根本不是1天两天的一个事情，只凭测试人员几天的了解和分析能够通过需求进行测试了，这不是天方夜谭吗？
2、公司的基本上没有对需求进行文档化，没有比较详细的需求规格说明书。
3、公司好不容易已经有了自己的产品，而且这个产品的主要的功能都已经实现好了，这个时候你对项目经理说，你们某几个功能不符合需求的定义。这时项目经理非要晕菜不可。小公司都有一个特点是要求稳定性，因为公司本身的开发流程，不是很规范，如果你让他从需求上，也是从根本上改变软件的功能，这下牵一发而动全身。对于公司来说，他们肯定是不会做的。
从以上几个方面说明，在我们测试的时候，有一个这样不合理的理解：现成的软件产品是大体上满足需求的产品，或者说我们要根据开发人员的理解来理解需求。我们要测试的是找出：1）功能实现有错误的地方；2）界面或者使用习惯不符合我们使用软件的规范的地方；3）找出软件重要模块中潜在的错误。既然这么说，我们测试人员该怎么进入项目呢？
1、首先我们根据现有的软件产品，确定要测试模块。
2、与公司这边以前曾经作过简单测试或者懂业务的人交流确定下面几个方面：
（1）那些功能模块需要重点测试。
（2）需要什么样的测试策略即测试方法如功能测试，界面测试等等，可能公司还需要比如负载测试和稳定性测试方面的工作。
（3）以前开发的进度和测试的时间安排，关于开发进度可以与项目经理交流，根据整个开发进度来决定测试的进度。
（4）根据以上三个方面确定一个切实可行的测试计划。
（5）有了测试计划，下面我们开始测试了，关于编写测试用例好给懂业务的人评审一下。
二、我们能为公司带来什么呢？
1、规范的各类文档模版。
2、提供开发人员和测试人员交流的平台，如bugzilla，通过这个缺陷管理软件，实现公司管理和解决bug的规范化的流程。当然本身这个软件是需要给开发人员进行简单培训的，让开发人员会使用这个软件。
3、为公司建立了测试计划，测试用例，缺陷报告，测试报告等等文档库，这个其实也是公司极其缺乏的一个方面。
4、对软件测试正确的理解，公司的人对软件测试的基本的概念比如说白盒黑盒测试，基本文档如何编写比如说bug报告等等
通过对这个项目的测试，基本上公司建立了内部的文档库，建立公司内测试和开发人员交流的平台，到下次我们再要测试的时候，再告诉公司的项目经理，测试应该从需求开始，我们需要对需求进行测试。通过这样逐步渐进的方式实现公司整个测试流程的规范化。也是像我们书上所说的那样建立公司测试的V模型。
