软件质量保证工程师

基本目标 目标 1: 软件质量保证 工作是有计划进行的。 目标 2: 客观地验证软件项目产品和工作是否遵循恰当的标准、步骤和需求。 目标 3: 将软件质量保证工作及结果通知给相关组别和个人。 目标 4: 高级管理层接触到在项目内部不能解决的不符合类问题。 目标 5: 软件质量需要全面的测试工作来保证。 由来 我们知道，国外很多的大公司，QA的职责就是测试（主要是系统测试），比如IBM、CA、PeopleSoft等。其实在最初，几乎所有的公司都是这样的。后来，由于缺乏有效的项目计划和软件质量保证 项目管理，留给系统测试的时间很少（注：我以前做的一个项目，项目经理就明确告诉我系统测试就1天，没得商量）。另外，需求变化太快，没有完整的需求文档，测试人员就只能根据自己的想象来测试。这样一来，测试就很难保障产品的质量，事先预防的QA职能就应运而生。 事先预防其实是借鉴了TQM的思想，而且也符合软件工程“缺陷越早发现越早修改越经济”的原则。这些思想的渊源还可以追溯到中国古代的典故中，比如曲突徙薪、扁鹊论医术等。 现状 实施CMM的企业越来越多了，CMM模型就要求建立QA角色。这里的QA类似于过程警察，主要职责是，检查开发和管理活动是否与已定的过程策略、标准和流程一致，检查工作产品是否遵循模板规定的内容和格式。在这些企业中，一般还要求QA独立于项目组，以保障评价的客观性。从国内来看，多数的QA没有技术背景，检查出的偏差多为鸡毛蒜皮，再加上自己没有令人信服的背景，领导也不支持，当然做起来就很困难了。 缺乏信任和支持只是一个方面，QA工作本身就很具挑战性。它要求QA具有软件工程的知识、软件开发的知识、行业背景的知识、数理统计的知识、项目管理的知识、质量管理的知识等等。 我们常常遇到这样的问题，改进到一定程度就很难突破，感觉心有余而力不足了，就开始郁闷了。后来通过学习、培训、交流，思想和技能得到升华，又发现了木桶中最短的那块，然后又开始改进，然后又遇到了玻璃天花板，然后……就这样处于郁闷的循环中。 假使我们掌握了所有的知识，能突破所有的玻璃天花板，那是不是QA就可以一帆风顺了。答案是否定的。QA角色定义本身就有很大的局限性。QA充当的是过程警察的角色，无论是否有意义，都专横地强制过程的执行，容易在项目组中造成敌对的关系，受到排挤，而且这种警察的姿态也破坏了团队精神。如此一来，QA工作还需要的是人际关系技能，就如我以前写的《质量平衡》和《QA应该独立于项目组吗？》一样，艺术化地处理这种关系。 未来 从某种程度上说，独立的QA审查机制是瀑布模型的产物。随着现代软件开发技术的演变，螺旋模型和迭代模型的兴起，QA机制正在悄然发生变化。这种变化就是从独立专职的QA向贯穿过程的兼职QA演变。在CMMI模型中，这种兼职的QA也是被允许的。为什么会发生这种改变呢？无论是XP、RUP还是其它先进的方法论，都是先产生架构，然后再增量开发，直到完成。这种模式中，需求和设计缺陷在各个迭代周期被所尽早发现和修复，质量也内建于架构和过程中，项目的成本和进度也得到保障。 到那时，是不是独立的QA就不复存在了呢？有些成熟度较低的企业还是需要的，主要是保证过程执行的有效性和评价的客观性。 理论探索 过程的认识 我们都知道一个项目的主要内容是：成本、进度、质量；良好的项目管理就是综合三方面的因素，平衡三方面的目标，最终依照目标完成任务。项目的这三个方面是相互制约和影响的，有时对这三方面的平衡策略甚至成为一个企业级的要求，决定了企业的行为，我们知道 IBM的软件是以质量为最重要目标的，而微软的“足够好的软件”策略更是耳熟能详，这些质量目标其实立足于企业的战略目标。所以用于进行质量保证的SQA工作也应当立足于企业的战略目标，从这个角度思考SQA，形成对SQA的理论认识。 软件界已经达成共识的：影响软件项目进度、成本、质量的因素主要是 “人、过程、技术”。首先要明确的是这三个因素中，人是第一位的。 许多实施 CMM的人员沉溺于CMM的理论过于强调“过程”，这是很危险的倾向。这个思想倾向在国外受到了猛烈抨击，从某种意义上各种敏捷过程方法的提出就是对强调过程的一种反思。“XP”中的一个思想“人比过程更重要” 是值得我们思考的。我个人的意见在进行过程改进中坚持“以人为本”，强调过程和人的和谐。 根据现代软件工程对众多失败项目的调查，发现管理是项目失败的主要原因。这个事实的重要性在于说明了 “要保证项目不失败，我们应当更加关注管理”，注意这个事实没有说明另外一个问题“良好的管理可以保证项目的成功”。很多人基于一种粗糙的逻辑，从一个事实反推到的这个结论，在逻辑上是错误的，这种错误形成了更加错误的做法，这点在SQA的理解上是体现较深。 如果我们考证一下历史的沿革，应当更加容易理解 CMM的本质。CMM首先是作为一个“评估标准”出现的，主要评估的是美国国防部供应商保证质量的能力。CMM关注的软件生产有如下特点： ⑴质量重要 ⑵规模较大 这是 CMM产生的原因。它引入了“全面质量管理”的思想，尤其侧重了“全面质量管理”中的“过程方法”，并且引入了“统计过程控制”的方法。可以说这两个思想是CMM背后的基础。 上面这些内容形成了我对软件过程地位、价值的基本理解；在这个基础上我们可以引申讨论 SQA。 生产线的隐喻 如果将一个软件生产类比于一个工厂的生产。那么生产线就是过程，产品按照生产线的规定过程进行生产。SQA的职责就是保证过程的执行，也就是保证生产线的正常执行。 抽象出管理体系模型的如下，这个模型说明了一个过程体系至少应当包含 “决策、执行、反馈”三个重要方面。 QA的职责就是确保过程的有效执行，监督项目按照过程进行项目活动；它不负责监管产品的质量，不负责向管理层提供项目的情况，不负责代表管理层进行管理，只是代表管理层来保证过程的执行。 SQA和其他工作的组合 在很多企业中，将 SQA的工作和QC、SEPG、组织级的项目管理者的工作混合在一起了，有时甚至更加注重其他方面的工作而没有做好SQA的本职工作。 根据 hjhza 的意见“中国现在基本有三种QA（按照工作重点不同来分）：一是过程改进型，一是配置管理型，一是测试型”。我个人认为是因为SQA工作和其他不同工作组合在一起形成的。 下面根据本人经验对它们之间的关系进行一个说明。 QA和QC 两者基本职责 QC：检验产品的质量，保证产品符合客户的需求；是产品质量检查者； QA：审计过程的质量，保证过程被正确执行；是过程质量审计者； 注意区别检查和审计的不同 检查：就是我们常说的找茬，是挑毛病的； 审计：来确认项目按照要求进行的证据；仔细看看CMM中各个KPA中SQA的检查采用的术语大量用到了“证实”，审计的内容主要是过程的；对照CMM看一下项目经理和高级管理者的审查内容，他们更加关注具体内容。 对照上面的管理体系模型，QC进行质量控制，向管理层反馈质量信息；QA则确保QC按照过程进行质量控制活动，按照过程将检查结果向管理层汇报。这就是QA和QC工作的关系。 在这样的分工原则下， QA只要检查项目按照过程进行了某项活动没有，产出了某个产品没有；而QC来检查产品是否符合质量要求。 如果企业原来具有 QC人员并且QA人员配备不足，可以先确定由QC兼任QA工作。但是只能是暂时的，独立的QA人员应当具备，因为QC工作也是要遵循过程要求的，也是要被审计过程的，这种混合情况，难以保证QC工作的过程质量。 QA和SEPG 两者基本职责 SEPG：制定过程，实施过程改进； QA：确保过程被正确执行 SEPG应当提供过程上的指导，帮助项目组制定项目过程，帮助项目组进行策划；从而帮助项目组有效的工作，有效的执行过程。如果项目和QA对过程的理解发生争持，SEPG作为最终仲裁者。为了进行有效过程改进，SEPG必须分析项目的数据。 QA本也要进行过程规范，那么所有QA中最有经验、最有能力的QA可以参加SEPG，但是要注意这两者的区别。软件质量保证 如果企业的SEPG人员具有较为深厚的开发背景，可以兼任SQA工作，这样利于过程的不断改进；但是由于立法、执法集于一身也容易造成SQA过于强势，影响项目的独立性。 管理过程比较成熟的企业，因为企业的文化和管理机制已经健全， SQA职责范围的工作较少，往往只是针对具体项目制定明确重点的SQA计划，这样SQA的审计工作会大大减少，从而可以同时审计较多项目。 另一方面，由于分工的细致化，管理体系的复杂化，往往需要专职的SEPG人员，这些人员要求了解企业的所有管理过程和运作情况，在这个基础上才能统筹全局的进行过程改进，这时了解全局的SQA人员就是专职SEPG的主要人选；这些SQA人员将逐渐的转化为SEPG人员，并且更加了解管理知识，而SQA工作渐渐成为他们的兼职工作。 这种情况在许多 CMM5企业比较多见，往往有时看不见SQA人员在项目组出现或者很少出现，这种SEPG和SQA的融合特别有利于组织的过程改进工作。SEPG确定过程改进内容，SQA计划重点反映这些改进内容，从保证有效的改进，特别有利于达到CMM5的要求。从这个角度，国外的SQA人员为什么高薪就不难理解了，也决定了当前中国SQA人员比较被轻视的原因；因为管理过程还不完善，我们的SQA人员还没有产生这么大的价值嘛！ QA和组织级的监督管理 有的企业为了更好的监督管理项目，建立了一个角色，我取名为 “组织级的监督管理者”，他们的职责是对所有项目进行统一的跟踪、监督、适当的管理，来保证管理层对所有项目的可视性、可管理性。 为了有效管理项目， “组织级的监督管理者”必须分析项目的数据。 他们的职责对照上图的模型，就是执行 “反馈”职能。 QA本身不进行反馈工作，最多对过程执行情况的信息进行反馈。 SQA职责最好不要和“组织级的项目管理者”的职责混合在一起，否则容易出现SQA困境：一方面SQA不能准确定位自己的工作，另一方面过程执行者对SQA人员抱有较大戒心。 如果建立了较好的管理过程，那么就会增强项目的可视性，从而保证企业对所有项目的较好管理；而 QA来确保这个管理过程的运行。 工作内容 计划 针对具体项目制定 SQA计划，确保项目组正确执行过程。制定SQA计划应当注意如下几点： 有重点：依据企业目标以及项目情况确定审计的重点 明确审计内容：明确审计哪些活动，那些产品 明确审计方式：确定怎样进行审计 明确审计结果报告的规则：审计的结果报告给谁 审计/证实 依据 SQA计划进行SQA审计工作，按照规则发布审计结果报告。 注意审计一定要有项目组人员陪同，不能搞突然袭击。双方要开诚布公，坦诚相对。 审计的内容：是否按照过程要求执行了相应活动，是否按照过程要求产生了相应产品。 问题跟踪 对审计中发现的问题，要求项目组改进，并跟进直到解决。 素质 过程为中心：应当站在过程的角度来考虑问题，只要保证了过程， QA就尽到了责任。 服务精神：为项目组服务，帮助项目组确保正确执行过程 了解过程：深刻了解企业的工程，并具有一定的过程管理理论知识 了解开发：对开发工作的基本情况了解，能够理解项目的活动 沟通技巧：善于沟通，能够营造良好的气氛，避免审计活动成为一种找茬活动。 活动 软件质量保证（SQA）是一种应用于整个软件过程的活动，它包含： ⒈一种质量管理方法 ⒉有效的软件工程技术（方法和工具） ⒊在整个软件过程中采用的正式技术评审 ⒋一种多层次的测试策略 ⒌对软件文档及其修改的控制 ⒍保证软件遵从软件开发标准 ⒎度量和报告机制 SQA与两种不同的参与者相关 —— 做技术工作的软件工程师和负责质量保证的计划、监督、记录、分析及报告工作的SQA小组。 软件工程师通过采用可靠的技术方法和措施，进行正式的技术评审，执行计划周密的软件测试来考虑质量问题，并完成软件质量保证和质量控制活动。 SQA小组的职责是辅助软件工程小组得到高质量的最终产品。SQA小组完成： ⑴为项目准备SQA计划。该计划在制定项目规定项目计划时确定，由所有感兴趣的相关部门评审。 ·需要进行的审计和评审； ·项目可采用的标准； ·错误报告和跟踪的规程； ·由SQA小组产生的文档； ·向软件项目组提供的反馈数量。 ⑵参与开发项目的软件过程描述。评审过程描述以保证该过程与组织政策，内部软件标准，外界标准以及项目计划的其他部分相符。 ⑶评审各项软件工程活动，对其是否符合定义好的软件过程进行核实。记录、跟踪与过程的偏差。 ⑷审计指定的软件工作产品，对其是否符合事先定义好的需求进行核实。对产品进行评审，识别、记录和跟踪出现的偏差；对是否已经改正进行核实；定期将工作结果向项目管理者报告。 ⑸确保软件工作及产品中的偏差已记录在案，并根据预定的规程进行处理。 ⑹记录所有不符合的部分并报告给高级领导者。 技术评审 简介 正式技术评审是一种由软件工程师和其他人进行的软件质量保障活动。 目标 ⑴发现功能、逻辑或实现的错误 ⑵证实经过评审的软件的确满足需求 ⑶保证软件的表示符合预定义的标准 ⑷得到一种一致的方式开发的软件 ⑸使项目更易管理 评审会议 3-5人参加，不超过2小时，由评审主席、评审者和生产者参加，必须做出下列决定中的一个 : ⑴工作产品可不可以不经修改而被接受； ⑵由于严重错误而否决工作产品； ⑶暂时接受工作产品。 评审总结报告 评审什么？由谁评审？结论是什么？ 评审总结报告是项目历史记录的一部分，标识产品中存在问题的区域，作为行政条目检查表以指导生产者进行改正。 评审指导原则 ⑴评审产品，而不是评审生产者。注意客气地指出错误，气氛轻松。 ⑵不要离题，限制争论。有异议的问题不要争论但要记录在案。 ⑶对各个问题都发表见解。问题解决应该放到评审会议之后进行。 ⑷为每个要评审的工作产品建立一个检查表。应为分析、设计、编码、测试文档都建立检查表。 ⑸分配资源和时间。应该将评审作为软件工程任务加以调度。 ⑹评审以前所做的评审 质量保证 IES 规约不完整或规格说明错误 MCC ；未理解用户意图 IDS 故意偏离规格说明 VPS 违背编程标准 EDR 数据表示有错 ICI ；构件接口不一致 EDL 设计逻辑有错 IET ；测试不完全或有错 ⅡD ；不准确或不完整的文档 PLT ；设计的程序设计语言翻译错 HCI ；不清晰或不一致的人机界面 MIS ；杂项错误 按严重，一般和微小级别统计各类错误的次数所占百分比，以及所有错误的数量及百分比。例如，建立一张类似如下的表格。 然后考虑“重要少数”的错误指标，提出改进意见。 根据软件过程中的每个步骤计算错误指标 Ei = 第i发现的错误总数 Si = 严重错误数 Mi = 一般错误数 Ti = 微小错误数 PS = 第i步的产品规模(LOC，设计陈述，文档页数) Ws，Wm，Wt分别是严重，一般，微小错误的加权因子，推荐取值，Ws=1，Wm=3，Wt=1 软件工程在过程的每一步中，计算各阶段的阶段指标 PIi = Ws（Si / Ei）+Wm（Mi / Ei）+Wt（Ti / Ei） 错误指标 Ei= ∑（i×PIi）/ PS =（PI1 + 2PI2 + 3PI3 + … + i*PIi）/ PS 错误指标与上面表格中收集的信息相结合可以得出软件质量整体改进指标。七、质量保证与检验 确保每个开发过程的质量，防止把软件差错传播到下一个过程，因此，检验的目的有两个： ⒈切实搞好开发阶段的管理，检查各开发阶段的质量保证。软件质量保证 2．预先防止软件差错给用户造成损失。 检验的类型有： ⒈供货检验：对委托外单位承担开发作业，而后买进或转让的构成软件产品的部件，规格说明，半成品或产品的检查。 ⒉中间检验 / 阶段评审 目的是为了判断是否可进入下阶段进行后续开发，避免将差错传播到后续工作中。 ⒊验收检验： 确认产品是否已达到可以进行产品检验的质量要求。 ⒋产品检验： 判定向用户提供的软件产品是否达到令人满意的程度。 项目内容 需求分析 需求分析→功能设计→实施计划 检查：开发目的；目标值；开发量；所需资源；各阶段的产品作业内容及开发体制的合理性。 设计 结构设计→数据设计→过程设计 检查：产品的计划量与实际量；评审量；差错数；评审方法，出错导因及处理情况，阶段结束的判断标准。 实现 程序编制→单元测试→集成测试→确认测试.检查内容除上述外，加测试环境及测试用例设计方法。 验收 说明书检查；程序检查。 ⒈3质量保证实施 软件质量评价标准。 ⒈质量需求准则：着眼点是是否满足用户的要求 ⒉质量设计准则：开发者在设计实现时是否按软件需求保证了质量 ⒊质量度量准则：为质量度量规定了一些检查项目： 精密度量：根据质量度量准则进行详细度量 全面度量 简易度量 五个实施步骤 ⒈Target：以用户需求和开发任务为依据，对质量需求准则，质量设计准则的质量特性设定质量目标进行评价。 ⒉Plan：设定适合于待开发软件的评测检查项目，一般设定2—3个。 ⒊DO：在开发标准和质量评价准则的指导下，制作高质量的规格说明书和程序。 ⒋Check：以Plan阶段设定的质量评价准则进行评价，算出得分，以质量图的形成表示出来，比较评价结果的质量得分和质量目标看其是否合格。 ⒌Action：对评价发现的问题进行改进活动，重复Plan到Action的过程直到开发项目完成。 ⒈4软件可靠性 可靠性统计定义： 在给定的环境和给定的时间间隔内，按设计要求成功运行程序的概率。 二、软件可靠性的主要指标 MTBF ——平均故障间隔时间 MTTF —— 平均故障时间 MTTR ——平均修复时间 MTBF = MTTF + MTTR 软件可用性是指在某个给定时间点程序能够按照需求执行的概率。 可用性 = MTTF /（MTTF+MTTR）×1% ⒈5 ISO9 质量标准 ISO9是指质量管理体系标准，它不是指一个标准，而是一族标准的统称。ISO9是由TC176（TC176指质量管理体系技术委员会）制定的所有国际标准。ISO9是ISO发布之12多个标准中最畅销、最普遍的产品。 ISO（国际标准化组织）和 IAF （国际认可论坛）于28年8月2日发布联合公报，一致同意平稳转换全球应用最广的质量管理体系标准，实施ISO91:28认证。 2版ISO 9族标准包括以下一组密切相关的质量管理体系核心标准： ⑴ISO 9《质量管理体系结构 基础和术语》，表述质量管理体系基础知识，并规定质量管理体系术语。 ⑵ISO 91《质量管理体系要求》，规定质量管理体系要求，用于证实组织具有提供满足顾客要求和适用法规要求的产品的能力，目的在于增于顾客满意。 ⑶ISO94《质量管理体系业绩改进指南》，提供考虑质量管理体系的有效性和效率两方面的指南。该标准的目的是促进组织业绩改进和使顾客及其他相关方满意。 ISO9标准被很多国家采用，包括欧盟的所有成员，加拿大、墨西哥、美国、澳大利亚、新西兰和太平洋区域。为了注册成为ISO9中包含的质量保证系统模型中的一种，一个公司的质量系统和操作应该由第三方审计者仔细检查，查看其标准的符合性以及操作的有效性。成功注册之后，这一公司将收到由审计者所代表的注册实体颁发的证书。此后，每半年进行一次检查性审计。 ISO91是应用于软件工程质量保证标准。这一标准中包含了高效的质量保证系统必须体现的2条需求。因为ISO91标准，适用于所有的工程行业，因此，为帮助解释该标准在软件过程中的使用而专门开发了一个ISO指南的子集ISO9—3。 ISO91描述的需求涉及到管理责任，质量系统，合约评审，设计控制，文档和数据控制，产品标识和跟踪，过程和控制，审查和测试，纠正和预防性动作，质量控制记录，内部质量审计，培训，服务以及统计技术的主题。