关于软件质量保障的体会
首先，软件质量保障的重要性不言而喻，书中说软件质量体现在以下方面
- 软件开发过程的可见性
- 软件开发过程的风险控制
- 软件内部模块，项目中间阶段的交付质量，项目管理工具的因素
- 软件开发成本的控制
- 内部质量指标的完成情况
有一套较为成熟的理论来衡量各个软件工程的质量——CMMI（Capacity Maturity Model Integrateg），即能力成熟度模型集合。
同时要达到一定的软件质量是需要付出一定的成本的，新功能的开发固然重要但是同时也必须要投入一定的成本来保证已有公的质量解决问题。这就是要各部门的人团队合作才能做到。
无论QA（Quality Assurance）还是Test都是在为软件的质量作保障，不应过分独立开来。明确的分工固然是重要的，可以提升工作的效率和质量但是我觉得"合作是分工的基础"，书中用足球来举例说明分工的重要性，说有专注进攻的，有专注防守的。但是不论进攻还是防守永远都是一个团队一个整体，竞技体育就更是如此了，其实你拥有世界上最优秀的前锋，最优秀的个人能力，也有可能被一个防守阵型弄的焦头烂额。同样，即使你的防守个人能力再好，也有可能被几个传切配合轻易撕破防线。团队协作是分工的基础，没有良好的配合分工只会无故平添烦恼，多增问题。邹老师在总结中有几个观点我觉得说的非常好：
- 在初始阶段（新项目，团队进入一个新领域，人员刚进入一个新项目），每个团队成员都要尽量打通各个环节，多负责，把所有的事都搞懂，培养通才。
- 当项目/产业发展到一定阶段（计入阵地战的时候），要大力提倡分工合作，培养专才。
只有当你对所有的工作流程都理解，才能在根本上意识到自己的岗位的精髓所在。QA（Quality Assurance）本身就包括Test，所以我觉得两者本身并不冲突不应将这两者完全独立。
如果我是一个项目的QA我觉得我的工作职责范围是：
我觉得一名优秀的QA必须是能全方位理解项目的从开发到测试都需要，不懂开发的人是必然的做不好QA的，同时其实无论QA（Quality Assurance）还是Test都是在为软件的质量作保障，不应过分独立开来。只要根本的了解开发，掌握开发，才能做好质量保障，同样的Dev也应该懂得测试，这两个种本身就是两个相辅相成的岗位，在良好和做的基础上才能建立明确的分工。
如果我是一名项目经理，我认为我得项目中不需要绝对的专职QA：
文章中有一句话说的是特别好的：
不懂开发的人必然做不好测试。就像不懂开发的研发经理必然管不好研发团队一样。我越来越觉得Dev应该应该是做测试最合适的人选，这必然是未来的趋势 （因为我已经看到了中国程序员的进步，相比起10年前，今天的程序员已经是非常全面了，再来十年，必然证明我的观点是对的）。
没错，不懂开发的人就是应该做不好QA，对一个项目本身的基础都不了解的人又凭什么可以去维护他的质量，作为一个QA可以不必对开发像大牛那么精通但是必须要有自己的理解，这就好比是在NBA优秀、传奇的教练员不一定是一个好的球员但是他一定对篮球本身有着很深的理解，有着自己的想法。所以我觉得不该存在绝对专职的QA，这样的QA即使能够工作也不会融入团队，做好各部门之间协调工作的。QA是保证质量的，但是质量并不是测试出来的，如果不从需求分析，软件设计，代码实现上做好控制。空有测试有何谈保证的只不过时发现BUG而已。关于QA和Test的问题上文我就已经提到了合作是分工的基础，无论QA（Quality Assurance）还是Test都是在为软件的质量作保障，不应过分独立开来。这也并不代表着就没人负责。团队是需要有负责人的，测试者本身就是一个合作的团队，出现问题是团队的责任，作为团队的负责人必须要为此负责，整理整个团队找出问题并解决。
2019-09-22 13:18:38