Microsoft Systems Management Server を使用した新規アプリケーションのインストール
テスト計画の概要
トピック
はじめに
このガイドの要点
品質の計画
テスト計画の詳細
寄稿者
はじめに
本書の目的
本書では、新規ソフトウェアの計画済みの展開をテストする方法の概要を説明します。 説明で重点を置いているのは Microsoft Office XP の展開のテスト ケースですが、テスト展開全体の手順ごとに提供するサブプロセス、必要な機能、およびテスト シナリオは、任意の新規ソフトウェア展開で使用するものと同じになります。 これらの手順の実行に必要な設備、構成、および作業の詳細については、「新規ソフトウェア展開テスト計画の詳細」を参照してください。
対象読者
本書は、Microsoft Services Organization およびパートナーのコンサルティング企業を対象としています。 本書は、ユーザーの観点からは、情報技術 (IT) 実稼動環境に変更を導入またはサポートする IT マネージャと IT サポート担当者のメンバという 2 つの主要なグループを主な対象にしています。
本書のユーザーは、Microsoft Operations Framework (MOF) のプロセス モデル、チーム モデル、およびリスク モデルに精通している必要があります。 これらのモデルについて説明されているドキュメントのコピーは、https://www.microsoft.com/japan/systemcenter/default.mspx から入手できます。
また、ユーザーは Microsoftｮ Office XP などの新規ソフトウェアを配布するために必要なテクノロジを使用でき、「Microsoft Systems Management Server を使用した新規アプリケーションのインストール」で提供されているアーキテクチャ ガイド、ソリューション ガイド、およびその他のサポート資料をお読みになっている必要があります。
このガイドの要点
IT プロジェクトを計画している組織は、その実装に重点を置くあまり、計画とテストに十分な時間や作業をかけない場合があります。 ただし、非常に多くのプロジェクトが失敗に終わる原因は、テクノロジの欠陥ではなく、そのテクノロジがどのように動作しているかに関する理解が欠如していることにあります。
組織は、プロジェクトの成功を確実にするために、製品またはソリューションがどのように機能するかを理解する必要があります。 デザインがビジネス要件を満たしているか、製品またはソリューションが予想どおりに機能するか、サポート担当者がその機能方法を理解しているか、および技術的なデザインが有効であるかを確認する必要があります。
この確認のすべてを行う場所は、実稼働環境ではなく、テスト ラボです。
技術担当者は、このテスト ラボで、運用中のデザインの監視、構成設定の変更、および最適なパフォーマンスを保証するためのデザインの微調整を、エンド ユーザーにまったく影響を与えずに行うことができます。 組織は、テストによってリスクを最小化し、サポート担当者に必要なスキルと経験を提供できます。また、不適切なデザインに関連して発生する費用を削減できます。
組織の実稼動環境をシミュレートするテスト ラボで、本書で概説しているテストを行うことにより、実稼働環境への展開が成功する可能性が高まります。
品質の計画
テストの対象部分
まず、機能上重要な側面をテストします。
プロジェクトは時間、リソースの可用性、および予算によって制限されます。 組織のビジネスの目的およびニーズにとって最も重要な側面に注目します。 ソリューションのその他の側面で問題が発生する可能性もありますが、より重要性の低い部分を検討し、その部分のテストのレベルを下げます。
テストの実行者
ソリューションのテスト チームの構成は、デザインの複雑さ、費やす時間、および元になるビジネスの優先順位によって異なります。 ただし、テスト チームは以下の事項を満たしているのが理想的です。
実績があり、高度な技術スキルを持った個人が主導すること。
実稼働環境に展開された後の、製品のサポートを担当するチームに所属する個人を含めること。
ビジネスの目的および展開を支える理由を十分に理解していること。
デザインの担当者と連絡を取り合い、見つかったことについて討議できること。
テストの実施方法
まず、インストールとテストを監督するラボ マネージャまたはコーディネータを指名します。 基本的な機能のテストから始めて、連続する各段階ごとに徐々に複雑さのレベルを上げていきます。 各テストの完了後、結果をドキュメント化し、プロジェクトの必要条件を満たしているかどうかを検証します。 問題があれば調査し、解決します。
変更制御プロセスを実装して、ラボを使用しているグループ間の競合を避けることが重要になります。 変更制御プロセスには、以下の項目を含める必要があります。
ハードウェアとソフトウェアの状態を記録すること、およびテスタがラボのアクティビティを認識できるように、ラボ マネージャがスケジュールをテストすること。
ラボのハードウェアまたはソフトウェアを変更する前にラボ マネージャに承認を得ること。
ラボのハードウェアまたはソフトウェアの変更をすべてのテスト グループに通知し、承認を得ること。
競合するテスト要件を持つグループのテスト時間を、ラボ マネージャに予約すること。
また、ラボ マネージャは、ラボを元の状態に戻すための適切な手順を用意する必要があります。
テストの実施場所
実稼働環境によく似ているか、理想的には、実稼働環境をミラー化したテスト ラボを作成します。
組織がクライアントとサーバーの標準ハードウェア構成を使用している場合、これらをラボで使用します。 できる限り、実稼働環境に展開されているものと同じハードウェア、ソフトウェア、ネットワーク、ログオン スクリプトなどを使用します。
ディスクの空き領域がほとんどないコンピュータ、旧式で使われていない可能性のあるソフトウェア、および異なる種類のネットワーク アダプタ カードが実稼働環境に含まれている場合、ラボでも同じ特性を持つコンピュータを使用します。 ルータまたは低速リンクで実稼動ネットワークが接続されている場合、ラボでもその状態を再現します。 組織は、この状態の再現によって、デザイン上の問題を、展開中ではなく、ラボの段階で識別し、解決できます。
実稼働環境を正確にミラー化するテスト ラボ環境を使用することにより、ラボのテスト結果が実稼働環境の結果を表しているという期待と確信を持って、システムやアプリケーションを認証できます。
テスト計画の詳細
次の図は、新規ソフトウェア展開のテスト計画の概要について示しています。
.gif "エンドツーエンド プロセス フロー")
エンドツーエンド プロセス フロー
このセクションの残りの部分では、テスト計画の各段階をそれぞれ 1 つのテスト ケースとして説明します。また、サブプロセスの表、必要な機能、および段階ごとのテスト シナリオも含めます。 次の図で、サンプルの表を例示します。
.gif "表 1: テスト ケースの例")
表 1 : テスト ケースの例
このテスト計画全体で、多くの個別のテスト ケースが識別されています。 テストの不必要な重複を防ぐために、あるテスト ケースが以前のテスト ケースで既にテスト済みの機能に依存している場合は、そのテスト ケースは含めません。
以下の例のテスト ケースは、Microsoft Office XP のテスト展開に基づいています。
変更要求
変更の開始者は変更要求 (RFC) を提示する前に、Microsoft Systems Management Server (SMS) Web レポート ツールを使用してレポートを作成する必要があります。このレポートを使用することによって、新規ソフトウェアを実行する必要があるコンピュータの数および場所を識別し、必要な製品ライセンスの数を確認できます。
ライセンス費用は製品のエディションによって異なるので、ソフトウェアのどのバージョンがインストールされているかを示すレポートを作成することも必要です。
どの実稼動環境にも、新規ソフトウェアを実行できないコンピュータ、つまり置き換えるかアップグレードする (追加メモリ、より大容量のディスク、より高速の CPU を取り付ける) 必要のあるコンピュータが数台存在することがあります。 管理者は、ハードウェアとソフトウェア インベントリ中に取得された情報を使用してこれらのコンピュータを識別できます。
No. |
サブプロセス |
必要な機能 |
テスト シナリオ |
合格/不合格 |
|---|---|---|---|---|
N1.1 |
RFC を作成および提示する。 |
最新のインベントリ情報を使用して、Office XP を必要とするコンピュータ、およびそのコンピュータの種類 (例: ポータブル PC またはワークステーション) を識別するレポートを生成する能力。 |
Office XP を必要とするコンピュータを識別するレポートの作成。 |
|
N1.2 |
|
不十分なハードウェア要件を識別する能力。 |
Office XP を必要とし、最低限のハードウェア要件を満たしていないコンピュータを識別するためのレポートの作成。 |
|
N1.3 |
|
Office コンポーネントを備えたコンピュータを識別する能力。 |
Microsoft Outlook などの、Office のサブコンポーネントを備えたコンピュータを示すレポート。 |
|
N1.4 |
|
Office XP を必要とし、必要なハードウェアを備えているコンピュータを識別する能力。 |
アップグレードしないで、すぐにソフトウェアを展開できるコンピュータを示すレポート。 |
|
変更分類
変更の開始者のレポートには、変更マネージャや変更諮問委員会 (CAB) が必要とする情報がすべて含まれている必要があります。
一部のコンピュータは、他の事項よりもビジネスにとってより重要であると見なされるので、変更マネージャは別のコンピュータに新規ソフトウェアをインストールして、異なる優先順位やカテゴリを割り当てようと考える場合があります。 このような場合、各 RFC を独自の適切さで分類し、優先順位を割り当てられるように、コンピュータごとに独立した RFC を作成します。
No. |
サブプロセス |
必要な機能 |
テスト シナリオ |
合格/不合格 |
|---|---|---|---|---|
テクノロジ テストは定義されません。 |
|
|
|
|
変更認可
RFC が変更認可プロセスに進んだら、認可が変更マネージャ、CAB、または CAB 緊急委員会 (CAB/EC) のいずれによって行われたかに関わらず、同じ認可処理を実行する必要があります。
最初の手順は、認可関係者が変更の分類プロセスで提供されるレポートや情報をレビューすることです。 認可の際、変更の認可者は、提供された情報が十分なものであるか、およびビジネス ケースが変更の続行に耐えうるものであるかどうかを判断する必要があります。 たとえば SMS サイト サーバーや配布ポイントが存在する場所を知ること、および公開をサポートするために十分なディスクの空き領域があるかどうかを判断することが、認可者にとって役に立つ場合があります。
可能な公開オプションの識別および評価には、サイトごと、部門ごと、またはコンピュータの種類ごとなど、別のレポートが必要になることがあります。 Office XP のように大規模で複雑な新規ソフトウェアを、すべての場所およびコンピュータに同時に公開することはおそらく不可能です。
No. |
サブプロセス |
必要な機能 |
テスト シナリオ |
合格/不合格 |
|---|---|---|---|---|
N3.1 |
RFC のレビュー |
すべての配布ポイントに Office XP を配布する容量があることを確認するために、指定した配布ポイントのディスク領域の使用状況を識別する能力。 |
Office XP を展開する配布ポイントおよびそれに関連する使用可能なディスク容量を識別します。 |
|
N3.2 |
|
部門または場所ごとにコンピュータを示すレポートを作成する能力。 |
対象となるコンピュータの場所の識別することは、管理者が組織全体に段階的に展開する方法を決定するのに役立ちます。 |
|
N3.3 |
|
Office XP を必要とするすべてのワークステーションの重要なハードウェアの仕様を示すレポートを作成する能力。 |
Office XP 展開前に、すべてのコンピュータのハードウェアのレベルを識別し、Office XP を実行するための組織の受け入れ可能なベースラインを満たしていないコンピュータを識別します。 |
|
N3.4 |
|
各 SMS サイトの SMS クライアントの数およびそのクライアントの種類 (例: ラップトップ) を報告する能力。 |
段階的に大規模な展開を行う場合、各特定のサイトのクライアントの数およびそのクライアントの種類を識別することが、展開の計画に役立ちます。 |
|
変更開発
大企業ユーザーが、すべてのユーザーとすべてのコンピュータに 1 つのインストール ルーチンを用意することはおそらくありません。 いくつか同じ設定や構成オプションもありますが、管理者はユーザーやコンピュータの異なるセットにカスタム インストールを展開する必要があります。
No. |
サブプロセス |
必要な機能 |
テスト シナリオ |
合格/不合格 |
|---|---|---|---|---|
N4.1 |
変更開発 |
MST ファイルを作成する能力とその MST ファイルを使用して既定の MSI ファイルを期待どおりにカスタマイズする能力。 |
Office の既定のインストールではすべてのユーザーに展開されない可能性があります。このインストール プロセスにはバリエーションがあります。 組織はこのバリエーションを展開するために、MST ファイルを使用する必要があります。 |
|
N4.2 |
|
Office XP をアンインストールする能力。 |
大規模な展開の実行中に、すべてのコンピュータまたは特定のコンピュータで Office XP の展開のロールバックが必要な場合があります。 |
|
N4.3 |
|
ワークステーションに追加の Office XP コンポーネントを展開する能力。 |
ワークステーションに追加の Office XP コンポーネントを展開します。 |
|
リリース計画
リリースの範囲設定には、環境に存在するものに関する正確な知識を持っていることが不可欠になります。
リリース マネージャが SMS データベースの情報が最新であると確認したら、変更プロセス中に作成した SMS レポートや情報を使用できます。また追加のレポートを構築して、リリース プロジェクトの規模についてのより正確なイメージを得ることもできます。
No. |
サブプロセス |
必要な機能 |
テスト シナリオ |
合格/不合格 |
|---|---|---|---|---|
N5.1 |
リリース処理 |
MST ファイルを作成する能力とその MST ファイルを使用して既定の MSI ファイルを期待どおりにカスタマイズする能力。 |
Office の既定のインストールではすべてのユーザーに展開されない可能性があります。このインストール プロセスにはバリエーションがあります。 組織はこのバリエーションを展開するために、MST ファイルを使用する必要があります。 |
|
N5.2 |
|
Office XP をアンインストールする能力。 |
大規模な展開の実行中に、すべてのコンピュータまたは特定のコンピュータで Office XP の展開のロールバックが必要な場合があります。 |
|
リリース開発
リリース マネージャは、管理インストール、および変更開発チームによって作成されたカスタマイズ済みの MST ファイルおよび CMW ファイルから新規ソフトウェア ファイルを受け取り、実稼動環境に新規ソフトウェアを展開することを担当します。 新規ソフトウェアの複数の構成を展開する必要がある大規模組織は、このようなソフトウェアを必要なコンピュータに展開できるかどうかをテストする必要があります。
No. |
サブプロセス |
必要な機能 |
テスト シナリオ |
合格/不合格 |
|---|---|---|---|---|
N6.1 |
リリース メカニズムの選択 |
接続を考慮して対象コンピュータに SMS パッケージを展開する能力。 |
高速 LAN に接続されている対象システムに Office XP を展開します。 |
|
N6.2 |
|
|
SMS を使用し、低速リンク経由で Office XP のインストールを開始します。次に CD-ROM などのファイルのローカル ソースを使用します。 これによって、Office XP のような大きなパッケージの展開が低速リンク経由では実行不可能な場合でも、どのユーザーが Office XP をインストールしたかを追跡できます。 |
|
N6.3 |
|
|
リモート クライアントに Office XP を展開します。ただし、利用可能な帯域幅が少ないときはインストールが行われません。 |
|
N6.4 |
リリース パッケージのデザイン |
ユーザーのログオン中に Office XP を非表示で展開する能力。 |
大規模展開では、常に、ユーザーのコンピュータへのログオンを制御できるわけではありません。 |
|
N6.5 |
|
ユーザーのログオンなしで Office XP を展開する能力。 |
大部分のコンピュータでは、ユーザーのログオンなしで Office XP が展開されます。 |
|
N6.6 |
リリース パッケージのデザイン |
クライアントにインベントリを強制的にレポートさせる能力。 |
管理者はインベントリを最新にできない場合、インベントリ サイクルで、クライアントからの最新のデータの取得を強制する必要があります。 |
|
N6.7 |
リリース パッケージのテスト |
必要なコンピュータに自動的に Office XP をインストールする能力。 |
新しいワークステーションがネットワークに追加されたとき、Office XP がビルド プロセスの一部ではない場合、管理者は Office が必要な新しいコンピュータを識別し、ワークステーションにインストールするために SMS を必要とします。 |
|
N6.8 |
確定版ソフトウェアの保管庫 (DSL) の更新 |
実稼動サイトにテスト パッケージを転送する能力。 |
管理者は、実稼動環境でテスト済みパッケージを再作成せずに、テスト済みパッケージをインポートすることによって、エラーの可能性を最小限に抑えることができます。 |
|
受け入れテスト
この時点までのテストの目的は、開発環境内でのリリースおよびリリース パッケージの正常な動作を確認することでした。 開発者およびビジネスの代表者は、受け入れテストにより、実稼働環境を忠実にミラー化する環境で、リリースおよびリリース パッケージが共にどのように機能するかを確認できます。 場合によっては、企業規模の公開に進むために必要な信用を築くために、パイロット テストが必要になることもあります。
No. |
サブプロセス |
必要な機能 |
テスト シナリオ |
合格/不合格 |
|---|---|---|---|---|
N7.1 |
パイロットの実行と結果の評価 |
SMS パッケージが正しく SMS にインポートされること、およびパッケージの属性が予想どおりであることを確認する能力。 |
管理者はパッケージがテスト環境でテストされたら、不適切な構成の原因となる手動によるオブジェクトの再作成を行うのではなく、そのテスト済みパッケージを実稼動環境にインポートする必要があります。 |
|
展開計画
Office XP のような新規ソフトウェアは配布するパッケージが比較的大きくなるので、管理者はパッケージのテストと組織内への配布方法の検討を慎重に行う必要があります。
No. |
サブプロセス |
必要な機能 |
テスト シナリオ |
合格/不合格 |
|---|---|---|---|---|
N8.1 |
詳細調査 |
SMS クライアントを持たないワークステーションを識別する能力。 |
SMS サイト サーバーによって管理される IP サブネットに新しいコンピュータを追加します。 SMS サイト サーバーがこのコンピュータに SMS クライアントをインストールする権限を持っていないことを確認します。 SMS レポートを使用してこのコンピュータを識別します。 |
|
展開準備
実稼動環境は、新しいリリースごとに個別に準備される必要があります。 展開準備に必要なタスクと作業は、リリースおよび選択したリリース メカニズムによって異なりますが、多くの場合、ユーザーやその他の個人へのリリースに関する情報の通知、サービス デスクおよびテクニカル サポート担当者のトレーニング、および重要な IT コンポーネントのバックアップの作成を含みます。
No. |
サブプロセス |
必要な機能 |
テスト シナリオ |
合格/不合格 |
|---|---|---|---|---|
N9.1 |
展開準備 |
低速リンク経由でのソフトウェア配布を管理する能力。 |
管理者は、低帯域幅ネットワークを展開する SMS 階層で、SMS が低速リンク経由でソフトウェアを配布するときに、その配布を制御する必要があります。 |
|
N9.2 |
|
ネットワークの帯域幅が小さいサイトにオンライン以外で Office XP ファイルを送信する能力。 |
管理者は、SMS 媒体使用センダを使用して、ファイルをある SMS サイトから別のサイトに転送し、リモート配布ポイントが更新されていることを確認する必要があります。 |
|
N9.3 |
|
パッケージのソース ファイルが配布ポイントに到達したことを確認する能力。 |
Office XP のソース ファイルを上記のテストのとおりに配布し、すべての配布ポイントがソース ファイルを受信したことを示すステータス レポートを作成します。 |
|
リリース展開
実稼動環境にリリースを移行するプロセスは、リリースの種類と性質、および選択したリリース メカニズムによって異なります。 ただし、すべての場合においてリリース マネージャにステータス レポートが提供される必要があります。また、場合によっては、展開の進捗状況の追跡および監視に役立つツールやテクノロジが提供される必要があります。
No. |
サブプロセス |
必要な機能 |
テスト シナリオ |
合格/不合格 |
|---|---|---|---|---|
N10.1 |
選択したグループへのリリースの展開 |
公開計画に従って、選択したグループに Microsoft Office XP を展開する能力。 |
異なるコンピュータのグループには、異なる構成の Office XP が対象となるため、管理者は Office XP の構成が予想通りにコンピュータに設定されていることを確認する必要があります。 |
|
N10.2 |
|
SMS ツールやステータス メッセージを使用して、Office XP が正常にインストールされたことを検証する能力。 |
管理者は Office XP の展開が開始されたら、インストールの進捗状況とインストールの成功を追跡できる必要があります。 |
|
N10.3 |
変更のロールバックと変更管理への移行 |
Office XP のインストールをロールバックする能力。 |
展開中に、何台かまたはすべてのコンピュータで展開のロールバックが必要になることがあります。 |
|
N10.4 |
実装済みリリース |
すべての対象のコンピュータが Office XP を受け取り、Office XP をインストールしたことを確認する能力。 |
展開中に、何台かまたはすべてのコンピュータで展開のロールバックが必要になることがあります。 |
|
変更レビュー
IT 環境に加えられたいかなる変更に対しても、その変更終了後にレビュー プロセスを実行し、期待どおりの効果が得られたか、また変更の要件が満たされたかどうかを確認する必要があります。
No. |
サブプロセス |
必要な機能 |
テスト シナリオ |
合格/不合格 |
|---|---|---|---|---|
この段階での新たなテクノロジのテストは不要です。このテスト パックの前述のテストで、必要な機能は例示されています。 |
|
|
|
|
寄稿者
プログラム管理チーム
Anthony Baron, Microsoft Corporation
Nigel Cain, Microsoft Corporation
主執筆者
Nigel Cain, Microsoft Corporation
Kamal Patel, Microsoft Corporation
テクニカル ライタ
Jerry Dyer, Microsoft Corporation
編集者
Pat Rytkonen, Volt Technical Services
Christine Waresak, Volt Technical Services
その他の寄稿者
Josh Bradbury, PCR Recruitment
Richard Trusson, Microsoft Corporation
- アーキテクチャ ガイド
- 展開ガイド
- 運用ガイド
- テスト計画の概要
- テスト ケース詳細