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