こんにちは、みんな！ 私の名前はユリアです。テスターです。 昨年もお伝えしましたが、 バゴデルニャ - バグのバックログを一掃するために社内で開催されるイベント。 これは、わずか 10 日で大幅に (チームによっては 50% から XNUMX% に) 削減できる、完全に実行可能なオプションです。

今日は春のバゴデルニーフォーマット、BUgHunting (BUH) についてお話したいと思います。 今回は古いバグを修正するのではなく、新しいバグを探して機能のアイデアを提案しました。 カットの下には、このようなイベントの組織、結果、参加者からのフィードバックに関する多くの詳細が表示されます。

規制を熟考して書き留めた後、企業 Slack のすべてのチャネルに制限を含まない招待状を送信しました。

その結果、開発者と非技術専門家を合わせて約 30 名が登録しました。 私たちはそのイベントのために丸一日を割り当て、大きな会議室を予約し、オフィスの食堂で昼食を用意しました。

なぜですか？

各チームがその機能をテストしているようです。 ユーザーはバグを私たちに報告します。 なぜこのようなイベントを開催するのでしょうか？

私たちにはいくつかの目標がありました。

1. 関連プロジェクト/製品に近いメンバーを紹介します.
   現在、当社では全員が別々のチーム、つまりユニットで働いています。 これらは、機能の独自の部分に取り組んでおり、他のプロジェクトで何が起こっているかを必ずしも完全に認識しているわけではないプロジェクト チームです。
2. 同僚をお互いに紹介するだけです.
   モスクワ オフィスには約 800 人の従業員がいますが、同僚全員がお互いのことを一目で知っているわけではありません。
3. 開発者の製品のバグを発見する能力を向上させる.
   私たちは現在、アジャイル テストを推進し、この方向に人材を訓練しています。
4. テストには技術専門家だけではなく関与させる.
   技術部門に加えて、他の専門分野の同僚もたくさんいます。彼らは、テストについて、つまり、「ああ...何も機能しません」のようなメッセージを受信するのを減らすためにバグを適切に報告する方法について、もっと話したいと考えていました。
5. そしてもちろん、厄介で目立たないバグも見つけます.
   私はチームが新機能をテストできるように支援し、実装された機能を別の角度から見る機会を提供したいと考えていました。

具現化

私たちの一日はいくつかのブロックで構成されていました。

