初建测试团队应该注意的几个方面

目前测试在越来越多的企业里受到了很多的注视，这是好事。但是目前很多公司的测试面临问题：

• 新上的测试流程不规范
• 测试工具杂乱无章
• 测试用例和缺陷管理工具使用不规范或者根本没有
• 大部分测试还已通过性和验证性测试为主
• 没有测试计划，开发流程不规范，测试人员无所侍从

这些问题的出现直接导致一个问题，就是测试跟不上开发，甚至测试拖累开发导致发布进度放慢。因此很多新组建起来的测试团队都不能得到公司领导的认可，从而变成弃子。

 

如何才能在各种环境都没有的情况下建立好一个过硬的测试团队？这是每个Test leader在团队初期都需要考虑的问题。

针对上面说的情况，先把问题总结成几个方面：

• 团队文化
• 策略，计划
• 用例，缺陷管理
• 团队建设
• 交流
• 规范开发流程

 

团队文化

    无论测试和开发，都需要一个鲜明的团队文化。所以在测试团队初期就必须想好自己的团队应该是一个怎么样的团队。一个有好风气的团队可能带起来事半功倍。当然，很多时候团队的文化符号的代表就是leader，leader是什么样性格的人就可能带出什么样性格的团队。所以，在团队建设的初期，为了培养出一个好的团队文化，leader必须以身作则，树立表率。

 

策略，计划

    针对不同的产品制定测试策略和测试计划是leader一上来就必须要考虑到的问题。

    策略要针对不同的产品制定，主要制定出产品的测试重点和测试方法。测试策略可能一般人不太注意，可是如果一开始就没有制定好策略，可能在以后的测试过程中抓不到重点，看不清方向。这也是很多测试失败的最重要的原因。

    计划一定要尽量制定的细致，这点我和其他人的看法可能不同。一般认为测试计划在一开始不需要制定的很细致，大概的制定到月就行，反正随着项目的不同会有变化。 的确，可能测试计划在项目实施的过程中是很容易变化的，但是我们必须一开始就制定一个最少到周的计划，而且计划中必须明确每个人在每周的工作内容。只有这样，leader才能在制定计划的过程中发现一些很细小的问题。在制定好计划之后，必须同你团队的成员一起review你的计划，听听他们的想法。

 

用例，缺陷管理

    测试用例和bug管理流程是在测试执行中必须要认真保证的一部分内容。打个比喻，测试用例就像开发人员的开发文档，bug就象开发人员每天写的code一样。用例和缺陷在测试执行中要充分的重视，test case reivew, bug review要定期的做，而且是在整个团队内部一起。一开始的频率可能要高些，建议每天都留10分钟的时间，团队内部成员一起，谈下今天的测试过程，遇到的问题，目前的测试用例的覆盖情况。到了后期，频率可以放慢。如果有机会，可以做些找bug竞赛，这个方法不仅可以在短期内迅速提高一个feature的质量，也可以在过程中提高每个成员对产品模块的认知程度。

团队建设

    每个团队都少不了团队建设这个要点，作为leader你理应知道你团队的成员都做了什么事情，他擅长做什么方面，有什么方面需要提高。好的团队，要有技术点，工作点和协作点，所谓技术点，就是团队内部要有技术比较好的人能够在测试过程中对一般成员给予一定的指导，工作点就是团队内部需要能交给他放心做事情的人物，一个模块的测试任务交给他，他可以很好的规划自己的测试工作。所谓协作点，就是有良好的沟通能力和协作能力，能在技术公关的时候协住技术高手，能在测试模块固定之后协助模块owner找出潜在的bug。三个点的个性越鲜明，团队的执行力就会越强。当然在日常的工作中，需要按照不同人的特点，帮助他们成长成团队重要的一部分。

 

交流

    之所以拿出这个来单讲，就是因为在交流上吃的亏太大了。很多事情都是因为交流不畅，或者是交流不及时导致的耽误进度，或者是一段时间的工作浪费。所以，在保证测试计划执行过程的同时，必须要定时的和开发，市场等团队做交流。了解新的情况，提前做准备。

规范开发流程

    作为测试leader，很多问题可能是开发流程不规范导致的，如果是没有开发设计文档和需求文档，那我们必须提出来的同时去通过沟通或者其他方式去解决。tester不是神，而且在目前的团队配置上，我们的技术能力是最弱的，所以，我们必须要去要求其他的团队协作，重视我们的测试过程。

    其实一个项目的立项初期，测试能介入的时间越早越能够保证产品的顺利发布。开发人员可能会从开发的角度考虑问题，一些架构的设计不会去考虑测试的方便。但是我们必须在他们架构代码的时候就要求他们提供一些方便测试的接口，或者设计结构，以便以后布置自动化测试，或者是降低测试模块的偶合度。考虑提高测试的质量和效率。