QA需具备的知识

来源于：/quality/Index.html一、QA需要具备哪些知识？品管七大手法ISO9000SPCCMMIPMP质量保证度量配置管理6SigmaQA应具有软件工程的知识、软件开发的知识、行业背景的知识、数理统计的知识、项目管理的知识、质量管理的知识5.质量管理知识（含统计学）：参考书目：六西格玛管理现代质量控制与诊断规程质量免费质量无泪朱兰质量手册6sigma手册统计过程控制的策划与实施统计技术基本原理新版抽样检验国家标准实施手册 最新国家标准GBT 4091-2001 常一、软性特质1、思想决定高度拥有好的思想，才能引导自身向好的方向发展，QA首先要有先知先觉的思想。思想就是灵魂，QA要有天然的悟性，要真正吃透过程改进的思想，抓住CMMI的脉络，而不是仅仅知道CMMI是什么。2、谦虚的服务意识服务是一种态度，谦虚是一种本质，作为QA，既是公司利益忠诚的服务者，又是项目组成员谦虚的服务者，只有让公司及项目组轻松、愉快起来，QA的价值才“有可能”体现。3、良好的人际沟通技巧人际关系，无疑是QA必备的素养，作为过程改进的执行者与推动者，是维系过程的纽带，拥有良好的人际沟通技巧，将给QA工作增添很多的分数。4、严谨的逻辑思维能力逻辑思维是一种长期历练的结晶，看问题、办事情总得有个相互关联的逻辑结构。解决过程改进中存在的一些问题，将始终考验QA的这种能力。以往经验与知识体系固然重要，但要分清楚问题之间千丝万缕的关系，有理有据、省时省力地去解决问题，还需要您严谨的逻辑来推理与分析。5、持续的自我反省“吾日三省吾身”，作为QA，必须时刻保持自我反省与批评的态度，我们也不必要“三省”，只要“一省”就可以了，每天下班后，整理一下自己的思绪，并把体会写下来，记得：一定要动手写下来，积年累月，说不定您记下来的这些体会就会变成一本书您自己的书。6、坚韧的毅力与决心人们学说：兴趣是最好的老师，没错，兴趣足以让人入迷于某事，但毅力与决心却是达到目标必备的素质，这种品质既可以与生俱来，也可以后天培养。有志者事竟成，没错的，要有这种坚持不懈的努力。二、硬性特质QA作为SPI的执行者与推动者之一，只有在自身具备一定的条件下，才能进行工作，QA首先是一个专才，其次才是一个全才。作为一名QA，如果您仅仅关注于什么CMMI中的一些PA等，那您就玩完了，余下的这几十年你就逃离不了文员的角色了（夸张了一点，主要是想说明知识广度的重要性）。举个例子：excel中有很多统计分析的内容，如果连统计分析中最基本的概念都搞不清楚，方差什么的都忘的差不多了，那么，很抱歉，从头开始。拥有丰富的知识体系，打好奠基，才能一步一步走向目标。笔者根据多方面的观察、了解，以及切身的体验与工作，觉得首先应该具备如下的几点（或几方面）知识体系。1、软件工程体系如果连最基本的软件生命同期、软件开发阶段都不懂或者不是很明白，那么，您死定了，要么现在就开始去学，要么，脱离QA这个行业。2、质量体系知识以前的ISO现在好像已经过时了吧？那么CMM、CMMI呢？都过时了！知识的发展与淘汰原来都这么快，我们得加紧“吃知识”。6Sigma比较流行啦，快快来学吧旧的知识会被新的知识所替代，但有一点：思想不变！不管发展成“后CMMI”时代还是后什么时代，请随时准备储存您的质量体系知识。3、部分项目管理与开发经验要做好QA工作，并做一位“有可能”称职的QA，如果没有实地的项目开发与管理经验，只会纸上谈兵，那么，您就有可能成为“赵括”（历史人物，如果不懂历史，请Google或Baidu关键字：“秦赵大战 赵括 纸上谈兵”）。这样说可能有些言重，但这却也是事实，没有实地的项目开发、管理经验，有可能将过程改进做砸。4、配置管理配置项是什么？配置基线又怎么理解？里程碑呢？如果您一直问配置管理员这些名词概念。哈哈，结果可想而知了，也许配置管理员就以沉默来侮辱您；也许就要呕倒一大片人了。5、测试知识如果连最基本的测试覆盖率都弄不清楚咋回事，那么，恭喜你，你要被那些测试的人数落了。6、统计分析统计分析知识的重要性这里就不必多说了，很清楚的一点：用数据来说话，收集、分析数据的能力您应该有所具备。7、良好的文采及演讲才能想成为大师吗？想。那么，请随时随地准备提升您的写作能力，因为您要将您的思想写下来并发扬出去；请锻炼您的演讲才能，因为您必须时刻准备做一位思想的传播者。说这些可能对于目前从事过程改进的QA有些言重，但，至少您得把您的方法、理念在公司或项目组进行推广，所以，您必须有这些才能。二、揭示7个提高软件质量的务实做法软件缺陷之所以被称为臭虫是有原因的，它们通常会在软件中存在很长一段时间，它们总是在最不合时宜的时候出现在代码中，目前还没有有效的方法来彻底消除它们，这些都和臭虫有着极为相似的表现，因此软件缺陷也经常使用一个臭虫图标来表示。 如今残酷的商业环境造成软件开发成本急剧下降，开发时间不断被缩短，在人员不够的情况下还希望提高开发速度，而质量第一的标语只不过是挂在墙上的一道风景而已。在这种极端的开发环境下，软件开发团队如何保证质量呢？按照教科书上的做法肯定不现实，本文拟就根据我多年的开发实践，总结出7个比较务实的做法，以期在有限的资源下确保软件质量得到较大保证。这里引用Forrester给高质量的软件下的定义：软件符合业务需求，提供满意的用户体验，以及软件缺陷很少。 Forrester的分析师Visitacion和Gualtieri说：尽管许多企业应用程序开发团队在工具，流程和人员上投入了很多，但软件质量仍然不高,我认为这就是一种未采取务实方法的表现，要想提高软件质量，必须在整个开发生命周期实施质量保证计划，既与开发经理和开发人员有关，也与测试和质量保证人员有关，下面就一起来看看都有哪些务实的做法吧。 1、定义恰当的质量目标 软件最终是要交付给用户使用的，因此应从用户的角度来定义软件质量目标，软件应满足用户的业务需求，实现令人满意的用户体验。这样做的好处：既不将质量目标定得太高，任由你付出百般努力也无法实现，也不将目标定的过低，那样你无法给用户交差，根据时间，资源和预算客观情况定义合适的软件质量标准最好，既不让开发团队感觉痛苦，又能让用户满意。 相关角色：商业利益相关者，整个开发团队。 2、让每个人都知道质量的重要性 尽量在软件开发生命周期的前段时间减少软件缺陷，避免在后期来消灭缺陷，那样耗费的时间和精力更多。好处：让每个人都知道质量的重要性后，他们就会从心理上更注重代码质量，就会更用心写出高质量的软件。 相关角色：整个开发团队。 3、调整团队和个人的目标，纳入质量考核体系 根据业务需求调整团队和个人的工作目标，并纳入质量考核体系，实施严格的奖惩措施，刺激开发人员的工作效率和工作质量。好处：根据团队成员的执行表现给予适当奖励，让他们知道改善软件质量是一种奋斗目标，逐渐发展成为一种习惯。 相关角色：管理人员。 4、获取正确的需求 确保从需求获取开始，项目就朝正确的方向迈进，需求偏离或需求错误是让开发人员最头痛的事，大量的返工和修改会熄灭本已燃起的激情，而正确的需求会给开发人员带来愉快的心情。好处：减少返工和重新测试周期，减少总体工作量。 相关角色：管理人员，业务分析师，用户体验设计师和架构师。 5、将测试重点放在最关键和风险很高的点 在时间有限的情况下，不可能将方方面面的缺陷通过测试全部暴露出来，这时只有抓住重点，做到有的放矢，将核心功能点重点测试，避免重大缺陷成为漏网之鱼。好处：杜绝关键缺陷，即便有其它缺陷未被发现，也不至于影响到软件的整体质量。 相关角色：管理人员 ,质量保证人员。 6、提高设计质量 开发人员会根据架构师的设计文档进行编码的，如果设计描述得含混不清，那开发人员可能会根据自己的理解编写代码，或许就会造成南辕北辙的结果。好处：参照简明清晰的设计编写出来的代码也会更简单，更干净，也更容易测试和返工，代码中包含的错误也会更少，也更容易诊断和修复缺陷。 相关角色：架构师，开发人员。 7、合理使用自动化测试工具 传统的手工测试很难覆盖软件的全部功能点，某些后台功能只能借助工具来测试，此外，手工测试的效率低，反复单调的测试更是对测试人员心理素质的极大考验，容易造成对测试工作的懈怠，降低测试质量。好处：通过自动化测试工具的合理使用，可以缩短测试周期，提高测试的可重复性。 相关角色：质量保证人员，开发人员。 小结 提高软件质量是一项团队运动，每个人都需要参与其中，软件质量必须贯穿整个软件开发生命周期，减少返工次数，提高用户满意度，减少未经检验的非功能性需求的风险，如安全性和性能，管理人员必须对质量进行考评，并通过各种手段进行激励团队提高质量。三、如何实施软件质量保证软件质量保证（即SQASoftware Quality Assurance），是CMM2级中的一个关键过程域，它是贯穿整个软件过程的第三方独立审查活动，出现在大多数关键过程域的检查与验证的公共特性中，在整个软件开发过程中充当重要角色。从CMM2级中包含的6个关键过程域来看，无论是需求管理、软件项目计划、软件项目跟踪与监控，还是软件子合同管理、软件配置管理，都不同程度地存在于我们现在正在进行的软件项目开发过程中，对于它们的了解我们已经不再陌生，只有SQA这个关键过程域，是在我们准备以CMM2级要求的关键过程域为基础进行软件过程改进前未接触过的。在很多软件企业中还没有与之相对应的人员和工作方法，整套关注软件开发过程的软件质量保证体系还没有建立起来。所以，在企业以CMM2级关键过程域为参考进行软件过程改进时，SQA往往是一个难点，直接涉及到组织结构的变化。实施SQA的目的软件质量保证的目标是以独立审查方式，从第三方的角度监控软件开发任务的执行，就软件项目是否正遵循已制定的计划、标准和规程给开发人员和管理层提供反映产品和过程质量的信息和数据，提高项目透明度，同时辅助软件工程组取得高质量的软件产品。主要包括以下四个方面： 通过监控软件开发过程来保证产品质量； 保证开发出来的软件和软件开发过程符合相应标准与规程； 保证软件产品、软件过程中存在的不符合问题得到处理，必要时将问题反映给高级管理者； 确保项目组制定的计划、标准和规程适合项目组需要，同时满足评审和审计需要；除了以上四点之外，我们还希望SQA能作为软件工程过程小组（SEPG）在项目组中的延伸，能够收集项目中好的实施方法和发现实施不利的原因，为修改企业内部软件开发整体规范提供依据，为其他项目组的开发过程实施提供先进方法和样例。对SQA人员的素质要求1、SQA人员（有时简称SQA）要有很强的沟通能力。从实施SQA的目的中可以看出，SQA不在项目中，是独立于软件项目的第三方，但他要了解项目的开发过程和进度，捕捉到项目中不符合要求的问题，这就要求SQA能够深入项目，和软件开发经理以及项目组中的开发人员保持很好的沟通，这样才能及时获得真实的项目情况。2、SQA要熟悉软件开发过程。作为SQA，既然要确保项目组制定的计划、标准和规程，要符合项目组要求，那么SQA首先自己就要了解软件项目开发过程，以及企业内部已经有的开发过程规范。3、SQA本身要有很强的计划性。SQA一方面要监督软件项目组编写计划，另一方面SQA自身的工作也要有计划，并且能够按照计划开展工作。4、SQA要能应对繁杂的工作。作为SQA，在跟踪项目进行过程的时候要对项目组的很多工作产品进行审计，而且会参与项目组中的多种活动。同时一个SQA还有可能会面对多个项目组，所以任务相对繁杂细碎，这就要求SQA在处理这些事物的时候要耐心细致。5、SQA要客观，有责任心。作为第三方对项目过程进行监督，SQA要能保持自己的客观性，不能一味讨好项目经理，也不能成为项目组中的宪兵，否则会影响工作的开展。对于项目组中多次协调解决不了的问题，能够向项目的高层经理进言，完成SQA的使命。以上五点是作为SQA应该具备的基本素质，除此之外，一个好的SQA还应该在软件开发过程中作为开发人员或测试人员参与过一个或多个环节，这样他们才能在过程监督中比较准确地抓住重点，同时他们的意见和提出的解决办法也会更贴近项目组，容易被项目组接受。SQA人员的组成软件企业中的SQA人员既可以由全职人员担任，也可以由企业内具有相关素质、经过SQA培训的人员兼职担任。由此组成的SQA小组可能是一个真正的物理上存在的独立部门，也可以是一个逻辑上存在的平台。但不管是真正的独立部门还是逻辑上的平台，它都需要有一个灵魂人物SQA小组组长，来组织SQA小组的日常活动。在给一个项目组分配负责监督其项目过程的SQA时，一定要注意一点：就是该项目的SQA不能是该项目组的开发人员、配置管理人员或测试人员，一个项目的SQA除了监控项目过程，完成SQA相关工作以外，不应该参与项目组的其他实质性工作，否则他会与项目组捆绑在一起，很难保持客观性。NextPage 保持清晰的思路，储备应对各种突发事件的措施项目里最需要保持思路清晰的人是PM，别人可以乱，但PM一定不能乱，特别是在有突发事情发生时。因此，PM有必要有意识地锻炼自己抗压能力，比如多做项目发布、设计评审和数据订正的工作，并且要有意识地储备一些应急方案，比如代码回滚，紧急发布等等。另外，要清晰地弄清楚团队之间和系统之间的依赖关系，往往这种依赖性是引发事件的根源。 保持平和的心态，多站在他人立场考虑问题项目会进行地风风火火，项目成员之间也会争论得很激烈，往往这种时候，保持一个平和的心态很重要。不平和的心态往往会导致不平和情绪，不平和的情绪就会导致更加混乱的局面。保持平和心态的办法很多，很重要的一条是多站在他人立场考虑问题，一旦为他人体谅后，激烈的情绪会消退不少，并且在这种沟通态度的促发下，分歧方也会不由自主地为你考虑，非常有利于解决问题，达成一致。 加强项目自动化方面的能力项目各个细节如果全都靠人肉去完成，会极大增加控制风险，而减少风险的最大利器就是用成熟的自动化方案去完成一些工作，特别是项目构建、持续集成和发布等工作。PM应该在怎样让日常工作流程化和工具化方面多动一点脑筋，而这方面敏捷开发提供很多很好的思路和方案。 共识和决议要通过邮件发给相关人在项目过程中会产生很多变故，需求和设计文档里定义不了所以问题，为解决变故而形成的临时决议一定要通过邮件发给相关人，不光是知会，更重要的是为决议提供证据，这些临时的决议往往会引发问题，当问题产生追溯责任时需要用到这些证据。 注意倾听组员的意见，给他们留出足够的发挥空间特别是在大公司带项目，组员都算是开发的精英，都不是甘于做个机械的coder，因此学会倾听他们的想法，深入了解他们想得到的，尽量满足他们成长需求，就算是由于项目客观原因，没法采纳他们的建议，也得和他们把道理说清楚，不合适用强势方式来决断，毕竟技术人员的需求和管理不同一般。 不以个人意愿为基准，凡是以大局为重PM也是人，在平时工作过程中，难免会带有个人情绪，但PM应该清醒地认识到自己身后还有一个团队，大家的情绪和状态与自己息息相关，所以说话做事一定要三思而行，考虑清楚对别人的影响，切勿乱放炮，失去同仁的信任。小结项目领导者有几个特性：自身技术扎实；注意节点控制；善于和员工沟通；为人有亲和力；自己很闲，但是员工工作很充实；知人善用；深入了解项目细节，做事有计划；有创新能力；有解决突发事件的能力。特别是自身技术扎实这个点，软件项目的PM如果自身在技术上缺乏深入，对细节不够了解，会直接影响他的判断力和全局控制力，但同时也得把握具体工作参与的力度。总结的说，合格的PM应该是个有大局观、全局观的有魄力的人！四、质量保证漫漫谈之QA基本工作流程QA工作的一个重要目标就是使各个项目的管理和开发、测试活动遵循组织要求的流程，当然QA工作本身也是需要遵循一定的流程的，以下是笔者在实际工作中总结出了基本工作流程，供大家参考。1、制定QA计划2、对项目实施活动中的过程和文档进行检查 项目立项阶段 审计立项会议过程、审计立项会议记录 检查配置库是否建立 项目计划阶段 评审项目管理计划、进度计划、裁剪表、估算表等项目管理文档 审计项目计划评审过程，审计评审问题和评审记录 审计配置管理计划、配置管理系统 审计项目计划基线 需求分析阶段 评审需求分析启动会是否进行、会议记录 审计需求分析文档 审计需求分析评审过程，审计评审问题和评审记录 审计需求分析基线 系统设计阶段 评审系统设计文档 审计系统设计评审过程，审计评审问题和评审记录 审计系统设计基线 概要设计阶段 评审概要设计文档 审计概要设计评审过程，审计评审问题和评审记录 审计概要设计基线nextpgae 详细设计阶段 评审详细设计文档 审计详细设计评审过程，审计评审问题和评审记录 审计详细设计基线 编码阶段 评审源代码 审计源代码评审过程，审计评审问题和评审记录 审计源代码基线 单元测试阶段 评审单元测试文档 审计单元测试评审过程，审计评审问题和评审记录 审计单元测试基线 集成测试阶段 评审集成测试文档 审计集成测试评审过程，审计评审问题和评审记录 审计集成测试基线 系统测试阶段 评审系统测试文档 审计系统测试评审过程，审计评审问题和评审记录 审计系统系统测试基线 产品发布阶段 审计发布过程 项目总结阶段 审计项目总结报告 审计项目总结过程 - 定期检查工作 针对项目成员不明白的过程和模板进行指导 检查进度计划、管理计划的更新 检查配置管理状态 每周审计项目周报 项目变更时，审计变更过程及变更影响 里程碑结束时，审计里程碑总结情况3、向受影响的组织或者项目通报QA活动的结果4、对于组织或者项目内不能解决的不符合问题，向高层管理者汇报并跟踪问题到关闭五、质量管理漫漫谈之软件质量指标尽管软件质量被很多人经常性的挂在口头，但是如果被问到“衡量软件质量的指标有哪些？”相信很多人会说不出话来，为了帮助更多的软件质量人了解衡量软件质量的指标，下面就简要的介绍一下软件质量指标。软件质量指标是衡量那些可识别的软件质量特性的项目，有助于软件质量进行度量，选择软件工程方法来达到特定的质量目标。在一个理想的范围内，一个系统总是最大限度的展示所有这些属性的可能价值，系统将随时可用、绝不崩溃、可以立即提供结果、易于使用。在ANSI/IEEE中提到的软件的6个品质要素如下：正确性：实现的功能达到设计规范并满足用户需求的程度可靠性：在规定的时间和条件下，维持其性能水准的程度易用性：用户掌握软件操作所要付出的时间及努力程度效率：软件执行某项功能所需的计算机资源和时间的有效程度可维护性：当环境改变或者软件发生错误时，执行修改或者修复所作的努力地程度可移植性：从一个系统/环境移到另一个系统/环境的容易程度根据这些软件品质要素，我们可以确定一系列的软件质量指标：1、功能性的质量指标功能的正确性：系统功能和用户的实际需求、已定义的产品规范一致功能的准确性：系统产生的结果在精度允许的误差范围内功能的完整性：所有功能及其定义清楚、可用2、可用性的质量指标可操作性：容易使用和操作，包括理解用户界面、适应一些特殊用户的可选项等通用性：数据显示、网络通信接口和用户界面等都遵守已有的软件标准一致性：在软件开发整个生命周期内建立和使用相同的标准，保证全局变量、数据类型、出错处理的命名和使用一致3、可靠性的质量指标自我恢复能力：当系统的某个功能失效发生时，系统在当前环境下能实现故障自动转移，重新自动配置、继续执行的能力，软件系统具有自我检测、容错、备份等机制，尽量做到独立于硬件的编码、硬件设备之间的通信协议一致等健壮性：各种恶劣环境(大数据量、大用户量)下系统能正常工作分布性：软件系统的某些子功能或子系统被定位于不同的处理主机、存储设备4、性能的质量指标有效性：系统在通信、处理、存储等方面占有很少资源或者对所使用的资源进行了优化完整性：系统具有良好的安全管理，能防止不安全存取系统、防止数据丢失病毒入侵等易存取性：对系统的存取权限设置清楚，存取操作方便，存取操作有记录5、可维护性的质量指标模块化：指讲一个复杂的软件系统分解为分别命名并具备最小耦合性、很强凝聚性、结构化的组件灵活性：容易为系统增加一个新功能或者新的数据而不需要进行大量的代码修改或者设计修改可测试性：测试软件组件或者集成产品时查找缺陷的简易程度可追溯性：对一个特殊需求容易找出相应的代码，反之，也可以根据代码找出特定的需求兼容性：软件、硬件、通信系统之间协调及兼容其他系统的能力可解释性：相关文档齐全、符合标准、逻辑清晰、描述准确、用词恰当，容易理解和定位6、可移植性质量指标适应性：系统不依赖于环境，即系统不做修改或作很少的修改即可运行在其他环境下易安装性：与在指定的环境下安装软件所需努力有关的软件属性。如在线更新、安装包自动生成等。可重用性：一个软件组件除了在最初开发的系统之外应用于其他系统的能力互操作性：软件系统与其他系统交换数据和服务的难易程度可替换性：与软件在该环境中用来替代指定的其他软件的机会和努力有关的软件属性看过读者其他文章的朋友会觉得上面的内容似曾相识，不错，笔者之前的文章非功能需求的6种类型中的内容和此文中的内容遥相呼应，一定程度上也反馈出“质量就是客户满意的程度”的观点。实际上，软件的质量并非静态的而是动态的，假如客户对于某项质量指标没有要求，就没必要花费时间和工作去满足该项质量指标，因此，在具体软件系统的质量指标定义上，一定要结合用户的非功能需求，不但能恰到好处的满足客户需求，也能尽可能的节省开发成本。六、软件质量保证的误区质量保证中的质量定义：产品或服务满足显式或隐含需求能力的功能和特性总和。而我们外包测试我们提供的是测试服务，我们除了分析客户的显式需求，还要分析客户的隐含的需求。显式的需求我们很好理解，即客户通过需求文档、口头要求、电子邮件要求、变更管理系统中对需求的变更等，这些都是用户提出来的需要我们作为测试中依据的。当然我们不是特别希望客户通过口头要求、电子邮件等非正规形式提出需求，但是目前现实的情况，我们也要考虑，规范需求管理是我们帮助客户不断改进的一个方面。而我们更多的应该关心客户的隐含需求，这些需求包括：1、 用户可能认为我们理解或遗漏的。例如认为我们很熟悉其行业的特点，而没有在文档中说明；2、 行业规范。每个行业都有一些行业中大家中的一种规则，例如会计帐务记录和报表，嵌入式领域中对物理内存考虑等；3、 计算机领域的规范和习惯。例如，窗口中的确定按钮在取消按钮的左侧。Web中的导航设置等。4、 客户对计算机技术的限制。例如，其不太清楚对性能指标如何来描述。对系统中的安全性要求，从哪些方面描述等。度量不是指具体的事物，而是对每个事物的度量。质量是一个度量元，事物度量的结果应该有一个明确的描述，不管是定量的还是定性的。当然定性的也最好是通过能够一些量化的参数判断。目前很多的质量保证原则不会与当今的商业软件系统开发的现实相符合，也存在一些对质量方面的片面认识。下面是根据一些书籍结合我对外包方面的一些经验汇总的对质量的认识误区。1、质量需求决定进度。事实上，对于大多数软件系统而言，市场压力和竞争决定进度。而对于我们外包测试行业来说，客户要求则决定我们的测试进度，归根结底，客户要求也是基于市场压力和竞争等方面的考虑。引用1997年Microsoft公司的测试主管Roger Sherman讲述的一段话来很好的证明。“进度通常是质量的敌人，但在Microsoft，进度被看做是产品质量的一个部分。的确，Microsoft 研究其市场并基于市场需求确定其自己的质量定义。而我们目前提高测试服务的金融客户，尤其是银行，对质量要求非常高，而基于国有银行、商业银行、城市银行，还有WTO开放后进入的外资银行，对新产品的推出速度或多或少决定其在市场上的占用率，这些从外汇交易、黄金交易、基金托管等业务可窥见一斑。2、质量等于可靠性，或可以说零缺陷是高质量产品的要求。而实际上可靠性仅仅是产品质量的一部分。我一直认为所说的零缺陷，只是一个海市蜃楼之类虚无缥缈的东西。这种零缺陷的软件系统我想可能很少存在，当然如果是经过了实践证明，的确某软件系统不存在任何缺陷，那就是说这种软件系统连用户认为连建议修改或完善的地方都没有。例如，控制激光手术的伽马刀系统是否满足零缺陷的要求。一般商用软件不愿意支付零缺陷产品或100%可靠性所需要的成本。而对于3、用户清楚他们的需求。事实上，用户需求往往是模糊的和粗略的，并不详细和具体。上面我们分析过，由于用户各种因素，很难准确的描述他们的需求。例如一个银行的报表经常有上百个之多，而这些报表是否都是需要的。有时候可能通过调研获得需求，但是这种调研是否对需求带来用途呢，而在需求描述中还是需要尽量把所能考虑的需求都描述了，结果使系统臃肿不堪。4、需求就是正确的。提出业务需求的人也是普通人，人是需要通过实验及排错的过程才能得到好的设计。如果开发过程没有充足的时间完成设计、测试和修复缺陷将不可能开发出好的产品。七、QA的工作（来自论坛写的较好的）1 摘要本文是对于QA工作的个人总结。1.1 QA的工作职责项目组成员对于QA的工作职责有不同的看法，有人说：QA就是测试，找出软件缺陷，可以保证软件质量；有人说：QA就是对CMM与ISO体系文档的培训，宣传公司质量管理措施；有人说，QA来进行过程评审和产品审计的，可以看到这两份的文档，等等。那么QA的工作职责到底是什么呢？1.2 QA的角色身为一名QA想要作好自己份内的工作，必须演好9个角色，如果某些角色相对地被忽视了，则整个工作无法达到尽善尽美，不同的角色投入的时间比例不同，要达到最佳的组合效果必须按不同的阶段做不同的事。这些角色主要体现在三方面：“人际关系角色”、“情报角色”与“咨询角色”。细分的话，可以理解为：联络人、侦探、发言人、危机预警者、说服者、纠正措施跟踪者、咨询者、培训师、参与者。1.3 QA的作用QA就像消防队员一样，工作做得好不好，不在于一年灭了多少次火，如果能做到一年里没有火灾的话，那QA的消防工作就做得非常到位了。1.4 QA需要的协助团队中的每个人都需要或多或少的帮助，QA也不例外，他也会犯错，他也有资源短缺的时候，那么当QA需要其他成员协助的时候，希望对方能提供什么呢？2 正文本人在项目工作中产生了一些看法，希望能和更多的人一起讨论，如何将QA工作做的更好？以问答的形式来阐述我的观点。2.1 QA的工作职责是什么？：根据公司的质量管理体系文件中的作业指导书部门职责与职位说明书指出：质量保证工程师u 职位概要：管理公司产品质量，实施质量改进计划，达到产品质量目标。 工作内容：u1) 向质量保证主管汇报工作情况；2) 协助质量保证主管制定和维护公司软件质量保证制度；3) 参与CMM和ISO质量体系的培训和宣传工作；4) 根据要求进行过程评审和产品审计，并对评审中发现的不符合项进行处理、跟踪，直至问题关闭为止。2.2 QA的角色是什么？：QA有9个角色，为：联络人、侦探、发言人、危机预警者、说服者、纠正措施跟踪者、咨询者、培训师、参与者。(1)联络人QA 做检查或评审与审核，并不是我们想查什么就查什么。QA要检查的内容在公司的过程、标准与规范、或质量体系中已经完全定义好了，并遵循QA的计划来执行的。QA一方面是制定流程并且保证流程的执行；另一方面就是不断搜集项目团队反馈，不断根据企业发展改进优化现有流程。我们如何确定流程的可操作性呢？就需要QA不断的充当联络人的角色，了解项目组当前的需要。企业的发展会不断变化，流程的变更也需要变化，所以，联络人的角色是一直存在的。(2)侦探QA 的职能是警察吗？我说，不是，QA更象一个侦探。在项目管理中，QA作为监督者的角色存在有一定意义。QA就象项目经理和高层主管的另一只眼睛，针对评审时发现的问题给软件项目经理提出改进建议。很多时候是由于项目团队不符合流程、不规范的做法才导致了产品质量问题，QA的工作之一（4）是抓住流程中的问题，通过保证流程的执行来大幅度降低执行过程中的差错。这个时候，QA就需要一双火眼金睛，找出可疑点。侦探与警察的区别是：侦探是将发现的不符合现象汇报给项目经理和部门主管，至于解决的执行由项目经理安排，QA只需要跟踪和验证最后的纠正措施；警察是发现有不符合现象直接解决，涉及到对人的处理而不光是对事的解决。可以这么说，（举例）警察的角色更适用于项目经理，侦探发现了小偷，报告给了警察，警察去抓小偷，将脏款交出来。(3)发言人QA 为了让自己的工作能够体现出管理公司产品质量，达到产品质量目标上，会有一系列报告，如：产品审计报告、过程评审报告。对报告内数据的收集、统计分析就能反映出项目组成员的工作效率和效果。QA是项目组的朋友。当项目组按正常的流程执行，有一定的工作成效时，QA在报告中应体现出项目组的工作实效。很多人往往都认为，QA只是汇报产生的问题，这样带来了不好的影响，不能如实反映项目情况，担心增加工作量和无意义的工作。其实，QA的报告内容之一就是对项目组成员的工作加以肯定，强调工作成绩是主要的，出现问题也是正常的，报告是为了预防下一次的不符合项发生。(4)危机预警者为什么说是危机预警者，而不是危机管理者呢？在项目启动时，项目经理一般会在软件开发计划中说明在该项目中存在的潜在风险列表，并有相对应的风险减缓措施，在项目进行中会整理项目问题日志。这些措施都是为了项目控制所采取的，此时的项目经理可以充当危机管理者的角色。QA协助项目经理，对项目开发/维护过程中出现的危机要及时汇报，QA的工作做的好不好，不是看解决了多少不符合项，而是预防了多少不符合项。没有问题产生是皆大欢喜。预防为先！(5)说服者当SQA 人员针对评审时发现的问题给软件项目经理提出改进建议后，项目经理出于进度的压力或其他原因，并不引起重视甚至拒绝采取任何措施，这是很正常的现象。这个时候，QA和项目经理经过一番沟通，发挥口才，说服项目经理在项目组中解决不符合项。避免扩