会社の最も重要なソフトウェアが突然故障した場合、どうなりますか？注文が失われたり、期日を過ぎても、お客様からの苦情は間違いなくあります。
この悪夢のようなシナリオは回避できます。継続的かつ厳密なテストプロセスを実装することで、問題が混乱する前に捕捉されます。しかし、このようなプロセスを組織に実装することは、「言うは易く行うは難し」です。
この記事では、社内でテストを開始する際に考慮すべき点と、長期的にテストを行うメリットについて説明します。
プロダクト チーム向けのテストのベスト プラクティス
この記事の最初の部分では、ワークフローにテストの実装を開始するプロセスについて説明します。
チームにテスト文化を取り入れる
チームにテストを効果的に導入するには、全員が共通の考え方を共有し、品質を負担ではなく投資として捉える必要があります。これは、他のすべての文化の変化と同様に、時間と一貫性が必要なプロセスです。
この文化を形成する 1 つの方法として、不具合、その影響、どこから、修正に何が必要かについて話し合う定期的なミーティングがあります。これにより、このような欠陥をそもそも防ぐべき理由を認識できます。
チームに取り組みを監督、推進する専任の担当者を配置することで、成功の可能性が大幅に高まります。チームまたは組織全体のガイドラインを定義し、ベスト プラクティスを収集して共有し、さまざまなレベルでの取り組みの支持者。
もう 1 つの便利な手段は、プロダクトのサポートの役割をローテーションすることです。 プロダクト マネージャー、デザイナー、デベロッパーにとって、フィルタリングされていない顧客から直接インサイトを得て、お客様が直面している日常の問題を知ることは、貴重な体験になります。
目標は、プロダクトのために構築する他の機能と同様に、品質が機能であることをチームの全員が理解することです。誰もがこの考え方を取り入れれば、テストも機能であることを理解するのは自然なことです。テストは出荷された品質を保証するから。
段階的なテストプロセス
プロダクト開発に関わるさまざまなチーム間で連携が取れたら、テストの存在と使用方法をさらに形式化できます。
テストを「完了の定義」の一部にする
機能要件としてテストを追加すると、機能が適切に自動的にテストされるまでリリースの準備ができていないことを伝える
定期的にテストを実行する
自動テストを実装すると、開発プロセスのあらゆるステップで自動テストを利用できます。人間の介入を必要とせず、開発パイプラインの重要なステップごとに実行できます。次に例を示します。
- commit のたびに、
- すべての pull リクエストで。
- 完全なリリースまたは環境変更の後。
本番環境でサードパーティ サービスに依存している場合は、本番環境に対してテストを実行して、サードパーティ API が期待どおりに動作することを確認することも理にかなっています。
指標を定義して収集する
一連の指標を定義することは、テストの有効性と、テスト ワークフローがビジネスに与える影響を測定するために重要です。使用できる指標の例を次に示します。
- 1 か月あたりのリリース数: 1 か月あたりのリリース数が多いほど、開発プロセスがよりアジャイルになります。自動テストは、リリースを確実に進めるうえで重要な役割を果たします。
- バグレポート: バグレポートが減少傾向にある場合は、テスト（および開発プロセス）が効果的であることを示しています。
- テスト カバレッジ: 正確な指標ではありませんが、カバレッジは重要なユースケースをどの程度深くテストしているかを示す優れた指標です。
これらの指標は、スキューが生じる可能性のある他の要因の影響も受けることに注意してください。たとえば、ホリデー シーズンにリリース数が減り、バグレポートが増える場合などです。そのため、少数の指標のみに依存せず、チームで利用できる他のデータとクロスマッピングするようにしてください。
これらの手順をチームで実施できれば、長期的に見て、プロダクトの健全性に確実にメリットがあります。しかし、できることはまだまだあります。
システム管理者向けのテストのベスト プラクティス
プロダクト チームは単独で作業することはできません。これらは、システム管理者が管理するハードウェア、ツール、インフラストラクチャに依存しています。システム管理者は通常、プロダクト開発に直接関与することはありませんが、開発ワークフローに良い影響を与える可能性があります。たとえば、社内の特定のユーザー グループが使用するブラウザのバージョンを積極的に管理しています。
記事の後半では、Chrome のチャネルとエンタープライズ ポリシーを使用して、この仕組みについて説明します。
Chrome リリース チャンネル
デフォルトでは Chrome が自動更新されます。これにより、すべてのユーザーは、最新かつ最も安定かつ安全な Chrome バージョン（すべての最新機能（Stable チャンネルでリリースされた Chrome のバージョン）を含む）を実行するようになります。
ウェブベースのプロダクトを開発する場合は、プロダクト チームがウェブ プラットフォームの変更にプロダクトを適応させる時間を確保するため、Stable チャンネルの前にブラウザを使用することをおすすめします。
このユースケースでは、Chrome はさまざまなユーザー グループ向けに合計 4 つのリリース チャンネルを提供します。
Chrome の場合、さまざまなリリース チャンネルを使用して、今後のブラウザの変更を予測し、一般公開前に最新機能をテストできます。
- Stable チャンネル: ほとんどのユーザーが利用するチャンネルです。Stable チャンネルは、毎月 Chrome の新しいリリースがあると自動的に更新されます。
- Beta チャンネル: このバージョンは 4 ～ 6 週間で安定版になり、リリース予定の安定版のプレビューとテストを行い、準備を整えることができます。
- Dev チャンネル: このチャンネルでは、Chrome の新しいバージョンを週に 1 回入手できます。また、最終的にベータ版に移行される最新の修正がすべて含まれています。チャンネル名が示すように、開発中であるため予期せず故障する可能性がありますが、最新機能も含まれており、安定版になるずっと前の場合もあります。そのため、Dev チャネルはプロトタイピングや最先端の開発に適したツールです。
- Canary チャンネル: 最も試験運用版のチャンネル。最新の機能をすべて含みますが、テストは多く行われません。少なくとも毎日リリースされます。
Chrome のチャンネルについて詳しくは、関連する Chrome のコンセプトのエピソードをご覧ください。
模範的な組織でのチャネルの使用
ソフトウェア開発に対して万能なアプローチは存在しないため、プロダクト チームの構造は組織によって異なります。たとえば、プロダクト管理、UX と UI、エンジニアリング、オペレーション、サポートのロールを持つチームを考えてみましょう。
そのような組織の場合、次のようなチャンネル分割が考えられます。
- プロダクト管理: PM は通常、大部分のユーザーと同じバージョンを使用するため、stable チャンネルを利用できます。まだリリースされていない API を必要とする機能に取り組んでいる場合は、beta または dev チャネルを使用できます。
- エンジニアリングと UX: これらのチームの一部を dev チャネルで利用すると、安定する前でもビュー遷移などの最新の機能にアクセスできるようになります。
- オペレーション: ベータ版の可能性があります。今後ユーザーに影響する破損が予想されます。
- サポート: 大部分のお客様と同じブラウザでプロダクトを操作するために、stable チャンネルを維持できます。
エンタープライズ ポリシーを使用してチャンネルを管理する
Chrome では、ガイドラインを提供し、使用するチャンネルの決定に任せるのではなく、各ユーザーが最終的に使用するチャンネルを積極的に管理するためのエンタープライズ ツールと管理ツールも提供しています。これは、テスト対象が少数の個人から決定論的なユーザー セットに即座に拡大されるため、可能な限り早期に、追跡可能な方法で障害を特定するのに役立ちます。
このレベルの制御を希望する場合は、次の構成を推奨します。
- 従業員（アプリユーザー）: サービス中断のリスクを最小限に抑えるため、ほとんどの従業員は Chrome テストチームによって十分にテストされている stable チャンネルを使用する必要があります。また、ごく一部のユーザー（5 ～ 10%）が beta チャネルを使用する場合があります。このチャンネルでは、Stable のプレビューが 4 ～ 6 週間にわたって提供されます。これにより、管理者はリリースで発生する可能性のある問題を発見できるため、リリースが他のユーザーに公開される前に問題に対処できます。
- IT 部門: システム管理者自身を含む IT 部門のメンバーは、beta または dev チャネルに参加して、Chrome の Stable 版の新機能を 4 ～ 6 週間または 9 ～ 12 週間前からプレビューできます。
長期リリース チャンネル
プロダクトの開発が計画どおりに進まない場合や、Chrome のリリース サイクルの 1 か月が長すぎる場合があります。このユースケースの場合、Chrome は Extended Stable チャンネルを提供します。これにより、機能の更新頻度は低くなりますが、セキュリティ修正は受け取ることができます。このチャンネルは 8 週間ごとに更新されます。
次の図は、さまざまなマイルストーンが Chrome のさまざまなリリース チャンネルでどのように進行するかを示しています。
- Stable と Extended Stable のどちらでも、最初の 4 週間は同じバージョンがリリースされ、その後は 2 つのバージョンが分かれています。
- 拡張された Beta チャンネルはありません。代わりに標準の 4 週間のベータ版サイクルが、Stable と Extended Stable の両方を安定させるために使用されます。8 週間の Extended Stable にオプトインする企業は、環境に影響を与える可能性のある問題をプロアクティブに特定するために、現在と同様にベータ版チャンネルを引き続き運用する必要があります。
おわりに
テストは、ソフトウェア開発会社が製品の品質を確保するための重要な部分であり、組織の従業員が高品質のソフトウェアにアクセスできるようにし、ビジネス プロセスを中断させないようにするためのシステム管理者の重要なステップでもあります。
組織内でテスト ワークフローを実装する場合、品質、つまりテストは機能であるという共通の考え方を共有することが重要です。
この記事では、テストのベスト プラクティスを組織に統合するさまざまな方法について説明しました。既存のテストツールの詳細については、Chrome のツールによるスムーズな自動テストをご覧ください。
テストの実践的ガイダンスについては、最新の Learn Testing コースと web.dev のテスト自動化のベスト プラクティスをご覧ください。