质量内建 | 敏捷的哲学

对于来自客户方的软件需求,我们直观的感受都会理解为,对一系列功能的期待。而软件构建,无非就是实现这一系列功能的过程而已。但事实是,总会因为经验和粗心的原因,我们会被此起彼伏的缺陷搞得心烦意乱。

其实只是因为客户很少会把质量当做默认的需求提出来。而我们也并未给自己一个机会,在软件构建中,明确质量的范畴到底意味着什么?对功能诉求恰如其分的满足当然是,对非功能(更合适的叫法应该是跨功能)需求的实现当然也是,还有缺陷的数目要足够少,代码的质量也要足够高。还有更多。

所以质量的范畴,远比我们想象的要广阔得多。有经验的开发者,在软件开发的初期,对显性的需求始终有谨慎的态度。因为他知道在繁杂的功能背后,需要填补进多少努力,才能保障理所当然的质量。以及我们知道,发现缺陷和问题越晚,修复的成本越高,所以如果只是期待测试人员作为守门人承担这努力的职责,也就必然是不现实的妄想了。这便是质量内建的初衷了。

质量内建是敏捷测试的核心,需要将测试全程介入、团队为质量负责和持续精准的自动化测试结合起来,在敏捷软件生命周期的每个环节做好缺陷的预防,把质量融入到产品的开发构建中。

曾经有国内传统行业的IT管理人员,质疑“团队为质量负责”这句话,认为有人为反正会有团队为质量负责,自己要不要负责并不重要,所以应该改成“我为质量负责”。企业文化对于人的思维的影响可见一斑。责任事大,所以只看到了负责两个字,而没有看到团队两个字。

当然这不只是喊喊口号就得以顺利进行,我们需要具体入微的流程和方法,去实现所谓的团队负责。比如:

  • 测试人员和业务人员共同参与需求的分析,切分以合适的粒度,不止是功能范围,还有可测试性,可集成性等多方面的考虑。
  • 测试案例先行于开发实现,验收条件清晰,Desk Check全角色参与。
  • 开发人员选择合理的方案实现,自动化测试精确覆盖。持续集成七步提交。
  • 精准回归测试,以及对生产环境监控。

事实上,对它们一一列举是徒劳的。因为整个开发活动中,每一个动作都点滴集聚对于质量的影响。高质量的反馈,必然需要团队全员在流程上,以及诸多实践方式,尽可能严丝合缝的协作。

有了如此极致而理想化的期待,我们自然就对参差不齐的质量问题见怪不怪了。

0 Comments

Leave a Reply

电子邮件地址不会被公开。 必填项已用*标注