摘要:---质量改进的2个前提--- 前提一:向开发要质量 当前很多公司将测试的同学称为QA(Quality Assurance,质量保证),意思是由测试保证质量。前三节我们讲了内部质量和外部质量的关注系:质量是向开发要的。(即质量管理是需要向前管控的) 原因一:测试不能提
---质量改进的2个前提---
前提一:向开发要质量
当前很多公司将测试的同学称为QA(Quality Assurance,质量保证),意思是由测试保证质量。前三节我们讲了内部质量和外部质量的关注系:质量是向开发要的。(即质量管理是需要向前管控的)
原因一:测试不能提高产品的内部质量
测试阶段发现的Bug修正后,报告数据暂时看起来好了,但是发臭的代码并不会因此变好,测试只能消灭Bug,不能消失Worm,只要环境和复杂条件触发(软件产品应用端的使用环境及用户操作方式,在测试的层面无法100%覆盖),Worm一定会变成Bug。
原因二:开发移交质量差,测试的质量也会差。
没有经过开发冒烟测试的软件移交给测试后,要么测试的等待时间变长(开发没有考虑可测试性,部分转测需要造的参数、造环境,到转测时才发现这没有那没有),要么测试受阻。
而移交的质量高,则给测试争取到更充分的时间。好的软件工程是很难测出BUG的,这给测试提出了挑战,也需要给测试同学足够的时间接受挑战。
原因三:依赖测试发现BUG再去修复是非常低效的。
测出问题后再去定位修复,会降低效率。相反,由开发来保证质量,可以更早的发现缺陷,还可以由代码层面发现同类的问题,从根源解决。
前提二:以需求为粒度控制质量
精益敏捷一直宣导小步迭代,快速交付。传统的瀑布模型的特点是很多需求绑在一起批量移交开发,开发完成后再批量移交测试。在瀑布模型下,很难在开发内建质量。
1、开发人员无法对需求交付质量负责
当需求绑在一起开发时,在开发阶段又被拆分为各模块。没有使用用户故事并实例化需求,开发同学关心的是单一模块的开发完成,没有针对用户故事进行验收。
2、在时间压力下,牺牲整体的质量
开发团队都有帕金森综合症,在开发阶段所有的需求都绑在一起,任何一个需求未完成都会影响整体交付。到批量移交的时限时,质量往往成了牺牲品。
在瀑布的批量移交模式下,开发更关注的是移交的时间,也叫“以项目为单位控制时间”。
当下的精益敏捷开发,以用户故事拆分需求,制定严格的DOD(达到质量标准,需求才可以移动到下一阶段)。每个需求可以单独移动,更灵活,使开发更关注需求及实例化验收。叫“以需求为粒度质量”。
(责任编辑:环球精益网)
|
谈谈您对该文章的看