誰かが行動を起こせるレポートに録画を変換する
バグのスクリーン録画を読み込みます。再生し、重要な出来事が起こるたびにマークします。タイムスタンプがキャプチャされ、その瞬間のビデオフレームが取得され、そのステップが番号付きリストに追加されます。
要約、期待したこと、代わりに起こったことを書き、GitHub用のMarkdown、Jiraマークアップ、またはプレーンテキストとして全体をコピーします。ブラウザと画面の詳細は既に入力されています。
録画はあなたのマシンから離れません。ローカルファイルから再生され、フレームはあなたのデバイス上に描画されます。これは、バグが未リリースのビルドや顧客のアカウント内にある場合に重要です。
なぜこのレポート作成にAIを使用しないのか
スクリーン録画を見ているモデルは、見ているものを記述できます。しかし、あなたが見ることを期待したことは知ることができません。そして、それこそがバグ報告の半分であり、誰かがそれに基づいて行動できるかどうかを決定する部分です。
「確認をクリックしたら、請求書パネルが空だった」というのは観察です。それがバグであるかどうかは、そこに何が表示されるべきだったかに完全に依存しており、それを知っている唯一の人物はあなたです。ビデオから期待される動作を生成するツールは、推測をしてその推測を「発見」として提示するものであり、フィールドを空白にするよりも悪い結果を招きます。なぜなら、もっともらしい間違った期待は開発者を誤った道に導くからです。
したがって、ここでの分担は意図的です。このツールは、タイムスタンプ、フレーム、環境、書式設定、番号付けなど、正確に実行できる機械的な作業を行います。あなたは判断を提供します。それには約1分かかり、その結果として誰もあなたに問い合わせる必要のないレポートが完成します。
レポートが通常見落とす3つのこと
多くの薄いバグ報告を読んできましたが、同じ欠落が繰り返し見られ、その3つすべてが難しいことではなく機械的なものです。
タイムスタンプ。「添付ビデオを参照」と書かれたレポートは、読者にその瞬間を見つけるために4分間視聴させます。1:12に発生したと書かれたステップはそうではありません。
環境。ブラウザ、オペレーティングシステム、画面サイズ。誰もがそれを含めるべきだと知っていますが、ほとんど誰もそうしません。なぜなら、思考の途中で設定パネルを開く必要があるからです。ここではあなたのブラウザから読み取られ、既に記入された状態でレポートに表示されます。そして、あなたはそれを修正できます。
静止画。失敗の瞬間のフレームは、20件のイシューのリストでスキャンされるものです。ビデオから手作業でフレームを抜き出すのは非常に面倒なので、人々はそれをスキップします。そのため、あなたがマークする各ステップで自動的に行われます。
正確に何がキャプチャされるか
マークされた各ステップは、正確な再生時間と、その時点のビデオからのJPEGフレームを、レポートを軽く保つために縮小して記録します。これらのフレームをダウンロードして、イシューに添付できます。
環境はブラウザから取得されます：その名前とバージョン、オペレーティングシステム、ピクセル比を含む画面サイズ、およびビューポートサイズ。現在のブラウザは以前よりも自己申告する情報が少ないため、一部が不明になることがありますが、すべてのフィールドはロックされておらず編集可能です。
ピクセルから何も推測されません。このツールは、画面からエラーテキストを読み取ろうとしたり、どの要素をクリックしたかを推測したりしません。なぜなら、それを不確実に行うことは、行わないことよりも悪いからです。
記入される構造
出力はバグ報告が定着している形式に従います。なぜなら、トラッカーやそれを読む人々がその形式を期待しているからです。もしバグ報告テンプレートを探していたなら、これは貼り付けて見つめるだけのテンプレートではなく、既に入力された状態で提供されるものです。
まず要約を1行で記述します。なぜなら、その1行が30件のイシューのリストの中で誰かがスキャンするものであり、あなたのイシューが今日開かれるかどうかを決定するからです。
次に、タイムコード付きの番号付きステップ、期待される動作、実際の動作、そして環境です。その順序は装飾ではありません。読者は、再現可能かどうかを確認するためにステップをチェックし、それが本当にバグであるかどうかを確認するために期待される動作と実際の動作のペアをチェックし、自分の環境で発生しているかどうかを確認するために環境をチェックします。これらのいずれかを埋もれさせると、往復のやり取りが発生します。
空のテンプレートができないことは、自分自身を埋めることであり、それが人々がテンプレートをスキップする原因となる部分です。ここでは、ステップ、タイムコード、フレーム、環境が入力された状態で提供され、ツールが本当に知り得ない3つのフィールドをあなたが記述します。
録画の前に
レポートの質は録画の質に左右され、2つの習慣が違いを生みます。
既知の状態から開始する。セッションの途中で始まる録画では、読者はそれ以前に何があったのか推測することになり、手順が再現できなくなります。ログイン画面、新しいページ、または記述された開始点から始めましょう。
移動すべきではないものを画面からクリアする。URLバーのトークン、顧客の名前、別のタブの無関係なメール、開発者ツールのパネルにあるAPIキーなどです。バグレポートは転送され、チャットに貼り付けられ、チーム外の人にも読まれます。そして、画面録画はその時に画面にあったものすべてを含んでいます。このツールは動画をアップロードしませんが、レポートとフレームはあなたが送った場所にどこへでも送られます。
できないこと
問題を発行しません。GitHub、Jira、その他との接続はありません。レポートをコピーして適切な場所に貼り付けることで、誰よりも先にあなたが読むことができます。
ログ、ネットワークリクエスト、コンソール出力をキャプチャしません。これらは開発者ツール内にあり、一部のバグにとっては非常に重要です。コンソールを撮影するのではなく、チームがすでに使用している安全なルートで添付してください。
そして、何も診断しません。原因、どのコンポーネントに問題があるのか、または既存の問題の重複であるかを伝えることはありません。誰かが作業できる形に証拠を整理することが、その唯一の仕事です。
まずはバグを記録する
まだ問題をキャプチャする必要がある場合、スクリーンレコーダーはブラウザでタブ、ウィンドウ、またはディスプレイ全体を記録します。再現中にナレーションを付ける必要があるバグの場合、音声を付けて記録すれば、説明が証拠に添付されたままになります。
知っておくべき2つの関連ツール。レポートではなく単一の画像が欲しい場合は、ビデオフレーム抽出ツールが一定の間隔でフレームを抽出します。また、録画が長く、口頭でのウォークスルーをテキストとして取得したい場合は、トランスクリプトジェネレーターがナレーションを検索可能なテキストに変換します。
