(1)对教材与参考资料阅读后关于软件质量保障你的体会是什么?
"Capbility of software product to satisfy stated and implied needs under specified conditions"
软件产品在特定条件下满足明示和暗示需求的能力——搜狐翻译 (大佬自行理解翻译)
与之相比较,我还是喜欢另一种相对更好理解的软件质量的表示方式:
软件质量 = 程序质量 + 软件工程质量
就该表示方式进一布分析,如下:
1)程序质量:程序的质量体现在软件外在功能的质量。(邹欣 构建之法——现代软件工程)
就该说法作为软工小白的我个人理解为:是否满足了客户及用户的需求?
即能否满足不同功能的软件的不同需求。除了需要满足安全性保障需求以及国家化质量需求等基本需求外还要满足其他的独特的需求。
例如构建之法中提到的网站显示查询结果的进度,订票网站的吞吐量,支持同时在线的用户数量等。
在面对这些质量需求时,都能用复杂的多维度特性的综合指标来衡量。因为有特定的衡量方法,所以程序的质量分析是可以很直观的。
2)软件工程质量:软件的开发过程有三个重要的特性:“好”,“快”,“便宜”。通俗的理解是“软件在功能,成本,时间三个方面满足利益相关者的需求”
除去与具体程序相关的功能方面,软件工程质量就体现在以下方面:
- 软件开发过程的可见性
- 软件开发过程的风险控制
- 软件内部模块,项目中间阶段的交付质量,项目管理工具的因素
- 软件开发成本的控制
- 内部质量指标的完成情况
软件工程的质量:
关于软件工程质量的衡量方式CMMI(Capability Maturity Model Integration,即能力成熟度模型集成)这是一个能提高企业的管理水平,减低企业的成本的方法。
(详见链接可供参考)
软件质量的成本(人力物力及时间成本):
预防—>评审—>内部故障—>外部故障—>流程分析改进—>提高职业技能—>学习新的技术
(详见 邹欣 构建之法——现代软件工程)
综上软件质量保障工作(Quality Assurance)即是,
软件团队为了让软件达到事先定义的质量标准而进行的所有活动。
软件质量保障工作对一个项目来说是至关重要且必不可少的。QA有权力和义务分析并改进软件质量方面的问题,并且他的工作能力决定了软件的开发成本(包括人力物力及时间成本)。
(2)如果你是一个项目的QA,那么你认为你的工作职责范围是什么?
作为一个项目的QA,我的工作职责范围应该是把控好整个项目,尽最大的能力,用最小的成本,最好的完成事先定义的质量标准。
那么我的工作内容就是前面提到的全部内容,保障软件质量的工作。
首先,在我对项目的分析把控下,我的团队也应该对项目有详细透彻的分析,在制定了一系列的规划(其中主要包括对开发成本的控制)后,我们继而应讨论并且安排出明确的工作分工(其中包括任务及需求的分工),目的是在后期的软件测试过程中,如果有哪部分有问题,那么应该能有一个具体的Dev对此负责以及整改。
其次,还要根据项目的大小及成本考虑是否安排专门的测试人员,项目小或者成本低的情况下要和Dev沟通并亲自测试保障软件质量,在项目工程量浩大的情况下,就要安排具体的Test团队对程序进行审核并且与Dev进行交互沟通做出改进,减轻Dev的工作内容。
最后,在整个团队工作进度的尾期,完成了事先和客户定义好的质标后,和顾客进行沟通,以及安排后续给客户的演示。不出意外的话,完美竣工!!但是在这个过程中如果在出现BUG或者其他的问题就要我对这个项目负责,在继而追究是测试人员的懈怠问题还是开发人员的疏漏问题,然后对项目或者对出现的问题进行进一步的整改。整改完成后,再一次和客户商讨沟通,完美竣工。还要在事发后对问题进行分析,分析疏漏的原因和团队布置上的改进方法以及问题出现后的责任追究问题。要尽可能的保障项目过程中的一切模块有人负责,一切问题有人承担,并且要让团队中的所有人都要对项目有一个整体上的认知,避免高清的责任分工下的各人自扫门前雪的现象。要让所有人积极的参与,避免交接后的大量工作以及完全可以避免的疏漏。
(以上阐述来自 我-软工小白 的分析理解)
(3)如果你是一个项目经理,那么你认为这你的项目中需要专职的QA么?还是只需有Test即可?如果一旦出现问题,你如何界定由谁担责?
需要QA!!
先说下需要QA的原因。
软件质量的保障包含了很多方面,然而Test只是其中一方面而已。QA的工作是对整个项目的把控和规划,完成定义的质量标准。在最后和客户交接沟通的时候如果项目中还有问题和疏漏,出现的后果QA也要对此负责。但是QA也有权利追究Dev和Test的责任。在完成了客户需求做好了一切的交接后,面对问题,QA应该很清楚的了解问题出现的具体原因,是工作分配的不够清楚,还是人员积极性不够导致的责任懈怠问题,亦或者是开发或者测试人员的个人能力水平不够。
但是作为一个项目的QA,如果在问题发生后既没有清晰的解决方法,又欠缺整体意识和分析问题的能力。毋庸置疑的问题最大的是QA的个人工作能力。
所以,QA既是必不可少的,QA的能力也应该是登峰造极的。比如一个全栈工程师,既然他可以兼顾很多角色,那么作为一个专职的QA就能更得心应手,他可以很理性和专业的分配工作以及对问题进行整改。同时,作为强力的主宰者,他也可以根据项目的大小和精力的分配考虑是否聘用Test团队。因为作为大佬级别的人物,在精力充沛和项目工程量相对较小的情况下,他有绝对的能力去亲力亲为做Test工作。
综上,我的理解是Test可有可无,因为强力的QA可以兼顾这个工作,但是一个可以把控全局的QA必不可少!QA的个人能力也必须登峰造极。
关于担责问题。
首先,如果在和客户交接沟通时,QA的能力有问题,那么责任应该由项目经理和QA担责。因为项目经理找了不靠谱的人来做一个项目的质保负责人,那么就是项目经理的问题,同时QA没有履行好职责,也有推卸不了的责任。
其次,在QA的分析,安排,沟通,改进良好的情况下,出现了问题,责任由QA认定的责任方和QA共同负责。如果认定的责任方的工作懈怠或者对团体工作的积极性不够导致的问题,那么出现问题的责任方们一定要对此负责。既然是出现了问题,如果是责任方能力不够,就是QA分配任务时对人员的认识不够,如果是没有考虑到Dev和Test的交接沟通问题,那么就是QA分配任务的疏漏,无论如何都是QA的工作失职,QA有义务和问题的责任方共同承担责任。
最后,QA的工作分配一切无恙的情况下。出现了其他人员的个人的工作问题,由每个人的负责自己负责的板块。