问：对教材与参考资料阅读后关于软件质量保障你的体会是什么？
软件测试在整个软件生命周期中的重要性使其存在于整个项目周期，这个环节在整个项目中占了很大的比重，能主导整个软件项目的走向。质量这个关键词对于企业来说究竟有多重要自然不必多说，轻则关乎到软件的最终运行状态和结果，重则直接影响到企业形象，不会有任何人相信一家质量不过关的企业，那样做无异于自寻死路。
软件测试如果能存在软件开发的整个周期中，可对软件开发过程中存在的风险作出及时规避，减少工程在时间和金钱上的消耗，还能让团队认识自己身的不足之处，并加以改进，避免在同一个坑中掉进去两次，更能挽回不少企业的损失。
引用书中关于软件质量的一句话：
Capability of software product to satisfy stated and implied needs under specified conditions.
谷歌翻译为：
软件产品在指定条件下满足陈述和隐含需求的能力。
而“程序的质量”和“软件工程的质量”如何影响软件的质量，就像这样一条公式：
软件质量 = 程序质量 + 软件工程质量
1） 软件在开发过程中通常有三个特性：“好”，“快”，“便宜”。
结合现时软件工程可理解为“在实现软件需求者需求的全部软件功能并将功能做到足够好后，在软件在正是运行时，存在最少的软件问题等的前提下，控制成本和时间达到最小的消耗，将这几项控制在一个相对最好的平衡的点上”。
以上这些就引出来一个问题——软件质量：
什么是质量，如何来衡量？
比如衡量一个搜索引擎的质量，业界通用准确度和覆盖率的综合指标来表示。网站查询结果的速率，订票网站能并发处理业务的吞吐量，支持同时在线人数的数量。等等许多衡量标准。
2） 软件工程的质量体现在以下方面：
3） 软件工程的质量如何衡量：
这里引入一套比较成熟的理论——CMMI（Capacity Maturity Model Integrated，能力成熟度模型集成）。
4）软件质量的成本：
问：如果你是一个项目的QA，那么你认为你的工作职责范围是什么？
1）什么是QA：
QA（QUALITY ASSURANCE，中文意思是“质量保证”），其在ISO8402：1994中的定义是“为了提供足够的信任表明实体能够满足质量要求，而在质量管理体系中实施并根据需要进行证实的全部有计划和有系统的活动”。有些推行ISO9000的组织会设置这样的部门或岗位，负责ISO9000标准所要求的有关质量保证的职能，担任这类工作的人员就叫做QA人员 。（来自百度百科词条解释）
2）工作职责范围：
QA的重要工作是预防、检查与改进来保证软件质量。QA的工作是软件生命周期的管理以及验证软件是否满足规定的质量和用户的需求。
综上如此，QA需要很多对应其专业的能力，这也是成为一名合格QA所要做的职责范围，不然绝不是一个合格的专业人员。
问：如果你是一个项目经理，那么你认为这你的项目中需要专职的QA么？还是只需有Test即可？如果一旦出现问题，你如何界定由谁担责？
需要根据企业实际情况出发分析QA是否需要，而相应的技术人才又从何而来。
有这么一说，测试团队是否真的有存在的必要，这要看情况。如果从事的工程太小，可能就是自己给自己做的。无知，对软件工程几乎一窍不通的团队，采用一窝蜂的开发方式。人手不够，一人干两件事情甚至更过事情，恨不得长出来三头六臂。
还有其他一种与上面相对立的情况出现，前面时比较弱的小企业，甚至是不到十人的小工作室。但是如果是大神或者是拥有强大雄厚资金的帝国企业，那么情况就另一种情况。
人太牛：高德纳认为排班软件不如他意，所以自己动手写一款自己的专属软件，他对其中的代码和原理了如指掌，哪里出错会第一时间更改。然而有多少这样的神级人物存在？即使存在，他们在大型团队中也能运筹帷幄，不用担心大问题的出现。
工程太小：前前后后代码加起来不超过千行，而且和前面大神相同，我只自己私用，管理起来更加轻松。但有局限性，软件只能自己这一个小圈子使用，出不去。
还有类似于Facebook的成熟经验
公司的员工都在频繁使用他们自己开发的软件，相当于我们每个人都是测试人员，每一次操作之后还有LOG日志文件作为记录。平台还提供BUG反馈入口，千万亿用户自动成为了测试一员。
Facebook作为一个平台，自然后又第三方厂家想要以此为基础开发自己的程序，他们更加专业，更容易找到问题。
群众力量的作用之下更容易找到问题所在，这样一来，测试部门的作用自然减少了。
可这仅仅只针对特殊企业，这种成功是很难被复制的。那么针对普通的企业或是团队，他们还是需要QA的。可不能谁都能当这个QA，门外汉自然是首先拒之门外的，让一个不懂软件工程的人测试，最高也就黑盒测试，可这又是没有多少技术含量的职业。
最好是从本团队中提拔，在团队中工作有段时间的员工最好。他们更容易理解团队代码风格，能第一时间找到问题所在，与开发团队有很强的默契性。然而团队还需要一个并不是本团队提拔上来的专业QA，这名QA对代码自然有一定基础和经验。因为当代码风格确定后，团队内部的人员会产生我这样写是正确的的迷惑性想法，造成错误不断累加。
这个时候团队分工体现出来，细分每个团队下每个部门的职责，在保持自身独立运行不受外界干扰的前提下，与周围团队密切交流，不断取长补短，实现一个统一的流水线一样的开发环境。一旦哪里出错，可以很快找到问题根源，及时作出更改。