パイロット試験とは？ 定義、意味、例

パイロットテストとは何ですか?

パイロットテスト パイロットテストとは、システムの一部またはシステム全体を実際の動作条件下で検証するソフトウェアテストの一種です。パイロットテストの目的は、プロジェクトを一般公開する前に、その実現可能性、所要時間、コスト、リスク、およびパフォーマンスを評価することです。

このテストは、UAT と運用環境の間で正確に行われます。

パイロットテストでは、選ばれたエンドユーザーグループがテスト対象システムを試用し、システムの本格展開前にフィードバックを提供します。つまり、これは後続のユーザビリティテストのリハーサルであり、システムのバグを早期に発見するのに役立ちます。

下の図はその構成を示しています。完成したビルドは限定されたパイロットグループにリリースされ、そこで監視されます。一方、より広範なユーザーは結果が出るまで既存のシステムを使い続けます。

パイロット テストでは、顧客サイト (またはユーザーがシミュレートした環境) にシステムをインストールして、継続的かつ定期的に使用することをテストします。

最も一般的な方法は、システムを継続的に使用して弱点を見つけることです。これらの弱点は、通常のプロセスを通じてバグ報告として開発チームに送り返されます。 欠陥管理プロセスそして、これらの不具合は次回のシステムビルドで修正されます。

このプロセスでは、受け入れテストも一部として含まれる場合があります。 互換性テスト。 これは、古いシステムを置き換えるためにシステムが開発されているときに発生します。

In ソフトウエアエンジニアリングパイロットテストは、製品やサービスに潜在的な市場があるかどうかという、商業的な疑問にも答える。

パイロットテストが重要な理由

パイロットテストは、費用をかけずに何かを学ぶ最後の機会です。それ以降はすべて本番環境でのインシデントです。具体的には、パイロットテストでは以下のことが実現します。

• ソフトウェアおよび、そのテストとサポートに使用される手順のデバッグを行います。
• 製品が本格的な導入に向けて本当に準備が整っているかどうかを確認する。
• 展開における時間、予算、リソース配分に関するより良い意思決定を支援します。
• 対象集団の製品またはプログラムに対する反応を測定する。
• プログラムの成功を、意見ではなく合意された基準に基づいて評価する。
• ユーザビリティテスト中に使用するアクティビティのリハーサルをチームに提供する。

パイロットテストのやり方

パイロット テストのレベルは、移行プロジェクトの規模と範囲によって異なります。 実際のパイロット テストは専用のエリアまたはラボで行われ、ユーザーはソフトウェアの機能をシミュレートしながら多数の手順、トランザクション、レポートを実行します。

プロジェクトの状況に応じて、パイロットテストを実施することができます。

• 一般的な企業であれば、データセンター内のサーバー群を用いて、ユーザーグループによるパイロットテストを実施することができる。
• ウェブ開発企業の場合、パイロットテストは、サイトファイルをステージングサーバーにホストしたり、インターネット上のフォルダに実際に配置したりすることで実施できます。
• 商用ソフトウェア ベンダーの場合は、早期採用者の特別なグループを使用してパイロット テストを実施できます。

いずれの状況においても、パイロットテストは5つのステップからなる文書化されたテスト計画に従って実施される。

ステップ1：パイロットプランを作成する

ステップ2：パイロットテストの準備

ステップ3：パイロットテストの展開とテスト

ステップ4：パイロットテストを評価する

ステップ5：本番環境への展開準備

パイロットテストを実施する前に、以下の点を考慮する必要があります。

• 参加者に適切な研修を提供する。
• サーバーの展開とパイロット運用に向けたシステムの準備に関するロールアウト計画。
• インストール手順に関するドキュメント。
• 各ソフトウェアアプリケーションのテストスクリプト。実行すべき機能のチェックリストで構成されています。
• メールやウェブサイトを利用して、ユーザーからのフィードバックをデザインチームやテストチームに継続的に提供する。
• 不満を感じたユーザーの数、サポートの電話やリクエストの数などの情報など、パイロットの評価基準を設定します。
• プロジェクトに投資してくれた地域パートナーや関係者からなるワーキンググループを組織し、定期的に会合を開いて進捗状況について話し合ってもらいましょう。
• パイロットグループの知識、態度、行動の変化に関する必要な情報を把握するための評価計画と評価ツールを作成する。

パイロットテスト期間中、チームはテストデータを収集・評価します。そのデータに基づいて、チームは以下の戦略の中から1つを選択します。

• よろめき前方へ – 新しいリリース候補版をパイロットグループに展開する。
• ロールバック ロールバック計画を実行して、パイロットグループを以前の構成状態に復元します。
• サスペンド パイロットテストを中止する。
• パッチを適用して続行する 既存のソリューションを修正するためのパッチを適用する。
• 配備します ソリューションの展開に進みます。

ロールバックオプションはパイロットを実行する価値がある理由なので、復元パスは次のようにリハーサルする必要があります。 回復テスト 失敗時の対処方法を書き留めて、うまくいくと想定するのではなく、リハーサルを行う。

パイロットテストの参加基準と終了基準

合意された基準がないまま試験運用を行うと、フィードバックが届くと意見の対立に発展してしまう。最初のユーザーがログインする前に、両方の基準が承認される。

参加条件 – パイロットプログラムは以下の条件を満たした場合に開始できます。

