背景知识
最近，我的一位熟人QA工程师在一个缓慢的项目中工作了很长时间，严格地概述了她的职责，改变了工作并进入了一个新启动的项目。 在花了几天时间没有完成上述任务之后，并且很无聊之后，她带着“我该怎么办？”的问题去了管理层。 她收到了有意义的回复“组织您的工作”。 然后她陷入昏昏欲睡，“这是怎么回事？” 真的，如何？
几个月前，我自己换了工作，进入了一个以前从未进行过质量检查的英语项目。 该项目本身已经存在了很长时间。 经常发生的是，一家拥有大量资金的公司购买了一家拥有较少资金但拥有客户的公司。 结果，一家大公司获得了新客户，但市场上却少了一个竞争对手。 我的项目改变了管理和管理原则。
在与新团队见面的头几天，我听到伦敦办公室的一位开发商提出的一个令人困惑的诚实问题：“您将在这里做什么？”
实际上，进入这个项目并环顾了几天后，我像我的同事一样，一开始陷入昏迷。 不是因为我不知道该怎么办。 相反，我不知道该如何正确地扎根于这里已经建立的基础。 开发团队在没有测试人员的情况下生活得很好。 他们几乎每天都使用了看板（即连续交付的原则），无畏，冷静和自信地将其部署到生产中，即使在星期五也是如此。 所有这些都是因为它们具有出色的自动测试覆盖范围。 也许是我见过的最好的。 在查看彼此的请求时，他们会毫不犹豫地告诉对方要添加哪些自动测试。 当前更改的作者本人将其工作部署到了生产中，这意味着他对自己的工作负有全部责任。 尽管我确实参加了该项目，但他还是随身携带了它。在部署之前，很高兴听到我的意见。
但是，当然，该过程并不完美：碰巧的是，开发人员不了解需求，错过了错误，而且在客户方面，经常有一些问题需要采取措施。
面对确定我在团队中的职位的需要，我还去了领导层。 只是我们的对话方式与我朋友的对话完全不同。
质量保证工程师的工作安排
提出正确的问题。
这样啊 为了进行对话，我召集了项目的领导者和主要开发人员。 有一个很棒的管理规则，我当然不能忘记：表达问题，表达解决问题的选择，至少一个。
但是，我有两个问题，我不知道的答案。 从它们开始的最简单方法。
第一个问题。 组织的结构是什么，即谁负责谁，谁负责什么？理想情况下，公司应采用分层呈现的方案来说明公司的结构。 但是我并不理想，因此找出可以向谁提出哪些问题和建议的人很重要。
第二个问题。 该公司将QA工程师引入了该项目，他们对我有什么期望，担任这个职位的目标是什么？当答案非常明确时，它在很大程度上决定了工作的前沿。 以我为例，答案包含许多笼统的模糊短语，我认为它们是“按您的意愿做，但对我们而言一切都很好”。
至此，讨论的第一部分结束了。
我们讨论行动计划
讨论的第二部分，也许是最重要的部分，是我工作计划及其基本原理的介绍。 我需要得到上级的祝福，因为我可以不受阻碍地将自己和我的活动介绍给该项目。
令人欣喜的是，聪明的书和理论根本没有存在，所以我用准备ISTQB认证所获得的知识武装自己，一旦出于好奇，我读了有关测试理论和Scrum的书，就通过了十年的经验筛查并编写了一份试点质量检查策略项目。
在与管理层协商并得到他的全力支持后，他后来获得了公司正式文件的格式。 接下来，我想分享有关如何起草此类文档的想法。 他们形成了以前经验的精髓，并构成了当前项目的发展路径。
而且，也许我会以引号的形式以我的原始格式在此处转载一些片段：英语。 我相信对于每个质量检查工程师来说，制定这样的计划都是“如何组织工作”问题的关键答案
我们制定质量检查策略
1.质量保证概论
第一次提醒/引入“质量保证”一词。 相信我，您的团队中充满了非常模糊地想象这是什么的人。 可以
从Wikipedia借鉴很多一般定义。 从战术上表明，质量保证团队参与该项目并不意味着现在对工作质量的所有责任仅转移给他们：
测试是质量检查的一部分。 它使我们能够确定正在评估的功能的质量等级。
测试人员并不是执行质量检查的唯一责任。 整个团队可以并且应该做出贡献，以确保所交付产品和服务的高质量。
2.质量检查策略简介
准备更多的人会读到的东西。
测试策略是一份不断发展的文档，详细说明了我们将要确保产品质量的过程和方法。
听起来内容。 它可以只是目录，也可以是更多抽象的句子。 在这里，要提到测试方法，测试过程，测试自动化策略的存在以及对测试计划的需求。
这很重要。 指出修改本文档的时间间隔。 而且公司的项目和流程正在开发中，因此本文档不应变成恐龙。 因此，计划一个日期，在该日期您的策略将被审查和更改。 我认为，六个月就足以重新思考。
3.测试方法
什么是测试方法？ 与该定义的大量官方用语略有不同，我允许我将其简化为以下论点：这些是“我们每天开始使用的基本思想”。 在这里写下：您进步的动力是什么？
流派和运作良好的方法的经典是“主动的”和“基于风险的”。
我们将采用积极主动且基于风险的测试方法。
主动-这意味着应尽早开始测试设计过程，以便在创建构建之前发现并修复缺陷。
基于风险的-这意味着我们将以降低系统出厂时产品风险级别的方式组织测试工作。 根据ISTQB提纲，“基于风险的测试是指我们可以以降低系统出厂时产品风险的剩余水平的方式组织测试工作的想法。 基于风险的测试使用风险来区分测试的优先级并在测试执行过程中强调适当的测试，但这远不止这些。 基于风险的测试从项目的早期开始，识别系统质量的风险，并利用该风险知识来指导测试计划，规范，准备和执行。 基于风险的测试既涉及缓解措施，也包括提供缓解机会以减少缺陷（尤其是高影响力缺陷）的可能性的测试，以及偶然性测试，以识别变通办法，以使经过我们的缺陷不再那么痛苦。 基于风险的测试还涉及评估我们在发现和消除关键区域的缺陷方面做得如何»
当我们谈论主动时，我们首先必须谈论质量控制要求规范。 编制下一个开发周期要素规范的管理人员在大多数情况下，将其视为系统的普通用户，而开发人员思想的逻辑则存在于另一个维度。 首先，我不止一次地看到，开发人员在阅读规范时无法将其转换为编程语言。 例如，它不能使规范中提到的用户与系统中的现有角色/访问权限匹配。 结果，他可以选择自己认为最合适的角色，这将是错误的，并且必须返回功能以便以后工作并浪费时间。 或向经理问一个问题，经理可能正在休假，又在期待中失去了时间。 QA工程师是以用户为中心的经理和技术娴熟的开发人员之间的奇妙层，尤其是如果QA工程师不忽略白盒测试。 正是我们能够理解管理者并将他们的想法转化为开发者。 准时。
基于风险的测试具有评估项目风险和产品风险的有趣正式方法。 能够将它们付诸实践真是太好了。 但就我个人而言，我从来没有足够的时间来描述发生的可能性，后果的严重性等。 并按照所有规则计算风险。 在这里，我完全依靠自己的直觉和常识。 在测试或覆盖具有风险区域的自动测试时（应首先重点注意的是）：
- 直接设计的功能
- 相邻和相互作用的区域
- 商业上重要的功能
- 什么最经常发生
- 向后兼容（例如，如果更改了元数据格式，现有数据将成功运行）
4.测试过程
告诉我们您打算坚持的工作方法论顺序。 我没有发明任何复杂的东西，但是我
从ISTQB那里得到了灵感并加以运用。
如果您按照我的方式做，请熟悉ISTQB的作者推荐的工作顺序，并知道将采取什么步骤以及如何采取。 我们从计划和控制开始。 这两个人在一起生活是因为 在监视自己的活动的基础上，可以定期重新绘制计划。 接下来是编写文档和编写测试用例的工作，将其投入使用（使用计划的测试数据和适当的环境），完成测试并自行清理（删除临时文件等）。
我们将使用基础级ISTQB大纲中概述的测试过程：测试计划和控制，测试分析和设计，测试实施和执行，评估退出标准和报告以及测试关闭活动。
5.责任
确定您和他人在提高产品质量方面的责任。 报告您的任务。
首先，再次强调
每个团队成员本身就是一名测试人员 ，每个人都在测试与之相关的内容。 编写代码-测试它。
其次，明确并理解您的持续发展方向。
质量检查工程师是产品功能的首席专家 ：他知道如何工作，什么工作，能够解释如何以及需要测试什么。 他是预测客户运营行为的人，这意味着他不会允许出现严重问题。
第三，指出
您如何与经理和开发人员互动 。 例如，在“
三个好友”敏捷方法处停止
业务，开发和质量检查之间的协作
一个 业务-我们要解决什么问题？
b。 开发-我们如何建立解决方案来解决该问题？
c。 测试-怎么办，可能会发生什么
6.测试级别和质量保证自动化策略
今天，本节对我而言已成为一个独立的自给自足的文件。 但是，在团队中新生的质量保证流程的组织级别，请指出谁将执行哪种类型的测试。 将手动完成什么，将自动完成什么以及按照什么原理进行。 谁负责哪个自动测试。
例如，在当前项目中，我仅编写端到端测试，从业务角度来看，其流畅的操作在战略上很重要。 同时，我查看了开发人员的拉取请求，并在必要时就测试范围提出了建议。 其余所有（单元，集成，负载等）都是开发人员的工作。 在上一个项目中，负载测试由我负责，我与开发人员一起编写了集成测试。
7.功能工作流程
今天，我的项目使用两个星期的冲刺在Scrum上工作。 因此，我为每个故事提供了分步的书面生命周期文档。
无论项目采用哪种方法，都要逐步描述如何进行日常工作。 如果在上面我们更多地讨论了行动策略，那么应该清楚地表明首先是什么，然后是什么。
例如，我的版本是
下面的工作流程详细介绍了我们将在内部采用的流程。
1.在计划会议之前获取故事
2.根据验收标准和描述创建清单
3.注意不清楚的细节/问题
4.澄清有关计划的问题
5.更新清单
6.突出显示任何依赖性以及如何克服它们
7.当故事复审时，检查验收标准是否包含在自动测试中
8.鼓励开发人员通过自动测试来涵盖所有验收标准，或者自己动手做
9.当故事准备好进行测试时，请使用清单执行手动测试
10.为故事创建错误（如果存在）并将其返回开发
11.修复错误后，再次使用清单进行手动测试
12.检查是否通过了所有自动测试
13.创建一个任务，以在需要时实施其他集成自动测试
14.在QA通过状态下移动故事
8.测试计划
选择测试计划的类型，存储计划的平台以及其存在的目的。 提供任何人查看的方式。
在这个项目中，我的测试计划是每个故事的一组清单。 以当前的自动化水平，这已经足够了。
在之前的项目中，测试计划用于彻底的手动测试，并作为将来自动测试的思想基础。
如果您有大量的手动测试，请详细编写测试用例，以便任何新来的QA工程师进入项目后都可以独立执行它们。
如何处理文件
编写整个计划和有效的措辞非常酷。 毫无疑问，当局将不胜感激。 但是该文件的存在有一个重要意义。 这些是对谁的问题的诚实回答，为什么要写这些呢？
在写下每个句子时，最好考虑以下问题：
“我真的想这样工作吗？” ，
“我真的要在项目中实现它吗？”如果两个答案都是肯定的，请放心打印。
我认为，如果答案之一是“否”，那肯定是不挂不必要的职责的信号。
如果答案之一来自“我还不知道”系列，请暂时将其保留在您的页面上。
我有这样的时刻仍然留在几个月后将首先审查的清单上。
首先，我为自己写了文件。 我有些时候我会从描述的过程中退后一步，甚至与它们有些冲突。 适应这种情况以在此处和现在有效地使用资源是正常的。 但是绝大多数，以及通常的日常工作，我的文档就是我的指南。 我不止一次地确信，任何领域中的现有计划/策略总是能够更快，更轻松地比预期结果更接近期望的结果。 希望您轻松高效地开展工作！
在发布本身之前，这篇文章就大大减少了，对于我来说对于Sandbox来说，这似乎是一件痛苦的事情。 我将很高兴稍后继续讨论该主题。 尽管如此，我总是很乐意发展，如果有什么我完全忘记的事情，请给我写评论。
谢谢你