一、关于软件质量保障的体会
1、软件质量好坏的定义：软件质量的好坏主要是指是否能满足用户的需求。所以软件质量保障主要围绕“客户”这个核心。代码阶段：要写出实现客户需求的代码，开发软件阶段:在满足客户需求的基础上最大程度的降低风险和成本，测试阶段：测试软件是否存在不满足客户需求的Bug。
2、关于软件质量保障的大体概念：软件质量保障包含很多方面，初步的代码程序的质量、软件工程的质量、软件测试、以及后期软件的维护，细小且繁杂的很多方面构成了软件质量好坏的决定性的因素。所以软件质量的检测也不是独立单独进行的，从开始的对于程序代码的准确度、覆盖率的综合指标、到对软件开发过程的对于风险的控制、成本的控制、内部软件质量指标的完成情况，到最后的软件测试，与其说他们是软件质量保障的步骤，不如说每一步都并行且相互包含。
3、软件质量保障的具体步骤划分：
首先 软件=程序+软件工程
可得 软件质量=程序质量+软件工程质量
（1）程序质量的保障：要通过多维度特性的综合指标来衡量，不同的软件需求不同所以综合指标也不相同。
（2）软件工程质量的保障：实施CMMI
二、如果你是一个项目的QA，那么你认为你的工作职责范围是什么
-
1.负责开展公司项目的软件质量保证工作。
-
2.实时了解项目的进程，多与开发人员进行沟通与交流。
-
3.制定项目的质量保证计划，并按计划实施 QA 活动，定期报告项目情况。
-
4.推动项目开发过程中可靠性活动的开展，确保交付产品运行稳定、可靠。
-
5.对产品的修改过程进行监控和指导，确保修改过程可控，质量可靠。
-
6.从上述活动中提取流程改进要求，推动过程的持续改进。
-
7.参与内审，发现体系改进点，与测试人员一起监测工程质量。
-
8.参与软件测试，文档编写。
三、如果你是一个项目经理，那么你认为你的项目中需要专职的QA吗？还是只需有Test即可？如果一旦出现问题你如何界定由谁负责？
1、首先谈一下QA和Test的区别和联系。
Test：运用一定的流程和工具，验证软件能够实现预先设计的功能和特性，特指验证代码的行为是否符合功能规格说明书 (spec) 的规定工作的流程和结果通常是可量化的。
QA：运用各种手段, 在软件工程的各个阶段确保软件的质量能帮助软件团队实现目标，是软件团队为了让软件达到事先定义的质量标准而进行的所有活动，包括测试工作。
在这样的定义下，Test其实可以说是QA的一个真子集。
2、对于QA：
我认为专职的QA是非常有必要的
QA是整个软件工程的质量保障，QA要求贯穿过整个产品（或项目）的整个过程，对整个过程进行监督，对项目的目前进度进行检查，同时还要完成组织验证、组织过程定义、风险管理等相关过程。每个过程结束，都要求进行阶段工作的整理，这种管理定量化的，成功与失败后，进行原因的分析，同时进行知识库的积累，以提高后继产品的质量。所以QA在一款软件上的质量保障是必不可少的。
3、对于Test：
我觉得设专职Test是没有必要的
（1）因为QA是包含Test的，如果有QA，就没有必要再设专职的Test
（2）谈谈关于Test存在的一种误解就是：所有的监管测试Test的工作是在整个工程的最后进行的。其实如果是这样的话是远远不够的，当在项目后期发现了问题，问题的根源往往是项目早期的一些决定和设计，这时候，再要对其进行修改就比较困难了。其实这要求测试人员从项目开始就要积极介入，从源头防止问题的发生。由此，我i觉得Test的工作是不可以独立出来的，无论是在软件工程的初期（代码程序的编写）还是中后期的软件设计等进程中，Test的监测都是必不可少的。所以如果要避免后期监测出来的漏洞在后期修补的时候会连着整个前期的东西的矫正，就要从Test在进程初期一直伴随到进程结束。如果这样的话就不如在一开始就由开发人员担任这项工作。所以这就是第一个原因，因为Test监测应该贯穿整个工程。
（3）第三个原因就是参考资料主要谈论的问题，“不懂开发的人必然做不好测试”。因为没有人比开发人员更了解整个软件工程，在发现漏洞的时候也没有人比开发人员更快的找出问题所在，并找到解决的办法.
（4）第四个原因就是，书上质量保障这一章提到的：出现问题之后，开发人员和Test人员之间责任的推诿，和分工明确会造成画地为牢导致的局部最优和全局未必最优的情况。
4、出现问题之后责任的界定
首先作为项目经理，没有及时发现问题，很大一部分责任在我。我会反思自己在整个工程期间的工作，是因为自己没发现潜在问题还是出现了本不该出现的问题，若是前者，我会承担自己作为项目经理未做好本职工作的责任，若是后者，我会具体情况具体对待，细化究竟是哪个进程出现的问题即由哪个进程的负责人和我一起担责任。我觉得项目出现问题不会一个人的主要责任，同负责一个项目，应该一起面对所有的问题。