软件工程第三次作业——关于软件质量保障初探
Q1: 对教材与参考资料阅读后关于软件质量保障你的体会是什么？
A: 首先了解一下什么是软件质量，根据IEEE认为符合用户以及利益相关者的需求，那么软件的质量又从程序质量和软件工程质量来看，软件质量又从软件功能的质量来体现，软件工程的又体现在，可见性，风险控制，成本，指标情况等，简单来说出来就是软件质量满足需求，还要满足盈利中造出足够好的软件,那什么是软件质量保障就是我们所说的QA,软件质量保障的工作无异于就是测试，但是这些还是不够的，读了质量保障以后说一下体会吧，虽然是专人专责，但是不意味着 某个模块出了问题，但是我没有责任，我就不管，项目毕竟是整体的，只要是项目的问题，我们就应该付出责任，也不应该盲目相信专业人士，应该根据我们的具体情况来，制定明确的责任人承担责任，采用高质量的测试用例
Q2: 如果你是一个项目的QA，那么你认为你的工作职责范围是什么?
A: 从项目需求阶段、设计阶段、研发过程、产品测试、验收几乎项目的整个生命周期都参与，需求设计阶段要审查设计时候合理，是否能满足客户的真正需求。是否符合客户群体的使用习惯，操作是否简单易学等等。数据库结构设计、系统架构、功能页面等是否能按照需求实现。另外，还要督促研发进度，要定好项目进度，并督促其完成。每个让都有惰性，没有人监督总会有延迟。产品出来了，QA还要检测质量，其实就是测试。通常QA手下有一组测试人员，负责产品测试。产品经过测试、修改，形成最终产品。此时产品可以交给客户了。产品到了客户那里，没有一个客户会一言不发欣然接受。总是提出这样那样的要求，这时候QA还要细心倾听客户的要求，耐心的给予讲解说明，汇总所有需要修改的点，反馈给研发人员（项目经理或研发经理）并确认其按照客户要求完成修改
总结：
-
qa应该懂开发，一个不懂开发的qa只能做流水线测试，而有些bug往往是测试不出来的。
-
qa必须了解需求项目中，qa的参与从需求开始。一个不了解需求的qa必然不是一名合格的qa.
-
qa必须了解项目的上下游的结构一个不了解上游的qa, 必然无法确定dev对上游的调用是否可靠；一个不了解下游的qa, 必然无法确定项目的实现是否符合下游的调用场景。
-
qa为整个项目的质量负责qa在项目中不是为找bug而存在的。
Q3: 如果你是一个项目经理，那么你认为这你的项目中需要专职的QA么？还是只需有Test即可？如果一旦出现问题，你如何界定由谁担责？
A：读了《我们需要专职的QA》后，一开始我也不敢说只需要QA或者只需要Test,我认为如果对于专职QA来说，他们只懂得用高级的工具进行流水线似的测试，但是不懂开发和原理，那么专职的QA对开发来说那就是一种累赘，不仅测试会生出许多的bug,甚至不是bug也会处理成bug让开发来进行处理，这就大大阻碍的工程的进度，还会在人际交往上产生隔阂，并且QA没有什么责任来承担，就像文中所说，项目即将上线了，出现了内存bug，本应该两个月之前应该告诉开发，却迟迟晚了两个月，如果这个时候，要是再有不太愿意上心的开发人员，那这个项目，我感觉质量啥的根本不用说什么保障了，在这个实例中，我感觉这个QA就是打酱油的，没有存在的价值，但是如果一个上心又有能力的QA，那会不会有就不太一样了呢，比如，促进项目的发展，节省项目开发成本，节省测试时间，按照我个人的观点来看，我感觉专职的QA我们不需要，我们只需要Test就可以了，让test每天跟进开发人员的脚步，而不是和以前一样只是，自己做自己的测试，完全不需要和开发人员进行协商，让开发和test各司其职，对项目共同负责，对项目责任进行划分，首先让开发首先进行自我测试，并且要注释明确，对于BUG进行等级划分，不能出现太多小的bug让测试来做吧，Test在进行测试的时候,如果在某个模块出现bug太多，如果说这个模块在以后的项目中，出现问题那么就由这个开发来负责，如果bug等级高，数量少并且没有被开发发现，后续过程中，test也没有发现，那这个责任由test负责，无论是谁负责，在项目中都应该尽职尽责，保证项目上线不会出问题。
