大家好！ 我叫 Yulia，是一名測試者。 去年我告訴你 巴戈德尼亞 - 我們公司舉辦的活動，旨在清理積壓的 bug。 這是一個完全可行的選擇，可以在一天內顯著減少（在不同團隊中從 10% 到 50%）。

今天我想向您介紹我們的春季巴戈德爾尼賽制 - BUgHunting (BUH)。 這次我們沒有修復舊的錯誤，而是在尋找新的錯誤並提出功能性想法。 剪輯下方有許多關於此類活動的組織、我們的結果和參與者的回饋的詳細資訊。

經過思考並寫下規定後，我們向企業Slack的所有管道發出了邀請，其中不包含任何限制：

結果，大約 30 人報名了——其中包括開發人員和非技術專家。 我們為這次活動安排了一個工作日，預訂了一個大會議室，並在辦公室食堂組織了午餐。

為什麼呢？

似乎每個團隊都測試其功能。 用戶向我們報告錯誤。 為什麼還要舉辦這樣的活動呢？

我們有幾個目標。

1. 介紹更接近相關項目/產品的人.
   現在在我們公司，每個人都在不同的團隊-單位中工作。 這些專案團隊正在處理自己的部分功能，並且並不總是完全了解其他專案中發生的情況。
2. 只需將您的同事互相介紹一下即可.
   我們的莫斯科辦事處有近 800 名員工；並非所有同事都認識彼此。
3. 提高開發人員發現產品中錯誤的能力.
   我們現在正在推動敏捷測試並朝這個方向培訓人員。
4. 不僅僅讓技術專家參與測試.
   除了技術部門之外，我們還有許多來自其他專業的同事想要更多地談論測試，如何正確報告錯誤，以便我們收到更少的消息，例如“啊......沒有任何效果。 」
5. 當然，也要發現棘手且不明顯的錯誤.
   我想幫助團隊測試新功能，並讓他們有機會從不同的角度查看已實現的功能。

履行

我們的一天由幾個部分組成：

• 簡報;
• 關於測驗的簡短講座，其中我們僅涉及要點（測驗的目標和原則等）；
• 關於引入錯誤時的「良好舉止規則」部分（這裡 原理有很好的描述）；
• 針對具有高級描述場景的項目的四次測試會議； 在每次會議之前，都會有一個關於專案和團隊劃分的簡短介紹性講座；
• 對事件的簡短調查；
• 總結。

（我們也沒有忘記會議和午餐之間的休息時間）。

基本規則

• 活動報名皆為個人報名，解決瞭如果一個人決定不去，整個團隊會因為慣性而流失的問題。
• 參與者每節都會更換團隊。 這樣可以讓參與者隨時來去，也可以認識更多的人。
• 命令 每次會議前兩個人 是隨機形成的，這使其更加動態且更快。
• 對於引入的錯誤，您將獲得獎勵 根據重要性評分（從 3 到 10）.
• 重複者不會獲得積分。
• 錯誤必須由團隊成員根據所有內部標準提交。
• 功能請求在單獨的任務中創建並參與單獨的提名。
• 審計小組監督所有規則的遵守。

其他詳情

• 最初，我想做一個“高級”測試活動，但是... 很多非產品團隊的人都報名了（SMM、律師、公關），我們必須大幅簡化內容並刪除複雜/簡介的案例。
• 由於JIRA中各個單元工作在不同的項目中，根據我們的流程，我們專門創建了一個單獨的項目，在其中設置了引入bug的模板。
• 為了計算積分，他們計劃使用通過 webhooks 更新的排行榜，但出了問題，最終不得不手動完成計算。

每個人在組織活動時都會遇到問題，為了讓您更輕鬆一些，我將描述您可以避免的問題。

其中一位演講者突然病倒，不得不尋找新的演講者.
我非常幸運，早上 9 點就找到了同一團隊的替代者）。 但最好不要靠運氣，有備用的。 或準備好自己提供必要的報告。

我們沒有時間推出功能，我們只好交換塊.
為了避免丟棄整個區塊，最好制定備份計劃。