• 説明会;
• テストに関する短い講義。主要なポイント (テストの目標や原則など) のみに触れました。
• バグを導入する際の「マナーのルール」に関するセクション (ここで 原理はよく説明されています）。
• 高レベルで説明されたシナリオを含むプロジェクトの XNUMX つのテスト セッション。 各セッションの前に、プロジェクトに関する短い導入講義があり、チームに分かれました。
• イベントに関する簡単なアンケート。
• 要約すること。

（セッション間の休憩と昼食も忘れませんでした）。

基本的なルール

• イベントへの登録は個別です, これにより、XNUMX 人が行かないと決めた場合に惰性でチーム全体が消耗してしまうという問題が解決されます。
• 参加者はセッションごとにチームを変更します。 これにより、参加者がいつでも出入りできるようになり、より多くの人と出会うことができます。
• チーム 各セッションの前に XNUMX 人 ランダムに形成される、これにより、より動的かつ高速になります。
• 持ち込まれたバグに対しては報酬が与えられます クリティカル度に応じてポイント (3 ～ 10).
• 重複した場合にはポイントは付与されません。
• バグは、すべての内部標準に従ってチーム メンバーが報告する必要があります。
• 機能リクエストは別のタスクで作成され、別の推薦に参加します。
• 監査チームはすべてのルールの遵守を監視します。

その他の詳細

• 当初は「上級」のテストイベントをやりたかったのですが…。 製品チーム以外のかなり多くの人 (SMM、弁護士、PR) が登録したため、コンテンツを大幅に簡素化し、複雑なケースやプロファイルのケースを削除する必要がありました。
• Jira 内のユニットはさまざまなプロジェクトで作業するため、フローに従って、バグを導入するためのテンプレートをセットアップする別のプロジェクトを特別に作成しました。
• ポイントの計算には、Webhook 経由で更新されるリーダーボードを使用する予定でしたが、問題が発生し、最終的には手動で計算する必要がありました。

イベントを企画するとき、誰もが問題に遭遇します。少しでもわかりやすくするために、回避できる問題について説明します。

スピーカーの XNUMX 人が突然病気になり、新しいスピーカーを探さなければならなくなりました.
午前9時に同じチームから代わりの選手を見つけられたのは非常に幸運でした）。 ただし、運に頼らず予備を持っておくほうが良いでしょう。 または、必要な報告を自分で行う準備をしてください。

機能を展開する時間がなかったため、ブロックを交換する必要がありました.
ブロック全体を破棄しないようにするには、バックアップ計画を立てておくことをお勧めします。

一部のテスト ユーザーがドロップしたため、すぐに新しいユーザーを再作成する必要がありました.
テスト ユーザーを事前にクロスチェックするか、すぐにテストできるようにします。

フォーマットが簡略化された選手はほとんど来なかった.
誰かを無理に引きずり込む必要はありません。 謙虚になってください。
イベントの形式を「アマチュア」/「アドバンス」と厳密に規定することも、一度にXNUMXつの選択肢を用意して事後的にどちらを開催するかを決定することも可能です。

組織に役立つポイント:

• 事前に会議を予約します。
• テーブルを配置し、延長コードとサージプロテクターを忘れないでください（ノートパソコンや電話の充電では一日中足りないかもしれません）。
• 採点プロセスを自動化する。
• ランキング表を作成する。
• テスト ユーザーのログインとパスワード、Jira の操作手順、スクリプトを記載した紙の配布資料を作成します。
• イベントの XNUMX 週間前に忘れずにリマインダーを送信し、持ち歩く必要があるもの (ラップトップ/デバイス) も指定してください。
• デモのとき、ランチのとき、コーヒーを飲みながら同僚にイベントについて話してください。
• この日は何も更新またはロールアウトしないという DevOps に同意します。
• スピーカーを準備します。
• 機能所有者と交渉し、テスト用のシナリオをさらに作成します。
• 軽食としてお菓子（クッキー/キャンディー）を注文します。
• イベントの結果についても忘れずにお知らせください。

結果

丸一日かけて、チームは 4 つのプロジェクトをテストし、192 個のバグ (そのうち 134 個は固有) と 7 個の機能リクエストの問題を作成することに成功しました。 もちろん、プロジェクト オーナーはこれらのバグのいくつかについてはすでに知っていました。 しかし、思わぬ発見もありました。

参加者全員に素敵な賞品が贈られました。

そして優勝者は魔法瓶、バッジ、スウェットシャツです。

何が面白かったのか:

• 参加者は、時間が限られており、考えることに多くの時間を費やすことができない中で、厳しいセッションの形式が予想外であることに気づきました。
• デスクトップ、モバイルバージョン、アプリケーションをテストすることができました。
• 一度に多くのプロジェクトを検討しましたが、退屈する暇はありませんでした。
• さまざまな同僚に会い、バグを導入する彼らのアプローチを調べました。
• テスターの痛みをすべて感じました。

改善できること:

• 実行するプロジェクトを減らし、セッション時間を 1,5 時間に増やします。
• 贈り物や記念品はかなり前に準備します（承認や支払いに XNUMX か月かかる場合もあります）。
• リラックスして、何かが計画どおりに進まず、不可抗力が生じることを受け入れてください。

レビュー

アンナ・ビストリコヴァ、システム管理者: 「救貧院は私にとってとても勉強になります。 私はテストのプロセスを学び、テスト担当者のすべての「痛み」を感じました。
まず、テスト プロセス中に、模範的なユーザーとして、ボタンがクリックされたかどうか、ページに移動したかどうか、レイアウトが移動したかどうかなどの主要な点を確認します。 しかし、後で、もっと固定観念にとらわれずに考えて、アプリケーションを「壊す」必要があることに気づきました。 テスターは難しい仕事をしています。インターフェイス全体を「調べる」だけでは十分ではありません。既成概念にとらわれずに考え、細心の注意を払う必要があります。
イベントからしばらく経った今でも、私が見つけたバグに対する作業がどのように行われているかがわかります。 製品の改善に参加していると感じられるのは素晴らしいことです ^_^。」

ドミトリー・セレズネフ、フロントエンド開発者: 「競技モードでテストすることは、より多くのバグを見つける動機になります)。 皆さんもバッグハンティングに参加してみてはいかがでしょうか。 探索的テストを使用すると、テスト計画に記載されていないケースを見つけることができます。 さらに、プロジェクトを知らない人でもサービスの利便性についてフィードバックを与えることができます。」

アントニーナ・タチュク、上級編集者: 「テスターとして自分自身を試すのが好きでした。 これはまったく異なる仕事のスタイルです。 あなたはシステムを破壊しようとしているのであって、システムと友達になろうとしているのではありません。 私たちは常に同僚にテストについて質問する機会がありました。 バグの優先順位付けについてさらに学びました（たとえば、私はテキスト内の文法上の間違いを探すことに慣れていますが、そのようなバグの「重み」は非常に小さいです。逆も同様で、私にとってあまり重要ではないと思われたものが最終的には重要ではなくなりました）重大なバグであり、すぐに修正されました）。
イベントでは、彼らがテスト理論の概要を説明しました。 これは技術者以外の人にとって役に立ちました。 そして数日後、私は自分が別のサイトを支持するために「いつ、どこで、何を」という式を使って、そのサイトと現実からの期待を詳細に説明しているのではないかと考えていたことに気づきました。」

まとめ

チームの生活を多様化したい場合は、機能を見直して、ミニ 「自分で作ったドッグフードを食べましょう」、それならそのようなイベントを開催してみてはどうでしょうか、そしてそれについて一緒に話し合うことができます。

バグが少なくて最高です!

出所： habr.com