软件工程第三次作业——关于软件质量保障初探
一：对教材与参考资料阅读后关于软件质量保障你的体会是什么？
(1) 质量是一个企业的代名词，质量都做不好，客户肯定会有不好的体验，并质疑你的能力。
(2) 对于大型的软件工程活动，如果前期版本到处挖坑，那么后期版本将会越做越痛苦，而且定位和解决问题所消耗的时间和金钱将会更多(这点感触颇深)。
(3) 从软件开发的角度来看，越早引入问题，带来的人力消耗和经济损失就越大，具体多大呢？据说有专门的团队研究过是成指数形式增长的(具体数字我不记得了，但是从切身体会来讲我是深信不疑的)，举个例子，如果开发阶段，引入一个和其他地方关联性比较强问题，一直没被发现，然后几个版本之后发现，那么可能很多代码都是基于这个错误的逻辑继续开发的，到时候修改起来，很可能会牵一发而动全身。再比如，需求分析没做好，或软件架构设计不合理，开发完之后才发现，那代价就会更大。
• 在初始阶段（新项目，团队进入一个新领域，人员刚进入一个项目），每个团队成员都要尽量打通各个环节，多负责，把所有事情都搞懂，培养通才。
• 当项目/产业发展到一定阶段（进入阵地战的时候），要大力提倡分工合作，培养专才。同时，要把好的工具和流程集成起来，从每日构建，到基本功能的自动化，都要尽快实现。
• 把自己项目的架构和流程做好，让所有人都能比较容易地进行QA工作，这样，团队的“软件工程质量”才会有提高。
• 培养“大家都要做QA，专人负责量化的Test，有条件多做测试自动化”的文化。
• 要明白自己项目的特点，避免照搬别人的做法。不要听说某某伟大的项目的开发/测试比例是多少，因此就哭着喊着也要同样的比例。
• 如果一个团队是认真严肃地做软件，那他们一定要考虑如何保证程序的质量/软件工程的质量，以及达到这些质量，需要多少成本。
• 首先, 我相信有分工是好事, 软件团队中应该有独立的测试 (Testing) 角色。所有人都可以参与QA的工作 (报告bug 什么的), 但是最后要有一个角色对QA 这件事负责。 不但角色要独立，而且在最后软件发布的时候, 必须得到此角色的签字保证 （sign off）。
二：如果你是一个项目的QA，那么你认为你的工作职责范围是什么？
我认为QA是专门做测试的技术人员， 运用各种手段, 在软件工程的各个阶段确保软件的质量能帮助软件团队实现目标。具体包括：测试计划，测试案例设计，测试结果;QA：Quality Assurance，直译为质量保证。质量保证是质量体系中非常重要而又特殊的组成部分，质量保证的工作涉及软件研发流程的各个环节，且涉及到每一位参与研发的人员，但质量保证工作又不涉及具体的软件研发细节。
- 研发流程规范执行辅导（口头、电话、邮件、会议）。
-
检查研发流程规范执行规范，并识别出不符合项。
- 记录并跟踪不符合项问题的解决。
-
对软件产品进行测试看是否有bug，或者控制产品质量，使之更好。
三：如果你是一个项目经理，那么你认为这你的项目中需要专职的QA么？还是只需有Test即可？如果一旦出现问题，你如何界定由谁担责？
- 我觉得是不需要全职的QA的，甚至不需要QA这一专职角色或部门，因为，其是很多公司成立的专门做测试的技术人员，仅测试不开发。这些QA对于软件开发技术并不熟悉，甚至不懂。不懂开发的人必然做不好测试。就像不懂开发的研发经理必然管不好研发团队一样。QA是保证质量的，但是很多QA是在做测试，软件质量是测试出来的吗？如果不从需求分析，软件设计，代码实现上做好控制，到测试的时候你还怎么保证质量呢？如果你开发的东西自己在用，那么自己就是自己天然的QA，如果有别的团队也在用你开发的模块，那么，别的团队也就很自然地在帮你做测试了，而且是最真实的测试。开发人员本来就要测试自己写的软件，如果开发人员不懂测试，或是对测试不专业，那么这就不是一个专业的开发人员。那么既然开发人员就能做好测试，那么要专职的QA又什么用呢，况且只有了解了测试的难度，你才明白怎么写出可测试的软件，怎么去做测试的自动化和测试系统。只有自己真正去运维自己的系统，你才知道怎么在程序里写日志，做监控，做统计……只有自己去使用自己的系统，你才明白用户的反馈，用户的想法，和用户的需求。大多数的软件开发都是以小组的形式来进行的，每个人分配了一个模块，如果说每个人对自己的模块都进行一下测试，这样就完全不需要专职的QA了。所以我认为是完全没必要有专职的QA的。
- 经过细致的分工后每个人负责一块小东西，如果一旦出现问题我认为应该分版块谁的版块出了问题谁负责，哪个地方出了问题就找对应的人负责。
