如何管理测试项目?(一)

前言

面试过几个应聘测试主管的应聘者,问到一个问题“你会如何接手一个新测试项目,你首先会做什么事,问哪些问题?”得到的答案几乎千篇一律:了解需求,做计划,然后设计用例,执行用例,最后提交报告……这样的答案,不能说错,但却不是我想听的。我想听到一些不一样的东西,准确的说是应聘者自己总结和思考过的东西,而不是网上流行的固定的那一套流程。

今天分享的主题是如何管理一个测试项目,跟上面的话题没有直接关系,不过也有借鉴价值。

管理一个测试项目大致可以分为事前、事中、事后三个阶段,从接到测试通知到完成测试计划为事前,从完成测试计划到完成测试报告为事中,完成测试报告往后是事后。今天主讲事前和事中,内容主要是各阶段工作的重点,需要做的准备(需了解的信息),常见的问题等。

事前

接手一个新测试项目以后,我首先会用一段时间来了解团队(这点很重要),学习产品架构,了解团队最新动态。我认为如果没有获取到足够的信息,做出的测试计划是没有信服力的。所以接手一个新的测试项目,首先要做的是先倾听而不是发表意见。

开发模型对测试工作的影响

现在比较流行的开发模式有瀑布模型和敏捷开发(迭代、进化、极限编程等),做测试计划的时候,开发模式在考虑因素中位于T1序列。

关于不同模式的优劣,争论一直没有停止过,本文不做讨论。模型的选择是立足于公司/团队所面临的问题,而且两者也并非不能交叉。这里需要提醒的是,如果选择了瀑布模型开发,《测试计划》中也不建议对时间进行精细的划分,“需求不会变更”只是一种美好的期望。每次需求变更,计划都需要进行随之改变——这个投入是没必要的——建议将时间投入在了解团队和项目信息中、规划测试策略上。

同理,在代码交付之前编写详细的测试用例也是有风险的。从实际工作来看,我们前期写得很多用例,到后来对应的功能甚至没有开发,或者开发出来的跟设计不一样,这也意味着我们前期花费了大量的时间和精力做了一堆无用功,而且用例写得越详细,测试数据准备的越“充分”,情况就越糟。但用例不能不写,因为抛开用例对我们测试人员的重要性不谈,开发有时候也需要根据我们的用例做自测,所以怎么写、写到什么程度合适呢?我的建议是可以写测试要点(试试mindmanager和visio),以后会详谈。

需要开发提供的文档

很多测试新手都有过这样的困扰:开发连一个完整详细的需求/规格书都没有,要不要给他们测试?

很多时候要不要投入测试不是我们能决定的,领导让你测,你敢说他们文档不提供你就不测?

我想说的是,并非所有公司、团队或者项目都需要提供文档,如果是互联网公司、或者选择敏捷开发,文档是弱化的。其次,如果因为没有一个详细文档,我们就不能高质量的测试,那岂不是说明我们能力也有问题嘛?除了文档,我们可以通过其他信息来保证我们的测试质量。

另外,除非我们确实需要,否则不要让开发提供文档。

在项目初期的投入

测试越早介入项目越有利于保证产品质量,这个观点目前基本已成为共识。不过在执行层面上还会有问题。比如如果只是想让测试员参加早期的项目团队会议,那也许是浪费测试员的时间。在比如如果测试员不懂代码,派他去参加技术/代码评审常常是浪费时间,而且如果问出一些“小白问题”,自己尴尬不说,还可能导致被开发瞧不起。

那我们应该参加哪些会议呢?或者我们参加会议的时候应该关注些什么呢?

我觉得值得参加的活动举有:

  • 评审文档的可测试性、可理解性和模糊性
  • 考虑测试策略,是否需要学习必要的工具,是否需要进行质量度量
  • 对团队进行培训,Bug预防
  • 推动代码评审(自身需要接受培训)
  • 拟定测试环境的配置清单
  • 了解产品的客户、市场和竞争情况

沟通版本发布计划。避免过于频繁的版本发布,否则会在测试管理上面花费过多的时间,而且每个版本无法“充分”测试,难以保证质量。