一些測試用戶斷線了，我們必須快速重新建立新用戶.
提前交叉檢查測試使用者或能夠快速完成。

格式被簡化的人幾乎沒有一個來.
沒有必要強行拖曳任何人。 謙卑自己。
有一個選項可以嚴格規定活動的形式：“業餘”/“高級”，或者一次準備兩個選項，事後決定要舉辦哪一個。

有用的組織點：

• 提前預約會議；
• 安排桌子，不要忘記延長線和電湧保護器（為筆記型電腦/手機充電可能不足以一整天）；
• 自動化評分流程；
• 準備排名表；
• 製作紙本講義，其中包含測試使用者的登入名稱和密碼、Jira 使用說明、腳本；
• 不要忘記在活動前一周發送提醒，並註明您需要攜帶的物品（筆記型電腦/設備）；
• 在演示中、午餐時或喝咖啡時向您的同事介紹活動；
• 同意開發人員在這一天不要更新或推出任何內容；
• 準備演講者；
• 與功能擁有者協商並編寫更多場景進行測試；
• 訂購零食（餅乾/糖果）；
• 不要忘記告訴我們活動的結果。

Результаты

在一整天的時間裡，這些人成功測試了 4 個項目，並產生了 192 個錯誤（其中 134 個是獨特的）和 7 個功能請求問題。 當然，專案所有者已經知道其中一些錯誤。 但也有意想不到的發現。

所有參與者都獲得了甜蜜的獎品。

獲勝者是保溫瓶、徽章和運動衫。

結果很有趣：

• 參與者發現艱難的會議形式出乎意料，因為時間有限，無法花大量時間思考；
• 成功測試了桌面版、行動版和應用程式；
• 我們同時看了很多項目，也沒有時間感到無聊；
• 會見了不同的同事，研究了他們引入錯誤的方法；
• 感受到了測試者所有的痛苦。

可以改進的地方：

• 減少專案數量並將會議時間增加到 1,5 小時；
• 提前準備禮物/紀念品（有時批准/付款需要一個月）；
• 放鬆並接受某些事情不會按計劃進行並且會出現不可抗力。

評測

Anna Bystrikova，系統管理員： 「濟貧院對我來說很有教育意義。 我了解了測試流程，感受到了測試人員的所有「痛苦」。
首先，在測試過程中，作為一個示範用戶，檢查重點：按鈕是否點擊、是否進入頁面、佈局是否移出。 但後來你意識到你需要跳出框框思考並嘗試「打破」應用程式。 測試人員的工作很困難；在整個介面上「戳戳」是不夠的；你需要嘗試跳出框框思考並非常專心。
印像只是正面的，即使是現在，在活動結束後的一段時間，我也看到瞭如何處理我發現的錯誤。 能夠參與改進產品真是太好了^_^。”

Dmitry Seleznev，前端開發人員：「在競爭模式下進行測試極大地激勵我們發現更多錯誤）。 在我看來，每個人都應該嘗試參加 Baghunting。 探索性測試可以讓您找到測試計劃中未描述的情況。 另外，不了解該項目的人也可以就服務的便利性提供反饋。”

安東尼娜·塔楚克，高級編輯：「我喜歡嘗試自己作為測試員。 這是一種完全不同的工作風格。 你試圖破壞這個系統，而不是與它交朋友。 我們總是有機會向同事詢問有關測試的問題。 我學到了更多關於優先考慮錯誤的知識（例如，我習慣於尋找文本中的語法錯誤，但這樣的錯誤的「權重」很小；反之亦然，一些對我來說似乎不太重要的東西最終被一個嚴重的錯誤，已立即修復）。
在活動中，大家總結了測試理論。 這對於非技術人員很有用。 幾天后，我發現自己認為我正在使用“什麼-哪裡-何時”公式來支持另一個網站，並詳細描述了我對該網站和現實的期望。”

結論

如果您想讓團隊的生活多樣化，請重新檢視功能，安排一個迷你 “吃自己的狗糧”，那你可以嘗試舉辦這樣一個活動，然後我們可以一起討論。

祝一切順利，bug 更少！

來源： www.habr.com