软件开发过程质量就是指为了生成工件而对可接受流程(包括质量测评和质量标准)的实施和遵守程度。软件生产的过程质量与汽车类似,体现在三个层次:一是产品本身和用来生产、组装软件产品的零部件质量,包括用来进行软件开发或在软件开发过程中产生的代码、文档、模型和可执行系统等工件;而是软件开发活动本身对标准化软件开发过程的遵守程度,主要体现在软件开发过程的标准化、流程化、自动化程度和团队基本协作平台的效率;三十用来对整个软件产品进行验收的评测手段,它应该是被业界广泛认可和接收的方法。
一个软件生产企业的过程质量一般可以用他的软件过程成熟度等级(例如CMM/CMMI的级别)来决定,这也正是印度的软件公司能够获取很多外包项目的重要原因。但我们应该更清醒的看到:真正保证软件质量的不是CMM、CMMI的一纸评估报告,而是软件生产过程本身的成熟度,包括我们赖以达成成熟等级的方法、采用恰当的工具和平台,切实提高软件生产过程的成熟度。
在实际的项目产品中采用了一套这样的方法,涉及到的角色有项目经理1、对于需求的满足。在对于需求的满足上,为避免代码的设计/实现与需求出现大的偏差,要求由需求人员提供验证的场景,同时根据每天早会大家的计划在下班时对计划的完成根据验证场景进行验证。涉及到的角色:需求人员(负责验证场景的提供和需求实现的验证);测试人员(根据验证场景进行验证)。
缺乏信任和支持只是一个方面,QA工作本身就很具挑战性。它要求QA具有软件工程的知识、软件开发的知识、行业背景的知识、数理统计的知识、项目管理的知识、质量管理的知识等等。
我们常常遇到这样的问题,改进到一定程度就很难突破,感觉心有余而力不足了,就开始郁闷了。后来通过学习、培训、交流,思想和技能得到升华,又发现了木桶中最短的那块,然后又开始改进,然后又遇到了玻璃天花板,然后……就这样处于郁闷的循环中。
假使我们掌握了所有的知识,能突破所有的玻璃天花板,那是不是QA就可以一帆风顺了。答案是否定的。QA角色定义本身就有很大的局限性。QA充当的是过程警察的角色,无论是否有意义,都专横地强制过程的执行,容易在项目组中造成敌对的关系,收到排挤,而且这种警察的姿态也破坏了团队惊声。如此一来,QA工作还需要的是人际关系技能,就如我以前写得《质量平衡》和《QA应该独立于项目组吗?》一样,艺术化地处理这种关系。
我们的微信
我们的微博