你好 我叫Dasha，我正在iOS上测试2GIS移动应用程序。 我想分享我们进行功能的过程，这不仅可以节省时间，而且可以提高我的个人技能。 阅读文章以了解我们如何在相同的背景下保持产品，设计师和开发的成功。 我们相信，所有感兴趣的人对第一次测试程序的复习确实会使生活变得更轻松。 沟通是管理功能的关键。
我们的痛苦
当与其他公司的测试人员交流时，我经常注意到测试他们的功能有些混乱且没有结构。 因此，浪费时间，参与开发的人员的力量。 人们开始生气，开始讨厌同事，在门廊等他们。
以前，我们也有类似的事情：在计划sprint时，一个任务飞了进来，在sprint的开始阶段将其带入开发阶段，我们已经在流程中制定了任务。 如果对与其他团队的互动有疑问，我们去了产品。 经常发生的情况是，有些团队的工作已经全面展开：每个人都期待发布，有人已经梦到了战斗中的功能。 而其他团队甚至都不知道它的存在。 这样的过程是无效的，花费了大量的时间/精力，带来了混乱。
结果，他们意识到不可能那样生活，并开始建立新的流程。 他已经帮助拯救了某人的神经，甚至挽救了生命。
关于团队
我们的团队包括：9个开发人员，6个测试人员，一个产品和一个设计师。 在计划迭代时（未来4个月我们将要做的事情），将编译要在当前时间段内发布的功能。 编译列表后，开发和测试团队将为每个功能分配一个功能，该功能将自始至终。
对于我们来说，有特色的人就是一个拥有从传统知识到发布的特色的人。 他具有有关整个功能发生了什么的最新信息，并且是有关为其他团队的人员使用功能的问题的切入点。 您可以在
Sasha Kartavtsev的
报告结尾处了解有关功能的更多信息。 记住这个术语，那么将会发现它不止一次。
分9阶段发行
释放功能的整个过程可以分为9个主要阶段。 为了清楚起见，我们采用了最近发布的“奖励”功能，并告诉我们如何在所有9个阶段进行操作。
奖励是对用户对产品的贡献的奖励。 用户可以通过撰写评论，上传照片，将新公司添加到目录中来获得他们。 可以在“我的2GIS”选项卡上看到它们。
阶段1-传统知识开发流程
在开始设计功能之前，我们在闲暇时创建了一个聊天室，并打电话给其中的所有人员。 我们同意在其中讨论可能影响发布过程的聊天参与者生活中的所有功能和事件。 不必说您去喝牛奶，但您需要谈论假期/病假，否则您可能会因反应迟钝而遭受仇恨。
首先，基于其他功能的经验，开发和测试的功能着眼于传统知识/设计，常见问题和改进建议。 对该功能进行了监视，以便在一天内回答问题。 如果最后期限被延迟，那么这些家伙会向产品/负责人暗示时钟正在滴答，已经很高兴回答了。
当所有主要问题都已解决，有最终设计，开发对功能的实现没有疑问时，就可以认为传统知识的开发过程已完成。
在第一阶段，制作功能原型并在TK开发中使用它非常酷：它将有助于感觉设备上的功能并在早期阶段识别缺陷，并提供测试用例。 产品甚至可以在平台上开始开发之前就对逻辑进行更改。
第2阶段-拟定清单
在制定ToR（作为测试功能）的过程中，我在TestRail中为该功能组成了测试用例，然后根据该用例对功能进行了检查。 优先考虑案例以进一步实现自动化。 由于该功能中有一个后端，因此我在测试计划中添加了对它的检查：我们发送了哪些字段，我们收到了哪些字段，如果这里有些不可理解的废话会发生什么。 让我们将完成的清单提供给开发人员和产品，以同步对功能的期望，这样就不会发生测试认为一件事，产品期望另一件事，而开发人员又做了其他事情的情况。
第三阶段-开发
在开发ToR之后，功能的开发就开始了。 当时的测试在ToR和聊天室中关闭/辩论了未解决的问题，通知了开发人员所有变更的出现（如果有的话）：新要求，新设计，新文本，其他任何内容-开发人员应该了解所有内容，否则无法避免争执。
阶段4-审查第一个功能部件
收到第一个程序集后，我们将其放入功能聊天中，在此我们呼吁产品和设计师进行审查。 测试控制着查看装配并获得了反馈-速度越快越好。 这是在早期阶段完成的，因此以后不会出现不愉快的情况。
令人不快的情况的例子您晚上在家安静地坐着，请勿触摸任何人。 您认为一切都已落后，明天该功能将投入使用。 但是在凌晨1点，有一件邪恶的商品突然冲进您的家中（这是真实的，因为她住在我的三层楼上）或设计师（已经不那么真实了，他住在我身边，但是他有车），并要求紧急修复字体/颜色/填充，否则“请勿发布！ 您不能那样出去，”而PR公司已经被概述了，就是这样，这一切都将一the不振。 现在您早上两点坐下来，打电话给开发商，开始购票。 通常，及时从正确的人那里收到反馈很有价值。 从一开始就获取它不会使您收紧该侧面的释放。
阶段5-平台测试
在检查第一个程序集的同时，还使用先前编译的测试用例在平台上开始了测试。 在测试过程中，如果您发现有可能破坏发行版的问题，或者意识到可以做得更好，那么他们会在聊天中添加功能或在工作声明中留下评论。 我们确保问题没有悬而未决。
在同一阶段，功能的逻辑发生了变化（例如，UI）-它们还将组件交给产品和设计人员进行审查，以确保期望与现实相符。
阶段6-整合测试
如果除手机以外的其他团队参与此功能的开发，则此项是必需的。 例如，手机+后端。 如果我们替换图标的字体或颜色，那么当然不会进行任何集成。 但是，在我们的Rewards示例中，涉及一个后端-集成是必不可少的。
首先要做的是在Confluence停靠码头。 通常，首先由一个人执行此操作。
该文件规定：
-开展日期；
-参与者-以便团队通过视线了解英雄，而英雄无法反驳这一事实；
-支票清单；
-案例清单-验证具有特定条件的方案。
编译好扩展坞之后，我将其放入功能聊天室，并呼吁所有集成参与者来审查/补充案例。
在第十天，集成参与者聚集在一个办公室中，并从集成坞中检查了所有方案。 与后端团队进行联合集成非常好-您可以立即解决所有问题并弄清所有奇怪之处。
阶段7-支持简报
在发布之前，他们告知支持人员该功能即将发布，是时候准备好了。 大理读TK，p组装。 他们报告了要写哪些聊天以及如果从用户那里收到反馈，应该与谁联系。
阶段8-发布
我们开始推出该功能，并通知聊天，并同时观看了Crashlytics，商店中的反馈和支持。 我们希望有最好的喝缬草。 有了Rewards，一切都进展顺利，但是我们准备好立即进行修复，并在发布过程中通知大家是否在平台方面发现了严重的错误。
阶段9-发布后对功能的支持
功能进入战斗后，我们的角色变成了信息人员：他们回答了传入的问题，提示，解决了一些平台问题，或者，如果他们知道问题出在后端，则将其继续下去。 发布之后，我还将“奖励”支票中的案件倒入测试记录中的主案件存储中，以便将来可以重复使用。
如果简短
- 始终保持每个人都在相同的上下文中。 报告重要更改。
- 具有功能的装配体出现后，请所有感兴趣的各方组织对第一个装配体的审查。
- 如果在任何阶段功能逻辑发生变化，请同时进行审核。
- 得到答案：写字，打电话，踢脚，直到您回应为止。
- 准备对新功能的支持，并在启动后提供帮助。
我在此过程中获得的知识和经验对我的工作和生活都有帮助。 我激发了沟通，独立性，责任感，使自己沉浸在产品中，超出了我们团队的工作范围。 顺便说一句，车队也很高兴-如果是fakap，他现在喝的是酒，而不是缬草。