開発者とQA向けの動画圧縮

MOV、MP4、WebM、GIFの再現録画を縮小し、証拠が読みやすく、イシュー、プルリクエスト、サポートチケットに収まるようにする実用的なワークフロー。

バグを30秒で録画しました。しかし、再現動画のアップロードには時間がかかり、2回失敗し、最後にGitHubからファイルが大きすぎると通知されました。あるいはQAがMOVファイルを添付しましたが、インラインで読み込まれず、誰も視聴しませんでした。

画面録画は回帰（レジッション）を説明する最も速い方法であることが多いですが、レビュアーが素早く開き、インターフェースを読み、正確な失敗したパスを再生できる場合にのみ有効です。

画面録画のファイルサイズとイシュートラッカーの制限

イシュートラッカーとPRホストは添付ファイルのサイズに上限を設けています。QuickTime、CleanShot、OBSからのフル解像度のMOVやMP4は、何もトリミングしていない段階で数十〜数百メガバイトになることがよくあります。

まずトリミングし、アップロードに十分な余裕を持ってトラッカーの実際の制限に合わせて圧縮します。最小の数字を追求する前に、UIテキストを保持してください。ハードな上限が重要な場合は、目標ファイルサイズプリセットを使用します。短いサイレントループが動画よりも問題の説明に適している場合にのみ、小さなGIFに変換します。

バグ報告用の動画、GIF、スクリーンショットのフォーマット

バグの証拠にはいくつかの形状があり、それぞれに適した配信方法が異なります。

動画: 画面録画ツールやデモツールからのMOV、MP4、WebM、M4V、MKVなど。
GIF: ループとして見た方が理解しやすい短いUIの glitch、ホバー状態、読み込みの回帰。
画像: 静止画1枚で報告に十分な場合のPNGおよびJPEGスクリーンショット。

QAが提出したものでも、自分のPRに証拠を添付する場合でも、同じキュー、同じプリセットで処理できます。

イシューとプルリクエストへの再現動画の添付

変更前後のクリップはレビューを高速化します。バグを示し、次に修正を示すコンパクトなMP4は、ブランチのチェックアウトなしでレビュアーにコンテキストを提供します。QAの承認も同じように機能します。軽量な添付ファイルは、数ヶ月後でも検索、再オープン、共有が容易です。

テストパスの後に録画ファイルをまとめてドロップするか、1つのファイルをコピーして、イシューに貼り付けられるように軽量化されたバージョンをクリップボードに取得します。

再利用可能なキャプチャフォルダの構築

チケットやテスト実行ごとに予測可能なフォルダを使用します。source、redacted、attachmentの3つです。元のキャプチャを保持し、コピーに対して承認された機密情報の削除（redaction）を行い、その確認済みのコピーから小さな添付ファイルを作成します。attachmentフォルダ内のファイルは、別の判断を必要とせずに指定されたトラッカーに配置できる状態であるべきです。

ファイル名にチケットIDとプラットフォームを含めます。例：GC-142-windows-actual.mp4。顧客名、メールアドレス、内部ホスト名が露出するファイル名は避けてください。

実際のイシュートラッカーの添付ファイル制限

GitHub、Jira、Linear、およびほとんどのPRホストは、プランとファイルタイプに応じて、インライン添付ファイルの上限を10〜100 MBに設定しています。フルRetina解像度の30秒間のMOVは、ディスク上で「大きい」と感じなくても、その制限を超えることがあります。PMやサポートとのメールスレッドに再現クリップを貼り付ける場合の同じ計算については、メール添付ファイルのサイズ制限をご覧ください。

目標ファイルサイズプリセットは既知の上限内に収まります。GIFループで十分なUI回帰の場合、フルMP4ではなく小さなループをエクスポートします。PNGスクリーンショットの細かなテキストよりも、モーションの再現動画では可逆圧縮と非可逆圧縮の違いは重要度が低くなります。チケットの読者がラベルを読み続けられるように、スクリーンショットプリセットは保守的に設定してください。

録画ディレクトリに対するフォルダ監視により、誰かが添付する前に新しいキャプチャはすべて軽量になります。これは、チーム全員が同じ受信トレイにMOVファイルをドロップしている回帰週の期間中に特に有用です。

有用なバグ証拠のためのプリフライトチェックリスト

圧縮は、焦点が定まらない録画を救うことはできません。ファイルを添付する前に、証拠自体を確認してください。

認識できる状態から始め、問題をトリガーする正確なアクションを示します。
ログイン、セットアップ、リトライ、アイドル時間をトリミングします。ただし、それらのいずれかがバグの一部である場合は除きます。
ポインターを表示したままにし、小さなコントロールを録画する前にアプリウィンドウを拡大します。
圧縮コピーを100%でスクラブし、ラベル、コンソールテキスト、エラーメッセージが読みやすいことを確認します。
無関係な通知、トークン、顧客レコード、ブラウザタブを削除します。
環境、ビルド、期待される結果、実際の結果をイシューテキストに記載します。動画はレポートを補足します。環境、手順、期待される結果はテキストでも残してください。

幅広いブラウザでの再生が重要な場合はH.264 MP4を使用します。GIFは非常に短いサイレントループには有用ですが、限られたカラーパレットと弱い圧縮により、より長い証拠のデフォルトとしては不適切です。レビュアーがより明確なフレームを必要とする場合に備えて、イシューが閉じるまでソース録画を保持します。

サービスごとに制限が異なるため、チームは宛先ごとの上限を確認してください。 GitHubは無料リポジトリで10 MB、有料リポジトリで100 MBの動画アップロードを文書化しています。一方、 Jira Cloudはファイルごとに1 GBをデフォルトとし、管理者が値を変更できます。実際の目標値はさらに小さくて構いません。レビュアーがすぐ再生できるサイズを基準にします。アップロードできるだけでは不十分です。

GetCompressがバグ報告ワークフローに適合する場合

レコーダーのエクスポートコントロールは、単発のクリップには十分であり、イシュートラッカーはステップ、環境、期待される動作の場所です。開発者とQAが異なるトラッカーの制限に合わせてMOV、MP4、WebM、スクリーンショット、GIFの証拠を繰り返し準備する際に、GetCompressがより適しています。目標動画サイズ、再利用可能なプリセット、バッチキュー、フォルダ監視により、キャプチャがローカルにある間に再エクスポートの作業を削減します。GetCompressの役割は、画面レコーダー、チケット、承認された機密情報の削除プロセスとは異なります。