如何管理测试项目(二)

前言

本文属于项目管理系列,之前已经写过一篇,今后也还会继续探讨这个话题。

前言与本文主题没有直接关系,算是笔者的啰嗦之言,不喜可以跳过。

也许跟自己的职业生涯有关(初做开发、后转技术支持,再后来直接做了测试管理),在走上管理岗,开始搭建测试流程的时候,着实困扰过一段时间。因为此前没有在测试团队工作过,所以不清楚究竟应该搭建什么样的规范,更不清楚什么样的规范才能快速顺畅的在公司内部推行。

很快,接触到了CMMI,也因此了解到了其他公司的一些流程规范,坦白说,在看到CMMI里的一些范例后,当时确有一种“如获至宝”的感觉,因为终于有了可以参考的、正规的案例。于是在此后一段时间,也开始推行收获的这些“宝贝”。结果想必你们也猜到了,很不顺畅。

在推行受阻后,开始反思那段时间的所做所为,时间长了,也确有收获。

正所谓逆着难从,顺着易行。难从则逆,易行泽顺。员工都是喜欢做容易的事,我一进去就把人家的工作搞得很复杂,不失败才怪。

我听过一种论调,就是做领导一定要坚定,即使错了也要坚定。坦白说我做不到“执迷不悟”,至少现在做不到。

另外,我也发现了规范里一些经不起推敲的地方。比如今天讨论的话题。

“测试停止标准 ”,也有公司叫“测试出口标准 ”,想必很多人都为此纠结过,本文就这个话题说说当年踏足的那些坑,希望对大家有所帮助。

正文

下面是我看到过的一个“测试停止标准”:

  • 测试用例执行率100%;
  • 功能性测试用例执行通过率100%;
  • 非功能性测试用例执行通过率90%以上;
  • 已实现/计划实现用例=100%;
  • 测试遗留的bug数量:
  • 严重的缺陷:0个;
  • 一般缺陷:0个;
  • 次要错误:0个
  • 修补改进:小于5个。

大家看到这个,是否会有什么感觉呢?

对我来说,我觉得这里面反映了一个测试用例的使用问题。这里的通过率是需要一些前提条件的,否则统计测试用例的通过率说明不了任何问题:90%的通过率到底是好还是不好?如果不掌握测试内容的详细信息,就没法回答这个问题。统计所实现的测试用例与计划实现的测试用例比例也说明不了任何问题:也许最困难的测试用例被推到最后,最后10%的用例需要50%的时间完成。也许所计划的测试用例数还根本不足以覆盖重要的风险。我认为,如果我们使用不合适的、解释不通的测试用例指标,向客户说明测试范围和完整性,不管是否是故意的,都是欺骗行为。

那么我们是否不应该统计这些数据呢?

我觉得,知道的少但是正视这种现实,总归要比知道的少但假装知道的很多好。况且我们可以讨论这些数字的含义。例如讨论测试用例通过率为何没有达到预期。也许没有足够的人执行所有的测试,或编写错误报告,或检验已发现的问题是否全部解决。可以利用这些数字说明自己的考虑。

一般来说,需要使测试过程具有可视性。指标可以做到这一点。但是不要指望项目经理和开发能够理解全部指标——不管我们认为指标多么“合理明了”、多么能够“自我解释”。相比指标,测试经理还是需要多关注用例的内容(即风险和覆盖率)。

什么才是测试结束的标准呢?

我们都知道,测试的价值在于它提供的信息。估计测试的价值是很困难的,而且我们都知道“我们不可能发现所有的问题”。一般来说,当我们有理由相信系统存在严重bug的可能性很低时,就可以停止测试。

怎么判断测试的足够好了呢?

判断测试是否足够好有很多因素:

  1. 知道要发现的重要问题的种类,知道程序的不同模块如何表现出严重问题,且做了与这些风险相对应的测试
  2. 测试策略具备多样性
  3. 清晰的定义或汇报了测试策略、测试结果和质量评估
  4. 使用了所有可用的资源进行测试
  5. 满足客户期望满足的所有测试过程标准

如果上面这些都做了,上线后仍然存在问题,那么原因可能有:

  1. 测试人员没有自己想象的那样了解风险
  2. 测试人员在测试中出现错误
  3. 测试人员的风险评估是正确的,但是管理层决定冒风险

总结

到底什么样的测试结束标准才是科学的?我我只能给出一般性的原则,具体的结束标准还是要根据项目情况、客户意愿等多方面因素具体考虑,而且测试能否结束,往往会随着测试经理对项目理解的加深而改变。另外在测试过程中遗漏问题不算问题,粗心、不认真思索或不通过实践吸取教训才是问题。

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

原文发表时间:2017-05-03

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏花叔的专栏

推荐个比较有诚意的小程序

小程序在9号的凌晨如期发布,掀起了一大波朋友圈分享狂潮,花叔马上去体验首发的一波小程序,这里就不写推荐列表了,只推荐一款比较有诚意的一款吧。 在“发现”->“小...

3809
来自专栏web前端教室

【提高】如何通过做例子来提高自己的前端水平?

在前一篇文章《【思路】已经入门前端了,想再提升前端水平,但没有思路怎么办呢?》中,写了在已经有一些前端基础,算是已经入门的情况下,提高前端水平的思路和方向。今天...

4629
来自专栏java一日一条

每个优秀程序员必须具备的技术技能

我特别支持软件开发者在他们掌握技术技能的同时去学习“软技能”——事实上,我写了一本关于这方面的书——但是不可否认的是:技术技能很重要。

881
来自专栏精讲JAVA

理解程序员并不是一项简单的任务, 即使你当过程序员

最近在读一本软件团队管理方面的书 :books: ,是两位在软件行业的资深从业者写的,其中有一个章节在讲如何理解程序员这件事。 理解程序员并不是一件简单的任务...

3505
来自专栏Golang语言社区

每个优秀程序员必须具备的技术技能

我特别支持软件开发者在他们掌握技术技能的同时去学习“软技能”——事实上,我写了一本关于这方面的书——但是不可否认的是:技术技能很重要。 我的意思是,如果你不能编...

3436
来自专栏架构师之路

通过“缓存”传递数据,是否可行?

如《互联网分层架构的本质》所述,互联网分层架构的本质,是数据的移动。 数据的移动,需要载体,DB和cache是常见的数据存储载体。 ? 如上图: service...

3587
来自专栏纯洁的微笑

如何成为一位「不那么差」的程序员

也不知道啥时候我居然成人生导师了。当然我不排斥这些问题,和大家交流都是学习的过程。

1253
来自专栏Python绿色通道

Python圈子需要净化一下

最近Python行业大环境出了很多大事,反正是不利于Python生态发展的事情,具体事宜我就不说了,我无意于因为这些事情打一些口水仗,我先做好自己就行.从现在做...

873
来自专栏程序你好

新手程序员如何写出好的代码

我之前的博客文章在推特上火了。这篇文章指出了一个问题——始终遵守某些规则实际上并不能帮助人们更好地编写代码。

1025
来自专栏腾讯社交用户体验设计

面对大型项目,设计师该做些什么

1403

扫码关注云+社区

领取腾讯云代金券