关于《测试计划》

做多少轮测试才算充分?

我们都希望有某种方式保证已经完成了足够的测试,网上也能查到很多公式。但实际上我觉得这些公式都有很明显的严重的问题。也有一种说法“两(三)轮测试性价比最高”,这种方法理想的认为第一轮会发现所有bug,第二轮回归所有bug……但实际情况我们大都知道,这不可行,因为我们对产品的了解是随着测试逐步深入的,越往后测可能会想到更多更好的测试方式,也会发现以前没有考虑到的地方。除此之外,需求变更、BUG阻塞、引入新BUG等都会让测试轮数不止两三轮。

当初制定的计划测试时间总是无法按期进行,写测试计划还有意义吗?

《测试计划》中时间是其中一环,但不是最重要的一环。测试计划的编写有5W1H的指导原则,关于这方面网上很多资料。我现在的团队,项目进度控制的也不好,我的做法是在代码交付以后做“阶段计划”:制定一个阶段测试的目标,比如要使用什么工具、战术,要寻找什么类型的BUG,有什么风险,要研究什么资料,需要什么结果等。有了阶段目标之后,再制定阶段测试时间,可能是一小时,也可能是几天。在有条件时会安排几个人共同完成这个阶段任务,从效果来看,这种做法更有实际意义。

测试任务时间估算,请参考我的另一篇文章:测试管理分享-《如何为一组任务确定计划,估计每个任务所需的时间?》

未完待续。

原文发布于微信公众号 - 软件测试经验与教训(udatest)

原文发表时间:2016-12-20

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏理论坞

您有一份礼物, 请查收

一个关于理论的库, [坞]是小港湾, 储存的意思; 英文叫 Theorywood , 简称 TW ( 理解成台湾可以嘛? ) 理论坞——打造你自己的理论库

1334
来自专栏Java架构

高并发风控技术解密(上)

2503
来自专栏TEG云端专业号的专栏

何维兵:大型DCI网络智能运营实践

做运营的同学,都有同样的感受,既希望被老板关注,又不希望被老板关注!因为觉得被老板关注时,常常是没什么好事发生。记得微信红包兴起时,有一次我们网络运营就有幸得到...

3953
来自专栏SDNLAB

现代数据中心标准COTS服务器的演进

数据中心内的x86商用成品(COTS)服务器的标准化已经经过了很长时间,因为该架构提供了多功能、低成本、易于集成、更有效地维护和管理配置文件,总而言之,其成本低...

3414
来自专栏编程坑太多

『高级篇』docker容器来说微服务优势和不足(四)

1843
来自专栏灯塔大数据

【连载•第一话】网络大数据技术与应用(下)

摘 要 简要介绍了网络大数据的概念,分析了运营商网络大数据的构成及带来的挑战,并从网络大数据存储与技术平台、感知与获取、清洗与提炼三个方面对运营商网络大...

3257
来自专栏IT大咖说

新浪微博平台自动化运维演进之路

摘要 新浪微博是一个由新浪网推出,提供微型博客服务类的社交网站。用户可以通过网页、WAP页面、手机客户端、手机短信、彩信发布消息或上传图片,是当下中国最火热的社...

4204
来自专栏互联网数据官iCDO

【精华知识】初学者的高级谷歌分析指南-Episode 4

主编前言: 这篇文章我们请朱玉雪帮我们翻译自Avinash Kaushik先生的文章。了解Avinash Kaushik先生的朋友不对他的行文风格不会陌生——内...

3356
来自专栏DevOps时代的专栏

DevOps 三步工作法之持续反馈的技术与案例

导言 很高兴参与DevOps时代社区的拆书联盟第一季活动,有幸能与几位DevOps大牛一起解读《DevOps Handbook》一书,这本书作者牛,内容也很牛,...

2747
来自专栏软件成本造价评估

如何度量一个软件的非功能需求?

  非功能需求,指软件产品为满足业务需求而必须具有的,且除功能需求以外的特性。非功能用户需求是描述软件如何实现功能而不是具备什么功能。非功能特性包括产品必须具...

1250

扫码关注云+社区

领取腾讯云代金券