当老板问:软件质量怎么样,能上线发布吗?阁下该如何应对

说在前面

每当你和团队完成了一款软件产品的开发,是否很容易被问到这样一个问题:质量怎么样?或者是能上线发布吗?如果你是团队的负责人,你会如何回答这样的问题呢?对软件质量的评判标准,不见得所有人都是同样的看法。质量要求的标准可能各不相同。本文聊聊软件质量的事情。

当老板问:软件质量怎么样,能上线发布吗?阁下该如何应对_第1张图片

谈谈质量评估的依据

重温了下《软件测试》(美,Ron Patton著)的部分章节,那位佛系年长教授给我的印象至今依然十分深刻,他当时说:软件测试是一种非常有意思的事情。现在想来他老人家是通透明了了。针对软件中的问题,本文不在名字上过于计较,统称“缺陷”。算作读后感吧,加入自己的理解,我总结了一些要点。

高标准没有错,这是一种理想和信念

软件质量不能出任何问题,你要找出所有的缺陷,并修复所有的问题。上线后不允许出现任何重大问题。

上述要求有错吗?合理吗?当然没问题,必须有这种要求的,这是一个完美的目标,是所有团队梦想追求的结果,这个方向是没有错的。有些项目甚至是苛刻的要求,我国最近接连两次的卫星发射失败,就是惨痛的教训。

但终归要认清现实

你无法找出所有的缺陷。你可以说自己找到了一个缺陷,但你不能说缺陷不存在了。程序员买苹果的段子,测试计算器软件的例子,等等......直接说明了程序设计工作的复杂性,这也直接导致了针对软件产品做“完全测试”几乎变成了一种空想。你所运用的任何测试方法,都会存在不同程度的取舍,比如删除一些重复的、无必要的用例等。出现了取舍,就代表着引入了风险,那种无法发现所有缺陷的一个风险。

你无法无限期的测下去。每个项目都有一个最优的测试量。试图过度的投入,会导致项目成本大幅增加。大多数情况下,缺陷数量达到一定程度后,不会再发生显著变化。我们的目标应该是找准最优的测试量。如果你的项目真的不计时间,不计成本,那就可以一直测试。但任何产品的研发,都是有周期要求的。

任何人都没有发现的缺陷,算不算缺陷?

如果这个问题很难回答,那我们就思考下另外一个问题:一棵树倒在森林中,如果没有人听见也没有人看见,那它发出声音了吗?答案显而易见了。我们可以称呼这种无人发现、也没有现身的缺陷,叫潜在缺陷

真的不能开发出无缺陷的代码吗?

  • 程序员是一个个非常主观的人,他心情可能不好或能力不行,写了缺陷可能不自知。
  • 程序设计其实是主观题,答案不唯一,很难有满分。
  • 就算刚开始真的做的很棒,无可挑剔,但耐不住变化太多。唯一不变的就是变化,这句话已经不像是在开玩笑了。
  • 有些缺陷可能让你觉得无所谓,不值得。但他有时可能只是表面现象,真实的问题会让你如坐针毡。

缺陷没有清零,就是质量欠佳吗?可以上线吗?

并非所有的软件缺陷都要修复,比如这些:

  • 不算真正的缺陷;
  • 修复的风险太大的;
  • 不值得修复的;
  • 没有足够时间修复的,交付日期逼近;
  • 其他一些原因,被认同可以不改的;

这些都要根据各项目的管理制度和规范,寻求团队自己的商业风险决策。之所以称风险,想必也是只有时间才能验证这样的决策是对的,还是错的。这是普遍的一个现象,会让团队或者决策层甚至产生非常不适的体验,这时往往需要团队自上而下的一致团结。除了团结,测试相关的流程和数据,是要严格考察的。

很多团队都会有这样的要求,在交付或上线前,缺陷必须清零。但往往那也只是表面上的清零,往往那些遗留的真正问题,并没有得到解决,只是以另一种形式消失不见了。这不是一件值得高兴的事情。如果你的团队做到了真正的清零,那真的很优秀,很难得。但你也要对潜在缺陷有一定的心理准备和团队级别的应对处置方案。

最后还有一个陷阱,不得不提:

产品说明书或者叫产品文档,就是真正的需求吗?它一定都是正确的吗?

  • 文档里是否就是需求,你一定有渠道或办法去确认!
  • 需求是正确的吗?你一定有方法或思路去验证!

尝试用正确的需求,去做产品研发。坚持下去,你一定会受益匪浅。

尽可能降低出错的概率

虽然不可能发现所有缺陷,但我们仍然可以去不断探索各种技术

和方法,去尽可能的提前找出错误,甚至避免错误,降低生产环境出错的概率。

  • 创造好的环境和空间,让你的程序员越来越靠谱;
  • 养成问题复盘和分享的习惯,让团队持续成长;
  • 让每个人都明白:逻辑严谨的重要性和必要性;
  • 让每个人都明白:何时有必要发起评审;
  • 引入必要的工作流,提早发现问题;
  • 引入专业的测试团队,专职服务于产品研发;
  • 提前验收,尽早验收,多次验收;
  • 能想到的测试方法和范围,尽可能做(功能、性能、压力、疲劳、容错、安全等等);
  • 尽可能找有测试天分或责任心的测试工程师;
  • 越早结对代码评审越好;
  • 保障最低限度的同行代码评审;
  • 了解行业动态,同行交流,持续完善方法论,形成良性反馈闭环。

 正在做测试的朋友可以进来交流,群里给大家整理了大量学习资料和面试题项目简历等等....

你可能感兴趣的:(软件测试,压力测试,单元测试)