• ユーザー受け入れテストは完了しており、日常業務を妨げるような重大な不具合は確認されていません。
• パイロット環境は、構成、データ量、統合において本番環境を忠実に再現している。
• パイロットグループは選抜され、訓練を受け、演習の目的と期間について説明を受けた。
• 試験運用期間中は、テスト済みのロールバック計画とサポート担当者が待機しています。

終了基準 – パイロット試験は、合意された測定値が得られた時点で終了します。通常、以下のとおりです。

• 欠陥数を深刻度別に集計し、展開が延期されるしきい値を示します。
• システムがサポートする業務プロセスにおけるタスク完了率とエラー率。
• 性能は、交換対象システムのベースラインと比較して測定されます。
• サポート負荷とは、ユーザー1人あたり1週間あたりの通話件数やチケット発行件数などを指します。
• ユーザー満足度は、非公式なコメントではなく、構造化されたアンケート調査を通じて収集された。

これらの測定値は、実行可否の単一の決定につながり、同じ数値は通常、より広範な リスクベースのテスト 一般発売前に、リリースにどれだけの追加報道が必要かを判断する評価。

パイロットテストとベータテスト

両者は未完成のソフトウェアをユーザーに提供するという点で混同されがちですが、違いは管理体制にあります。パイロット版は特定のグループ内で行われる測定可能な試験であるのに対し、ベータ版は大量のフィードバックを収集するオープンリリースです。

側面	パイロットテスト	ベータテスト
Audience	既知の場所における、選ばれた代表的なグループ	参加を希望する一般市民
環境	チームによって管理される、本番環境に近い環境	ユーザー自身のデバイスとネットワーク
タイミング	ユーザー受け入れテスト後、展開前に	パイロット版の後、一般公開に近づく
目的	実現可能性、コスト、リスク、および展開準備状況を証明する	幅広いフィードバックを集め、稀な環境問題を明らかにする
サイズ測定	合意された指標に基づく正式な参加基準と退会基準	報告された問題と使用状況のテレメトリ
ロールバック	パイロットグループ向けに計画およびリハーサルを実施	ユーザーが自分でアンインストールまたは元に戻す

パイロットテストは、 ユーザー受け入れテストシステムが合意された要件を満たしているかどうかを尋ねるものであり、 アルファテストこれは、顧客が完成品を見る前に社内で行われる作業です。

パイロットテストの利点と欠点

トレードオフは単純明快だ。パイロットは証拠を購入するが、その証拠を得るためにはスケジュールと調整の労力を費やす必要がある。

優位性	デメリット
実験室では再現できない、実際の使用パターンにおける欠陥を明らかにする。	UATとリリースの間にスケジュールにフェーズを追加します
インストール手順、トレーニング資料、およびサポート手順を検証します。	本番環境に近い環境と専任のサポート体制が必要です。
実行可否の判断のための測定された証拠を提供する	結果は、選ばれたパイロットグループの代表性にのみ基づいている。
障害発生時の影響範囲を全ユーザーではなく、特定のグループに限定する。	短期間のパイロットテストでは、月末、ピーク時の負荷、季節的な変動を見逃してしまう可能性がある。
本格的な展開に先立ち、関係者の信頼を築く	参加者は、自身のライブワークにおける問題点を報告することをためらうかもしれない。

両方のコラムは、パイロットをスケジュールされたフェーズとして扱うことを主張している。 ソフトウェアテストのライフサイクル 独自の計画と所有者を持つ、非公式な浸水期間として最後に付け加えられるのではなく、 システムテスト.

パイロット テストのグッド プラクティス

• パイロット テストはユーザビリティ テストの XNUMX 日前にスケジュールします。
• すべてのユーザー、顧客、およびプロジェクトチームが成功の基準に合意するまで、パイロットテストを開始しないでください。
• ユーザーに、資料のコピーに問題がある場合はマークを付け、懸念事項を説明し、改善のための提案 (あれば) を提供するよう依頼します。
• パイロットプロジェクトの目的、期間、進捗状況をユーザーに知らせてください。
• 実際のユーザー層を反映した参加者を選ぶべきです。自信のないユーザーも含め、熱心なユーザーグループからは好ましい結果が報告される傾向があるからです。
• 問題点、フィードバック、決定事項はすべて単一の記録にまとめておき、退職時のレビューがその記録に基づいて行えるようにしてください。

さらに2つの実践方法は環境そのものから得られます。パイロットグループのデバイス、ブラウザ、オペレーティングシステムの分布をできるだけ注意深くカバーします。 構成テスト バックアップ、監視、バッチ ジョブなどの日常的な操作が正しく動作することを確認します。 運用受入試験.

パイロットテストの例

パイロット テストの一般的な例を以下に示します。

• Microsoft 実行します Windows インサイダープログラムプレリリースを公開 Windows 一般公開される前に、ボランティア向けチャネルにビルドを配布する。
• Google 実行します Android ベータプログラム対応するPixelデバイスを登録して、リリース前のトライアルを実施する Android 一般公開に先駆けて構築する。
• HPは、自社製品およびサービスに関するオンラインパイロットプログラムを実施している。

それぞれの例は同じ構造を共有しています。限られた自己選択集団が実際の製品を実行し、テレメトリとフィードバックがベンダーに送られ、より広範なリリースはその証拠を待ちます。この手法が他の利用可能なアプローチの中でどのような位置づけにあるかは、以下に記載されています。 ソフトウェアテストの種類.

よくあるご質問