软件工程第三次作业——关于软件质量保障初探
（1）对教材与参考资料阅读后关于软件质量保障你的体会是什么？
我也希望开发者一开始就了解用户的需求，完美的分析文档入高屋建瓴般流出，软件工程师在此基础上开发了各种完美的功能，按时交付给用户，用户一看就特别满意......但我们都知道现实的工作过程远远没有这么浪漫。现实就是“代码太乱，全部推倒重写后，结果同事却说：你看到的就是你前任重写过的”。这样的情节。 QA、 Test、Dev……一大堆同事相爱相杀………..
一款软件开发的过程往往都很漫长，“需求分析——设计——实现——发布——运营维护——退役”过程冗长得就像就像一朵花从种子的受授粉到下一代的花朵在苗圃中盛开。 软件的质量保障也不是一个人的事情，需要每一个人都要努力做好，需要奋不顾身地加班，头直到顶越来越清凉......但不管你是这个精密的仪器中的螺丝钉还是齿轮，都要做好分内的事情，尽自己最大的努力。
（2）如果你是一个项目的QA，那么你认为你的工作职责范围是什么？
职责一、了解你要审查和测试的内容
古人云：知己知彼，方能百战百胜。我认为，要测试一个软件编写得是否合格，就要明白如何编写这些代码。不然只站在外行的角度来评测别人的成果，会给双方都带来不必要的麻烦。
职责二、具备良好的沟通能力，及时且清晰地将问题与发型很清凉的程序员沟通。
良好的沟通能力是团队合作的关键，作为一个“反馈机制”这一点尤为重要，如果你能够发现问题，却不能表述清楚问题的细节，恐怕你的队友又要多掉几把头发了。及时沟通也很重要，第一时间反馈问题能够避免后期赶工的加班。
职责三、将对项目的干预控制在职责范围内
QA的职责是发现并反馈错误，而不是对着项目指手画脚，定义和实现的过程都有专门的部门负责，所以，尽量不要越俎代庖，不然可能越忙越乱。
（3）如果你是一个项目经理，那么你认为这你的项目中需要专职的QA么？还是只需有Test即可？如果一旦出现问题，你如何界定由谁担责？
我认为一个项目在交付之前需要进行大量且全面的测试，但不需要专职的QA。test是必须的，而且执行test的和写下这些代码的是同一批人，没错，同一批人。也就是说，在代码的编辑整理结束之后，相人员直接转入测试阶段，谁负责开发哪里，谁就负责哪里的测试，谁就承担哪里的责任。有问题部门内沟通解决，既节省了部门对接的时间消耗，又能够更加快速全面地解决问题，最重要的是，这种运行模式可以把责任精准地分配到个人头上，也解决了产品出现漏洞后的追责问题。
我们试想一下，如果一个QA团队不懂开发，那么对底层程序员来说简直是一场灭顶的灾难，就像甲方经常会提一些奇奇怪怪的问题，比如 “根据手机壳的颜色自动更换壁纸、”“五彩斑斓的黑”和“把图像翻过去，我要看背面”等等。不用细思考就知道以目前的科技水平这根本就不可能，但你还要浪费口舌和他解释。这些看似专业的人员实际上只是增加了研发的时间以及人力、物力成本。或者这些专职的QA对开发有一定程度的了解，那么与其养着一群懂开发，但从不开发的人才，而且是只在项目接近尾声时才使用的人才，那么不如让负责开发的人才直接转入测试，既节省了人力资源，又避免了一系列的问题。
分工明确会增加效率不假，但仔细观察这类的文章你就会发现，这种文章举出的例子基本上都是在流水线上，而软件开发相比流水线更加扁平化，也更加复杂，每一个模块的代码都不同，也没有具体的数字和条条框框标准来说明，多少行以上的就一定是好代码，即便是覆盖率也不能，因为程序里很多的语句是用来处理种种异常的，这些情况大多都不会发生，但是如果这些语句未被覆盖的话，这个模块的代码覆盖率就会下降，就很有可能打不到预期的覆盖率。唯一能够衡量一款软件好坏的只有四个字——用户体验，这四个字还模糊到不行。所以，综上所述：专职的QA是没有必要的，我们需要的更多的是更精更全面的人才。