大家好！ 我叫朱莉娅，我是一名测试员。 去年，我向您介绍了百吉饼面包店（Bagel's） ，这是我们公司举办的旨在清理积压的bug的活动。 这是一个完全可行的选择，可以在一天之内将其显着减少（在不同团队中从10％减少到50％）。

今天，我想向您介绍我们的行李箱春季商店-BUgHunting（BUH）。 这次我们没有修复旧的错误，而是寻找新的错误并提供了功能方面的想法。 删减了有关此类活动的组织，我们的结果和参与者反馈的许多细节。

考虑并制定了规则之后，我们向公司Slack中的所有渠道发出了邀请，其中没有任何限制：

结果，开发人员和非技术专家都签了约30个人。 他们为该活动分配了整个工作日，预定了一间大会议室，并在办公室餐厅用餐。

怎么了

似乎每个团队都在测试其功能。 用户将向我们报告错误。 为什么还要举行这样的活动？

我们有几个目标。

1. 介绍那些与相关项目/产品接近的家伙 。
   现在，在我们公司中，每个人都在独立的团队中工作。 这些设计团队看到了他们的部分功能，但并不总是完全了解其他项目中正在发生的事情。
2. 只是互相介绍同事 。
   我们在莫斯科办公室拥有近800名员工，并非所有同事都亲眼所见。
3. 提高在开发人员的产品中查找错误的技巧 。
   我们目前正在推广敏捷测试，并朝着这个方向努力。
4. 不仅邀请技术专家参与测试 。
   除了技术部门外，我们还有许多其他专业的同事，他们想更多地谈论测试，如何正确报告问题，以便我们收到更少的“ Ahhh ...什么都不起作用”格式的消息。
5. 好吧，当然，要找到棘手且不明显的错误 。
   我想帮助团队测试新功能，并提供一个从不同角度审视已实现功能的机会。

实作

我们的一天包括几个街区：

• 简报；
• 关于测试的简短讲座，其中我们仅涉及要点（测试的目标和原理等）；
• 设置错误时的“良好方式”一节（ 此处对原理进行了详细说明）；
• 具有高级脚本的项目的四个测试会话； 在每次会议之前，都会有一个简短的介绍性演讲，内容涉及项目和向团队分发。
• 对事件的简要调查；
• 总结。

（我们也没有忘记会议和午餐之间的休息时间）。

基本规则

• 赛事注册是个人的 ，这解决了如果一个人决定不参加的话，将消耗整个团队的惯性。
• 每次会议时，参与者都会更换团队 。 这使参与者可以随时离开和走动，并且您也可以结识很多人。
• 每个会话之前由两个人组成的 团队 是随机组成的 ，因此结果变得更动态，更快。
• 根据严重程度，为受伤的虫子（从3到10）奖励积分 。
• 双打没有积分。
• 错误应由团队成员根据所有内部标准启动。
• Featurekvesta开始执行单独的任务，然后参加单独的提名。
• 审核团队会监控所有规则的遵守情况。

其他细节

• 最初，我想做一个“高级”测试活动，但是因为 非生产团队（SMM，律师，公关）中的很多人都签了字，我不得不大大简化内容并删除复杂/专业的案例。
• 由于Jira的部门在不同项目中的工作，根据我们的流程，我们专门制作了一个单独的项目，在其中我们设置了一个用于创建错误的模板。
• 为了计分，我们计划使用排行榜，该排行榜通过webhooks更新，但是出了点问题，因此必须手动进行计算。

在组织活动时，每个人都会陷入困境，为了让事情变得容易一些，我将描述您可以避免的问题。

一位演讲者突然生病，不得不寻找新的演讲者 。
我很幸运能在上午9点找到同一支球队的替补球员。 但是，最好不要依靠运气和多余的钱。 或者您自己准备好告诉所需的报告。

我们没有设法推出该功能，我们不得不交换块 。
为了不浪费整个块，最好有一个备份计划。

