会社の最も重要なソフトウェアが突然壊れたらどうなるでしょうか？注文が紛失したり、納期に遅れたりする可能性があり、お客様からの苦情が殺到するでしょう。
この悪夢のシナリオは回避できます。継続的で厳格なテストプロセスを実装することで、問題が混乱を引き起こす前に検出できます。しかし、このようなプロセスを組織に導入するのは、言うほど簡単ではありません。
このドキュメントでは、社内でテストを開始する際に考慮すべきすべての事項と、テストを長期的に活用する方法について説明します。
プロダクト チーム向けのテストのベスト プラクティス
このドキュメントの前半では、ワークフローでテストの実装を開始するプロセスについて説明します。
チームにテスト文化を導入する
チームでテストを導入するには、全員が共通の考え方を持ち、品質を負担ではなく投資と捉える必要があります。これは、他の文化的な変化と同様に、時間と一貫性を必要とするプロセスです。
この文化を形成するうえで役立つのは、欠陥、その影響、発生源、修正に必要な作業について話し合う定期的な会議です。これにより、このような欠陥を未然に防ぐことがなぜ重要なのかを認識できます。
チームに専任の担当者を配置して、取り組みを監督し、推進することで、成功の可能性を大幅に高めることができます。チームまたは組織全体のガイドラインを定義し、ベスト プラクティスを収集して共有し、レベル全体で取り組みを推進する人。
もう 1 つの有用な手段は、プロダクトのサポート ロールをローテーションすることです。お客様から直接、フィルタリングされていない分析情報を取得し、お客様がプロダクトで直面している日常的な問題について学ぶことは、プロダクト マネージャー、デザイナー、デベロッパーにとって貴重な経験となります。
目標は、チームの全員が品質を機能として理解することです。品質は、プロダクトのために構築する他の機能と同じくらい重要です。全員がその考え方を採用すると、テストも機能であると理解するのは自然な流れです。テストは出荷品質を保証するものです。
テストのステップごとのプロセス
プロダクト開発に関わるさまざまなチーム間で連携が取れたら、テストの存在と使用方法をさらに正式にすることができます。
テストを「完了の定義」の一部にする
テストを機能要件として追加することで、機能が適切に自動テストされるまでリリースできないことを明示します。
テストを定期的に実行する
実装された自動テストは、開発プロセスのあらゆるステップで保護手段となります。手動で操作する必要がなく、開発パイプラインのすべての重要なステップで実行できます。次に例を示します。
- すべてのコミットで実行されます。
- すべての pull リクエスト。
- 完全なリリースまたは環境の変更のたび。
本番環境でサードパーティ サービスを使用している場合は、サードパーティ API が想定どおりに動作することを確認するために、本番環境に対してテストを実行することもできます。
指標を定義して収集する
テストの有効性とテスト ワークフローがビジネスに与える影響を測定するには、一連の指標を定義することが重要です。使用できる指標の例を次に示します。
- 1 か月あたりのリリース数: 1 か月あたりのリリース数が多いほど、アジャイルな開発プロセスが採用されていることを示している可能性があります。自動テストは、リリースを自信を持って進めることができるようにすることで、ここで重要な役割を果たします。
- バグレポート: バグレポートの減少傾向は、テスト（および開発プロセス）が効果的であることを示す良い兆候です。
- テスト カバレッジ: 正確な指標ではありませんが、カバレッジは重要なユースケースをどの程度深くテストしているかを示す良い指標になります。
これらの指標は他の要因にも影響されるため、偏りが生じる可能性があります。たとえば、ホリデー シーズンにはリリース数が減少し、バグレポート数が増加する可能性があります。そのため、少数のデータだけに頼らず、チームが利用できる他のデータと相互にマッピングするようにしてください。
チームでこれらの手順を適切に実装すれば、プロダクトの健全性は長期的に必ず向上します。しかし、まだできることはあります。
システム管理者のテストのベスト プラクティス
プロダクト チームは単独で作業することはできません。システム管理者が管理するハードウェア、ツール、インフラストラクチャに依存しています。システム管理者は通常、製品開発に直接貢献することはありませんが、開発ワークフローに良い影響を与えることができます。たとえば、社内の特定のユーザー グループが使用するブラウザのバージョンを積極的に管理します。
この記事の後半では、Chrome のリリース チャンネルとエンタープライズ ポリシーを使用して、この仕組みについて説明します。
Chrome のリリース チャンネル
リリース チャンネルは、Stable、Beta、Dev、Canary の 4 つがあります。
詳しくは、Chrome のリリース チャンネルをご覧ください。
模範的な組織でのチャネルの使用
ソフトウェア開発に万能なアプローチはないため、プロダクト チームの構造は組織によって異なります。たとえば、プロダクト マネジメント、UX と UI、エンジニアリング、オペレーション、サポートの各ロールを持つチームを想定します。
このような組織では、次のようなチャネル分割を検討できます。
- プロダクト マネジメント: PM は通常、ほとんどのユーザーと同じバージョンを使用するために、安定版チャンネルを使用します。まだリリースされていない API を必要とする機能に取り組んでいる場合は、ベータ版または開発版チャンネルを使用することもあります。
- エンジニアリングと UX: これらのチームの一部は dev チャンネルを利用して、ビューの切り替えなどの最新機能を安定版よりも早く利用できます。
- オペレーション: ユーザーに影響する破損を予測するために、ベータ版で実行される可能性があります。
- サポート: 安定版チャンネルを維持して、ほとんどのユーザーと同じブラウザでプロダクトを操作できるようにします。
エンタープライズ ポリシーを使用してチャネルを管理する
Chrome では、ガイドラインを提供するだけでなく、どのチャンネルを使用するかを決定する企業や管理ツールも提供しており、各ユーザーが最終的に使用するチャンネルを積極的に管理できます。これにより、テスト対象が数人の個人から確定的なユーザーセットにすぐに拡大されるため、できるだけ早く、追跡可能な方法で破損を特定できます。
このレベルの制御を使用する場合は、次の構成をおすすめします。
- 従業員（アプリユーザー）: 中断のリスクを最小限に抑えるため、ほとんどの従業員は Stable チャンネルを使用する必要があります。このチャンネルは、Chrome テストチームによって十分なテストが行われています。また、少数のユーザー（5 ～ 10%）は ベータ版チャンネルを利用できます。このチャンネルでは、Stable の 4 ～ 6 週間前のプレビュー版を利用できます。管理者は、リリースで発生する可能性のある問題を特定し、他のユーザーにリリースをロールアウトする前に、問題を解決するための時間を確保できます。
- IT 部門: システム管理者を含む IT 部門のメンバーは、ベータ版または Dev 版チャンネルを利用して、Chrome の安定版で提供予定の新機能を 4 ～ 6 週間または 9 ～ 12 週間前からプレビューできます。
長期リリース チャンネル
製品開発が計画どおりに進まない可能性があり、Chrome の月単位のリリース頻度が高すぎる可能性があります。このユースケースでは、Chrome は Extended Stable チャンネルを提供しています。このチャンネルでは、機能の更新頻度は低くなりますが、セキュリティ修正は同じように適用されます。このチャンネルは 8 週間ごとに更新されます。
次の図は、さまざまなマイルストーンが Chrome のさまざまなリリース チャンネルをどのように進むかを示しています。
- Stable と Extended Stable は、最初の 4 週間は同じバージョンをリリースしますが、その後は異なるバージョンをリリースします。
- Extended Beta チャンネルはありません。代わりに、標準の 4 週間のベータ版サイクルを使用して、Stable と Extended Stable の両方を安定化します。8 週間の延長安定版を選択した企業は、環境に影響する可能性のある問題を事前に特定するために、現在と同様にベータ版チャンネルを引き続き実行する必要があります。
Extended Stable ユーザーにとっての開発版とベータ版のチャネルの重要性
Stable チャンネルのリリース サイクルが 2 週間になり、組織で 8 週間の Extended Stable サイクルを採用してテスト時間を確保している場合でも、Dev チャンネルと Beta チャンネルを使用することは重要です。「拡張 Dev」や「拡張 Beta」といった個別のチャンネルはありません。標準の Dev チャンネルと Beta チャンネルは、Stable リリースと Extended Stable リリースの両方を安定化するために使用されます。
デベロッパー チャンネルとベータ版チャンネルを継続して実行することで、企業は環境に影響する可能性のある問題をプロアクティブに特定できます。Dev チャンネルと Beta チャンネルでは、次期安定版リリースの 4 週間前にプレビューが提供されます。拡張安定版ユーザーにとって、このプレビュー ウィンドウは、8 週間の機能更新に先立って潜在的な破損を発見し、対処するために不可欠です。
Dev チャンネルと Beta チャンネルは、8 週間の Extended Stable 環境に導入される変更に関する早期警告システムとして機能し、エンタープライズ アプリの互換性を維持します。システム管理者は、このメリットを最大限に活かすため、引き続き少数の確定的なユーザー グループ（アプリユーザーの 5 ～ 10% など）を開発チャンネルとベータ版チャンネルに割り当てることができます。
まとめ
テストは、ソフトウェア開発会社が製品の品質を確保するための重要な要素であり、システム管理者が組織の従業員に高品質のソフトウェアを提供し、ビジネス プロセスの中断を回避するための重要なステップでもあります。
組織内でテスト ワークフローを実装して成功させるには、品質、つまりテストは機能であるという共通の考え方を全員が共有することが重要です。
このドキュメントでは、テストのベスト プラクティスを組織に統合するさまざまな方法について説明しました。既存のテストツールについて詳しくは、Chrome のツールでスムーズな自動テストを実現するをご覧ください。
テストの開始から終了までのガイダンスについては、web.dev の最近のテスト学習コースとテスト自動化のベスト プラクティスもご覧ください。