质量保证工程师
qa是质量保证工程师。qa是quality assurance的缩写，中文意思是质量保证，是指为了提供足够的信任表明实体能够满足质量要求，而在质量管理体系中实施并根据需要进行证实的全部有计划和有系统的活动。
qa即英文quality assurance的简称，中文意思是品质保证、质量保证。也就是品质控制员，是负责检验产品，控制品质的人。在职能结构中，各个职能部门设立自己的qa岗位，位于高级经理之下，独立于项目组。qa直接对高级经理负责，但业务上需要向项目经理汇报，属于项目成员。这种组织结构的优点是qa容易融入项目组，易于发现实质性的问题，解决问题也很快捷。
缺点是各职能部门相对独立，部门之间的经验缺乏交流和共享，还可能出现对过程、方法和工具研究的重复性投资。在这种组织结构下，由于高级经理专注于业务的发展，qa的职业发展容易受到忽视，难于接受到应有的培训和提升。
质量保证职位在公司组织结构中是独立于研发体系之外的，辅助高层管理人员对项目进行审计，它的工作成果会给整个研发团队提供信心，所以理论上是比较重要的，尤其在大公司。如果小公司的话，可以考虑质量保证人员身兼多职，比如：兼过程改进人员，或配置管理或测试等。
QA工作内容
在需求定义流程中，审查是更适合质量保证(QA)测试人员的角色，而不是定义;但QA测试人员需要学习如何高效执行审查。对于QA测试人员来主产，在于需求定义审查中成功获得支持关键在于，找到对于其它参与人员重要的问题，这就意味着找出需求内容相关的问题，避免投入过多的精力在形式和可测试性上。在我的书中，或相关的讨论坛中，我描述了许多方法来识别需求问题——包括清晰度和可测试性——以及如何使用强大的方法来检测出错误和疏忽的内容。
有些组织让业务分析师负责定义需求和开发测试，从而证明需求已经达到要求。这类双重角色常常会因为测试方法和知识的不足，而导致测试被忽略掉。另外，分析师的测试不可能显示他们需求问题。这类弱点也还会更严重，当开发人员是定义需求和测试的人时。
因此，让具备独立技能的测试人员定义和执行需求测试是有道理的。
让他们，与资深的分析师一同参与到需求发现行动中，如面试的利益相关者，这又是另外一回事了。
如果QA测试在需求和设计流程中参与的早的话，测试人员可以准备更多的测试，且当代码到来时，准备好开始执行他们。早期的参与者帮助确保需求是可测试的，并帮助QA测试人员更好地理解测试什么，然后编写更好的测试。
我已经警告过，仅仅取得接近需求的权利往往会事与愿违。更常见的是，QA测试人员在第一次尝试中并没有准备好做出高效地贡献。其它人也发现他们并有什么帮助，更糟的甚至他们有点碍事，然后把他们排除在需求审查之外。此外，这种不好的经验阻断了第二次返回的机会。主要原因是我称之为的“可测试性陷阱”;具有讽刺性的是，它是来自于QA测试权威的口中，他们说需求的主要问题是缺乏可测试性，进而在很大程度上是由于缺乏清晰度。
这样，当他们参与到需求审查流程时，QA测试人员更倾向于停留在引用他们认为所缺乏的可测试性的需求，然后期望分析师们重写它们，使之更加可测试性。分析师鲜少有时间，也很少有兴趣重做他们的工作;而其它审查者常常认为这类对可测试性的抱怨是无关紧要的。它们也被忽略了，这些参与者不仅没有增加价值，还干扰了有用的评论。
