为了账号安全,请及时绑定邮箱和手机立即绑定

如何管理测试项目?

前言

    面试过几个应聘测试主管的应聘者,问到一个问题“你会如何接手一个新测试项目,你首先会做什么事,问哪些问题?

    得到的答案几乎千篇一律:了解需求,做计划,然后设计用例,执行用例,最后提交报告……这样的答案,不能说错,但却不是我想听的。我希望听到一些不一样的东西,准确的说是应聘者自己总结和思考过的东西。

    今天分享的主题是如何管理一个测试项目,对回答这个问题有借鉴意义。

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


事前

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

    有的员工很喜欢说“在我们以前的单位是怎么怎么做的....”,这是很忌讳的。会让听众觉得,你还没有融入到现在的团队,做事不考虑实情。


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

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

    关于不同模式的优劣,争论一直没有停止过,本文不做讨论。模型的选择是立足于公司/团队所面临的问题,而且两者也并非不能交叉。这里需要提醒的是,如果选择了瀑布模型开发,《测试计划》中也不建议对时间进行精细的划分,“需求不会变更”只是一种美好的期望。每次需求变更,计划都需要进行随之改变——这个投入是没必要的——建议将时间投入在了解团队和项目信息中、规划测试策略上。
    同理,在代码交付之前编写详细的测试用例也是有风险的。从实际工作来看,我们前期写得很多用例,到后来对应的功能甚至没有开发,或者开发出来的跟设计不一样,这也意味着我们前期花费了大量的时间和精力做了一堆无用功,而且用例写得越详细,测试数据准备的越“充分”,情况就越糟。但用例不能不写,因为抛开用例对我们测试人员的重要性不谈,开发有时候也需要根据我们的用例做自测,所以怎么写、写到什么程度合适呢?我的建议是可以写测试要点(试试mindmanager和visio),以后会详谈。


需要开发提供哪些文档?

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

    很多时候要不要投入测试不是我们能决定的,安排了测试任务,我们若因为一点困难就推掉,这是说不过去的,不是吗?

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


在项目初期的投入

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

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

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

    • 评审文档的可测试性、可理解性和模糊性

    • 考虑测试策略,是否需要学习必要的工具,是否需要进行质量度量

    • 对团队进行培训,Bug预防

    • 推动代码评审(自身需要接受培训)

    • 拟定测试环境的配置清单

    • 了解产品的客户、市场和竞争情况

    沟通版本发布计划

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


    关于《测试计划》

        做多少轮测试才算充分?

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

        计划测试时间总是变,写测试计划还有意义吗?

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

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


    点击查看更多内容
    TA 点赞

    若觉得本文不错,就分享一下吧!

    评论

    作者其他优质文章

    正在加载中
    软件测试工程师
    手记
    粉丝
    1.4万
    获赞与收藏
    1041

    关注作者,订阅最新文章

    阅读免费教程

    • 推荐
    • 评论
    • 收藏
    • 共同学习,写下你的评论
    感谢您的支持,我会继续努力的~
    扫码打赏,你说多少就多少
    赞赏金额会直接到老师账户
    支付方式
    打开微信扫一扫,即可进行扫码打赏哦
    今天注册有机会得

    100积分直接送

    付费专栏免费学

    大额优惠券免费领

    立即参与 放弃机会
    意见反馈 帮助中心 APP下载
    官方微信

    举报

    0/150
    提交
    取消