Content last updated 2026-07-15
Test Governance グループ(廃止)
Test Governance グループは廃止されました。機能チームがテストライフサイクル全体を担います。
このグループは廃止されました
Test Governance グループは廃止されました。テストは中央集権的に管理される機能ではありません。変更内容
DevOps 変革の一環として、GitLab は中央集権的に管理されるテスト機能から離れ、Test Governance グループを廃止しました。
モジュール型の機能チームとモノリスが、エンドツーエンド(E2E)を含むすべてのレベルで、テストの設計、作成、保守、トリアージ、品質というテストライフサイクル全体を担います。チームに代わってテスト(E2E を含む)を作成または保守する専任者や中央チームは存在しません。
リリース準備完了はチーム内で行う意思決定です。 GitLab.com へのロールアウトを承認する外部チームはありません。自動パイプラインチェック(たとえば、staging-canary スモークテスト)は、その決定を支援する仕組みであり、外部の承認者ではありません。
DevEx が現在行うこと
Developer Experience 部門は、チームが効果的にテストを担えるようガイダンスとスキル向上の支援を提供し、共有テストインフラ(テスト環境、フレームワーク、ツール、ダッシュボード、E2E パイプライン)を担います。
失敗のトリアージと最初の対応は担当する機能チームが行います。DevEx は、深い専門知識を本当に必要とする深刻なケースにおける最後のエスカレーション先であり、問題が起きたときの標準的な連絡先ではありません。
ガイダンスが必要な場合は、#s_developer_experienceで連絡してください。
参照先
- GitLab におけるテスト — テストの考え方、オーナーシップモデル、サポート
- Developer Experience 部門
- 品質は全員の責任
テストを担うための役立つリソース
カバレッジ戦略とレベル
- GitLab テストの概要 — チームがユニット、統合、エンドツーエンドのテスト全体で包括的なテストカバレッジを担うという全体的な期待を示します。エンドツーエンドのカバレッジは重要なユーザーフローに重点を置きます。
- テストレベル — テストピラミッドを最も明確に説明しています。カバレッジの大半はユニットレベルに置き、上位レイヤーのテストは少なくし、実行と保守のコストが最も高いため E2E は最小の割合にします。
- テスト戦略 — GitLab の自動テストの設計図です。テストを実行する場所とタイミングを示すため、チームは各スイートがどのリスクを担うかを把握できます。
- テストカバレッジ — 機能レベルの E2E だけでなく、オフラインまたはエアギャップ環境でのテストやアップグレードパスのカバレッジなど、特別なシナリオ全体のカバレッジを GitLab がどのように考えるかを説明します。
テストの作成
- テストのベストプラクティス — テスト設計、RSpec、FactoryBot、システムテスト、パラメータ化テストなど、優れたテストを書くために知っておくべきすべてを説明します。
- フロントエンドテストの標準とスタイルガイドライン — promise のテストとスタブを含め、Jest で優れたフロントエンドテストを書く方法を説明します。
- エンドツーエンドテスト作成の入門ガイド — まず既存の下位レベルのカバレッジを確認します。ユニット、機能、統合のカバレッジがすでに十分なら、追加の E2E テストは不要な場合があります。
- エンドツーエンドテストガイド — GitLab が E2E を実行する方法、選択的実行、および下位レベルの機能テストがすでにリスクをカバーしている場合に E2E カバレッジを避ける原則を説明します。
テストを健全に保つ
- 不健全なテスト — 発生するフレーキーテストの種類と、その特定および修正方法を説明します。これにより、チームは自らのスイートを信頼できる状態に保てます。
- フレーキーテスト — 主要なフレーキーテストがチームの対応のために自動検出・報告される方法を説明します。
- 隔離プロセス — テストを隔離する方法と、担当チームが
feature_category に基づいて解決または削除の責任を持つことを説明します。
このページには Test Governance グループの公式ワークフローが記載されています