一些测试用户放弃了，我不得不快速重新创建新的 。
提前检查测试用户，或有机会快速建立测试。

简化格式的家伙几乎没有来 。
您无需强行拖拽任何人。 谦虚
有一个选项可以严格规定事件的格式：“业余” /“高级”，或者一次准备两个选项并决定要进行的操作。

有用的组织要点：

• 提前预定会议室；
• 安排桌子，不要忘记延长线和电涌保护器（一整天为笔记本电脑/手机充电可能不够）；
• 自动化计分过程；
• 编制评分表；
• 用测试用户的登录名和密码进行纸质讲义，使用Jira的说明，脚本；
• 不要忘记在活动开始前一周发送提醒，另外指出您需要携带的物品（笔记本电脑/设备）；
• 在演示中，晚餐时，喝咖啡时告诉同事有关该事件的信息；
• 同意devop在这一天不更新或推出任何东西；
• 准备演讲者；
• 同意功能所有者并编写更多脚本进行测试；
• 订购零食（饼干/糖果）作为零食；
• 不要忘记谈论事件的结果。

结果

一整天，这些家伙设法测试了4个项目，并获得192个bug（其中134个是唯一的）和7个带有功能请求的任务。 当然，项目所有者已经知道其中一些错误。 但是有意外发现。

所有参与者都获得了甜蜜的奖励。

获奖者是保温瓶，徽章，运动衫。

有趣的是：

• 在时间有限且您不能花很多时间思考的情况下，艰苦的会议形式对于参与者来说是出乎意料的。
• 我设法测试了台式机，移动版和应用程序；
• 一次查看许多项目，没有时间感到无聊了；
• 会见了不同的同事，研究了他们建立错误的方法；
• 感到测试人员的痛苦。

有哪些可以改进的地方：

• 减少项目数量，将会议时间增加到1.5小时；
• 提前准备礼物/纪念品（有时协调/付款持续一个月）；
• 放松一下，并接受一些事实，那就是出问题了，并且会发生不可抗力。

评论

系统管理员Anna Bystrikova： “行李店对我来说非常有用。 我学会了测试过程，感觉到测试人员的所有“痛苦”。
首先，在测试过程中，以近似用户的身份检查以下要点：戳按钮，转到页面，布局是否移出。 但是后来您了解到，您需要更加不规范地思考，并尝试“破坏”该应用程序。 测试人员的工作很艰巨，几乎没有“刺穿”整个界面的麻烦，您需要尝试跳出框框思考，并且要非常专心。
即使在活动结束后的某个时间，也只留下了积极的印象，我看到如何对发现的错误进行处理。 参与产品改进很酷^ _ ^。”

前端开发人员Dmitry Seleznev ：“在竞争模式下进行测试会极大地激发发现更多错误的动力。” 在我看来，每个人都需要尝试参加Baghanting。 研究测试使您可以找到测试计划中未描述的案例。 另外，不了解该项目的人可以就服务的便利性提供反馈。”

高级编辑Antonina Tatchuk ：“我喜欢尝试自己作为测试人员。 这是一种完全不同的工作方式。 您正在尝试破坏系统，而不是与它交朋友。 我们总是有机会向同事询问有关测试的一些信息。 我了解了更多有关优先考虑错误的信息（例如，我习惯于查找文本中的语法错误，但是此类错误的“权重”很小；反之亦然，在我看来不是很重要的事情后来被发现是已修复的关键错误） ）
在活动中，这些家伙从测试理论中挤出了一些心血。 这对非技术专业人员很有用。 几天后，我突然想到自己正在使用“什么时间”公式来支持另一个站点，并详细描述了我对该站点和现实的期望。”

结论

如果您想使团队的生活多样化，可以重新审视功能，安排小型“吃自己的狗粮” ，可以尝试举办这样的活动，然后我们可以一起讨论。

所有好的和更少的错误！