质量不只是发生

如果开发人员和管理人员都希望创建用户喜欢的软件,那么为什么会有这么多劣质的软件项目逃离质量保证部门?

1 2 3 4 5 6 7 Page 3
第3页,共7页

第9课:为了最大化团队效率,项目计划必须考虑测试效率。这可以确定特征实施顺序。

该软件有故障。测试团队围绕尚未实现或无法正常工作的领域进行测试,但是发现了许多阻碍进一步测试的问题。

更糟糕的是,当测试团队从开发中获得错误修复时,有30%的时间无法解决问题。在这种状态的代码搅动,该项目超过了截止日期。总理被迫下船(他也想去塔希提岛旅行!)。告知开发人员和测试人员更多的努力,共同努力实现目标,尽一切努力...

第10课:Buggy软件需要更长的时间才能发布。

产品出厂时状态未知。添加了最新功能,并且仅接受了粗略的测试。尽管已解决了所有已知的关键问题或将其归类为“严重”,但仍有大量已识别的错误仍在打开。维护版本已在计划中。团队筋疲力尽。再次,它花费了英勇的时间,并且再次产生了几乎无法支持的产品。顾客再次感到不高兴。该产品具有客户不想要或不了解的功能,并且缺少他们期望的几个主要项目。荣誉奖杯从上方降下来,以进行另一次“准时”交付。

What went wrong?

  • 管理层不承认“准时”不等于“满意的客户”。
  • 整个项目团队都由进度驱动。每个决定都显示进度表,而不是质量意识。
  • 为缩短进度时间而采取的捷径(包括未完成的需求,不足的系统设计,没有单元测试)实际上使项目花费了更长的时间才能完成。
  • 实际上,维护版本仍然是主要版本,但现在也涉及不满意的客户。
  • 人们精疲力尽,精疲力尽,无法有效利用。奖励系统搞砸了!

该项目交付六个月后(随后又发布了八个维护版本),进行了分析以确定所有错误的来源。分析显示:

  • 要求中引入了50%的错误。这些是由于不清楚和含糊的要求以及未定义的功能,因此必须在维护版本中引入。这还包括数据问题和设备问题,其中测试团队没有合适的数据或设备来反映客户的环境。此外,与不需要的功能相关的所有错误均在此处计算,因为如果未实现这些功能,这些错误就不会发生。
  • 15%的错误是由于设计问题引起的,尤其是代码模块和数据库之间的接口。
  • 在新代码和修复程序中引入的回归方面,有25%的问题是编码错误。
  • 这些问题中有10%是仅在完全集成的环境中才可见的系统集成问题。
1 2 3 4 5 6 7 Page 3
第3页,共7页