团队应该如何安排QA 和测试工作
一、团队如何安排QA
（一）瀑布模式中的QA
在这样的环境中，QA们能做的事情非常有限。在需求开始时他们会参加需求澄清的会议，制定一些测试计划，然后进行测试用例的设计。有的企业会用诸如Excel之类的工具来记录这些用例。这些写在Excel里的，“死”的用例作用非常有限。而最大的问题在于：它们无法自动化执行。另外，在实际软件开发中，需求总是会经常发生变化，需求的优先级也会有调整，然后这些记录在Excel中的“死”的用例会很快过期，变得无人问津。
除此之外，QA中的有些成员会使用工具来录制一些UI测试的场景，然后在每个新版本出来之后进行回放。然而，当UI发生一点变化之后，这些自动化的用例就会失效：比如HTML片段中元素位置的调整，JavaScript的异步调用超时等等。
显然，这种单纯以黑盒形式来检查功能点的测试方式是不工作的，要真正有效的提升软件质量，仅仅通过事后检查远远不够，软件的质量也应该内建于软件之中。QA的工作也应该是一个贯穿软件生命周期的活动，从商业想法到真实上线，这其中的所有环节都应该有QA的参与。
（二）软件质量
1、软件需求是度量软件质量的基础。不符合需求的软件就不具备质量。
2、在各种标准中定义了一些开发准则，用来指导软件人员用工程化的方法来开发软件。
3、往往会有一些隐含的需求没有明确地提出来。
（三）软件质量保证策略
1、审查。
2、复查和管理复审。
3、测试。
（四）QA到底应该干什么？
本质上来说，任何软件项目的目标都应该是：更快地将高质量的软件从想法变成产品。
将这个大目标细分一下，会得到这样几个子项，即企业需要：
更大的商业回报（发掘业务价值）
更短的上线时间（做最简单，直接的版本）
更好的软件质量（质量内嵌）
更少的资源投入（减少浪费）
其实就是传说中的多、快、好、省。如果说这是每一个软件项目的目标的话，那么团队里的每一个人都应该向着这个目标而努力，任何其他形式的工作都可以归类为“浪费”。用Excel记录那些经常会失效，而且无法自动执行的测试用例是浪费，会因为页面布局变化而大面积失效的UI测试也是浪费，一个容易修复的缺陷要等到数周之后才被发现也是浪费。
QA在团队里的工作，可以分为两大类：
（1）确保我们在正确的交付产品。
（2）确保我们交付了正确的产品。
需求分析阶段，如果有QA的加入，一些从QA角度可以发现的有明显缺陷的场景，则可以在分析阶段就得到很好的处理。另一方面，尽早介入可以设计出更合理的测试计划（比如哪些功能的优先级比较高，用户会更频繁使用，那么对应的测试比重也会更高）。在Story分析与书写阶段，QA可以帮助写出更加合理的验收条件，既满足业务需求，又可以很好的指导开发。在和开发一起编写澄清需求时，主要是编写自动化验收测试，而不是实际编写业务逻辑的实现（虽然QA应该参与Code Reivew环节，学习并分享自己的观点）；甚至在上线运维阶段，QA还需要和OPs一起来设计用户数据的采集指标（比如用户访问的关键路径，浏览器版本，地区的区分等），从而制定出新的测试策略。
二、团队如何安排测试工作
1、各司其职，各尽其责。
通过激发测试队员的积极性充分发挥各自潜能，并培养团队协作氛围增加团队精神，工作上步调一致，来最大程度的发挥团队效能。不同测试阶段采取不同测试策略，例如测试过程中出现定位效应、审丑疲劳和同化现象可采取交叉测试来规避;鼓励创新，不断变化测试方法来提升测试效率;尽量让每个人做不同的事情减少重叠和内耗，在专长上面要有互补性，充分发挥各自特长。
2、参与需求分析流程
在需求阶段，测试员应抽空查看有关用户的需求，尽量多的了解用户到底需要什么。当实施部完成了用户需求的总结后，测试员应认真查看，让自己更了解这个软件，方便展开测试工作以及测试用例的编写。测试员在需求阶段的主要职责是确实了解用户需求;检查需求中是否存在逻辑矛盾的地方;检查总结是否完全覆盖用户需求。测试员在软件需求阶段就介入进去另外一个好处是:尽早的了解需求，这样以后测试中可以发现更多不满足用户需求的缺陷。
3、做模块测试策略和计划
确定需求后，测试员开始编写测试计划和测试用例，开始搭建所需的测试环境，熟悉软件的具体操作流程。
4、评审测试用例
测试员编写好测试用例后，召开开发人员一起开测试用例评审会，让开发人员了解测试员的测试点具体在哪里，如果测试员的重心不对，开发人员可以直接提出，一起商讨修正，另一方面也是让开发人员在开发完一个模块后，自己自测一遍，确认软件可以正常运行才送测，这样可以节省很多时间。
5、展开测试
开发人员认为自己开发的产品已经可以送交测试部门进行测试，测试部门接受到测试软件版本首先需要进行冒烟测试，-般为半天到一天。如果冒烟测试通过,进入正式测试阶段;否则退回开发部门(一般冒烟时bug数超过12个，可视为冒烟失败)。进入测试阶段，测试部门]按照事先写好的测试用例执行测试，缺陷通过缺陷管理工具经营管理以及与开发人员进行交付。每一轮测试结束后，测试员都应该编写buglist,这一轮的buglist也就是下一轮新版本测试的回归测试，每一轮新版本测试开展前都应该先进行bug回归测试。
6、发布软件
软件测试到比较稳定阶段后，即bug数低于2个并无严重缺陷，由测试员编写最后的测试报告并将报告提交给主管，由主管来做最后的软件发布工作。
小组成员：刘传雨、马杰杰、汪翔、王迎春、陶晨冉、沈骞