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