Microsoft Systems Management Server を使用した修正プログラム管理
テスト計画の概要
トピック
はじめに本書の目的 本書の主な目的は、組織が Microsoft Systems Management Server (SMS) を使用して、ソリューションが実稼働環境で機能する確度が高くなるように修正プログラムを展開できるようにすることです。 本書では、ソリューションが期待どおりに実行されることを確認するために必要な機能やテストの概要を説明しています。 本書の補足資料として『テスト ケースの詳細』ドキュメントがあり、このドキュメントにより、このテスト計画で要約したテスト ケースを実行するために必要な詳細が提供されます。 対象読者 本書、社内の担当メンバとコンサルタントの両者に役立ちます。 本書は、情報技術 (IT) 実稼動環境に変更を導入またはサポートする IT マネージャと IT サポート担当者のメンバという 2 つの主要なグループを主な対象にしています。 本書は、読者が Microsoft Operations Framework (MOF) のプロセス モデル、チーム モデル、およびリスク モデルに精通していることを前提としています。 これらのモデルについて説明したドキュメントについては、http://www.microsoft.com/japan/management/ を参照してください。 読者は、SMS サービス提供物を使用する修正プログラム管理で必要なテクノロジ コンポーネントの使用経験があり、同時に提供される『アーキテクチャ ガイド』、『ソリューション ガイド』、およびサポート ドキュメントを一読している必要があります。 このガイドの要点 IT プロジェクトを計画している組織にとっては、主に実装に重点を置き、組織の投資からの直接的な利益を得る上ではあまり重要でない計画段階や展開前段階などの作業を検討することは珍しいことではありません。 テクノロジの欠陥からではなく、テクノロジがどのように動作するかが十分に理解されていないことから、かなりの数のプロジェクトが失敗しています。 組織はこのような失敗を避けるために、展開に進む前に、製品やソリューションがどのように機能するかを判断し、製品やソリューションが機能する前提を検証し、デザインがビジネス要件を満たすことを確認する必要があります。 つまり、組織は製品やソリューションを使用する前にテストする必要があります。 製品やソリューションが期待どおりに機能することの確認、サポート担当のメンバが製品やソリューションの動作方法を理解していることの確認、および技術的なデザインの検証を行う場所は、実稼動の企業ネットワークではなく、テスト ラボです。 技術担当メンバは、テスト ラボで、ユーザーにまったく影響を与えることなく、動作中のデザインを監視したり、構成設定を変更したり、最適なパフォーマンスを確保するためにデザインを微調整したりできます。 組織は、テストによってリスクを最小限にとどめ、サポート担当メンバに必要なスキルと経験を提供できます。さらに、不十分なデザインに関連して発生するコストを削減できます。 ユーザーの実稼動環境をシミュレートするテスト ラボで、本書で概説しているテストを行うことにより、ソリューションおよびソリューションに関係するスキルや能力の信頼性が高まります。 品質の計画テストの対象部分 大部分のプロジェクトでは、テストなどの展開前の作業に割り当てる時間が、時間、リソース、予算、および組織のニーズの制約によって制限されます。 このような制約によって、テストに使用する時間、テストを実行する範囲や精度が制限されます。 このようなテストの数や範囲は組織の要件やビジネスの目的によって異なるので、展開に進む上で十分高い信頼性を組織に提供するテストの数が少なくなることはお勧めできません。 そのため、テストでは組織が機能上 "重要である" と見なしていることに重点を置く必要があります。 ソリューションのその他の側面で問題が発生する可能性もありますが、より重要性の低い部分があれば、その部分のテストのレベルを下げます。 テストの実行者 ソリューション テスト チームに関係する担当者の数は、デザインの複雑さ、費やす時間、および元になるビジネスの優先順位によって大きく異なります。 証明済みの、詳細な技術的スキルがある担当者がチームを指導する必要があります。 理想的には、展開後の製品のサポートを担当するチームに所属する数人の担当者もテスト チームに含める必要があります。 チーム全体として、ビジネス、ビジネスの目的および展開を支える理由を十分に理解している必要があります。 また、チームはデザインの担当者と連絡を取り合い、見つかったことについて討議できる能力も必要になります。 テストの実施方法 テストの基本的なアプローチでは、基本的な機能のテストから始めて、連続する各段階ごとに徐々に複雑さのレベルを上げていきます。 各テストの完了時に結果をドキュメント化し、プロジェクトの必要条件を満たしているかどうかを検証します。 問題点をすべて調査し、解決する必要があります。 テストの実施場所 実稼働環境によく似ているか、理想的には、実稼働環境をミラー化したテスト ラボを作成します。 このテスト ラボを設置する程度は、実稼働環境の複雑さ、および組織がこのテスト ラボの設置に用意できる時間と予算によって異なります。 組織がクライアントとサーバーの標準ハードウェア構成を使用している場合、これらの構成をラボで使用します。 できる限り、実稼働環境で使用されているものと同じハードウェア、ソフトウェア、ネットワーク、ログオン スクリプトなどを使用します。 ディスクの空き領域がほとんどないコンピュータ、旧式で使われていない可能性のあるソフトウェア、または異なる種類のネットワーク アダプタ カードが実稼働環境に含まれている場合、ラボでも同じ特性を持つコンピュータを使用します。 ルータまたは低速リンクで実稼動ネットワークが接続されている場合、ラボでもその状態を再現します。 このアプローチにより、デザイン上の考慮点が、展開中ではなく、ラボ内で識別され、解決できます。 組織は、インストールとテスト作業を監督するラボ マネージャまたはコーディネータを指名します。 組織は、ラボを適切に構成するときに、変更制御プロセスを実装して、ラボを使用しているグループ間の競合を避けるようにします。 このプロセスでは、ラボを使用する各グループはラボのハードウェアやソフトウェアの構成を変更する前に、ラボ マネージャの承認を受け、あるグループが行った変更が他のグループのテストに影響しないようにします。 変更管理プロセスでは、すべてのテスト グループがラボのハードウェアまたはソフトウェアへのすべての変更を通知され、それを同意するようにします。 競合するテスト要件を持つグループは、ラボ マネージャにテスト時間を予約する必要があります。 ラボ マネージャは、ハードウェアとソフトウェアの状態およびテスト スケジュールを掲示し、テスタがラボの利用状況をを把握できるようにする必要があります。 また、ラボ マネージャは、ラボを元の状態に戻すための適切な手順を用意する必要があります。 テストの目標は、製品を実稼働環境に展開する承認 (または許可) を得ることです。 ラボ環境が実稼働環境をミラー化している場合は、ラボのテスト結果を実稼働環境でも同じ結果が得られるという確信を持って、システムやアプリケーションを承認できます。 詳細テスト計画本書の中核をなす詳細テスト計画は、図 1 に示された修正プログラム管理プロセス フローチャートで識別されるプロセスに相当します。  図 1: 修正プログラム管理のエンドツーエンドプロセスフローチャート このテスト計画全体で、多くの個別のテスト ケースが識別されています。 テストの不必要な重複を防ぐために、あるテスト ケースが以前のテスト ケースで既にテスト済みの機能に依存している場合は、そのテスト ケースは含めません。 これらのテスト ケースは、各テスト ケースが参照するサブプロセスに従って、グループ化され、番号が付けられています (図 2 参照)。 図 1 の各プロセスの隣に付けられた番号は、一連のテスト ケースごとの先頭番号を示します。 セットアップ作業 変更を開始する前に、まず、ベースラインの設定と通知手法の購読という 2 つのセットアップ プロセスを完了しておく必要があります。 ベースライン IT 環境全体の標準を確立するには、標準を測定できるベースラインを確立する必要があります。 組織内の IT のパフォーマンスを最適化するには、目的の明確なビジョンだけでなく、プロセスが始まる既存の状況の明確なビジョンも必要です。 表 1 には、テクノロジ ソリューションがベースラインの設定作業をサポートすることを確認するために実行すべきテストを一覧します。 表 1: ベースラインの確立のテスト
購読 組織内に展開されたテクノロジが識別されると、管理者は電子メールのエイリアスを購読したり、Web サイトを参照したり、その分野の専門家(SME: Subject Matter Expert) にそのテクノロジについて相談して、インストールが必要な更新があるかどうか判断したりできます。 表 2 には、テクノロジ ソリューションが購読作業をサポートすることを確認するために実行すべきテストを一覧します。 表 2: 通知方法の購読のテスト
変更の開始 変更を開始するには、通知のソースを特定し、修正プログラムと組織の IT インフラストラクチャとの関連性を確認し、修正プログラムに関連するファイルを分離して調査する必要があります。 このセクションでは、これら 3 つの変更開始プロセスを説明します。 識別 通知を購読する方法を特定すると、それについての責任を担うテクノロジ ストリームに多くの形式で通知が到着し始めます。 また、以前には識別されていなかったソースからの新しい通知が到着する可能性もあります。 このようなソースは、当初は見落としていても、通知のソースとして役に立つことがわかれば、購読モデルに含める必要があります。 このセクションでテストするテクノロジはありません。 関連性評価 たくさんの修正プログラムが、IT 運用コミュニティに毎日リリースされます。 修正プログラムの情報源および作成理由はさまざまで、システム内で注目されているバグの発見やセキュリティを侵害する可能性のあるエラーの出現などがあります。 膨大な種類の使用可能なソフトウェアに適用できる修正プログラムが多数あるので、すべての修正プログラムを徹底的に検査して、組織の IT インフラストラクチャとの関連性を確認することが重要です。 このセクションでテストするテクノロジはありません。 検疫 ウィルスの感染や悪質なコードによる組織の IT インフラストラクチャへの悪影響を防ぐため、修正プログラムのすべて関連ファイルは、検疫 (分離) 環境で検査する必要があります。 検疫は、修正プログラム ファイルを含めて、"すべての" ソフトウェアについて行う必要があります。 隔離された環境では、これらは厳重に管理される必要があります。 厳密な管理を確保するには、組織の専門家グループが検疫プロセスを実行する必要があります。 表 3 には、テクノロジ ソリューションが検疫作業をサポートすることを確認するために実行すべきテストを一覧します。 表 3: 検疫テスト
変更管理 修正プログラム管理での変更とは、Service Pack や修正プログラム (Hotfix) など、IT 環境に十分な計画の下に導入されるソフトウェアへの追加で、IT サービス レベル アグリーメント (SLA) に影響する可能性があり、導入されない場合は環境や環境のコンポーネントの機能に悪影響が出る可能性のある、ソフトウェアへの追加と定義されます。 変更には、臨時の変更と永続的な変更があります。 臨時の変更は、永続的な変更が実装されるまで、または期間限定である特定の目的のために適用されるものです。 永続的な変更は、コンポーネントの現在のバージョンを完全に置き換えます。 ただし、臨時であれ永続的であれ、すべての変更は変更管理プロセスに則る必要があります。 変更要求 他の変更の要求 (RFC) の場合と同様に、変更の開始者は修正プログラムの展開に関連する提案された変更から受けるすべての影響を特定するために、あらゆる作業を行う必要があります。 開始者はすべての影響を受ける構成アイテム (CI) を特定できない可能性がありますが、特定するように努力する必要があります。 特に修正プログラム管理に関連する場面では、開始者が前提条件を把握しているのであれば、要求される順序や干渉が RFC に含まれていることが重要です。 このセクションでテストするテクノロジはありません。 変更分類 変更の開始者が修正プログラムの RFC を提出するときに、RFC の承認プロセスの一部により、変更の優先順位およびカテゴリが判断されます。これはすべての変更が従う標準です。 修正プログラム管理の審査プロセスには、優先順位とカテゴリに関するさらに詳しい審査が含まれます。 このセクションでテストするテクノロジはありません。 変更認可 修正プログラムは標準的な変更とほぼ同じ方法で認可されます。 変更マネージャは、決定を支援するために、RFC 承認 Web フォームのリンクを使用してRFCの共有場所にアクセスし、サポート文書を入手するかもしれません。 これには、修正プログラム RFC を検討する場合に、関連するサポート技術情報や URL リンクを参照したり、Microsoft Outlookｮ のようなツールを使用して現在の変更スケジュールをレビューすることが含まれます。 表 4 には、テクノロジ ソリューションが変更の承認プロセスをサポートすることを確認するために実行すべきテストを一覧します。 表 4: 変更の承認のテスト
変更開発 修正プログラムの RFC は、他の変更と同じスケジュール設定プロセスに沿って行われる必要があります。 ただし、修正プログラムの RFC では、相互依存している変更、順序、前提条件、および競合を考慮することも重要です。 また、変更のスケジュールを設定する担当者は、既存の RFC に影響する可能性のあるキュー内の変更を考慮する必要があります。 このセクションでテストするテクノロジはありません。 リリース管理 リリース管理は、承認された変更 (修正プログラム管理の場合は、修正プログラムや Service Pack) を IT 環境に展開するプロセスです。 環境への影響を最小限に抑えながら、実稼動環境にすべての変更を正常に適用することが目的です。 つまり、リリース管理は、各リリースの準備状態を判断するのに重要な役割を果たします。 リリース計画 リリースの範囲設定では、環境に存在する項目に関する正確で最新の知識を持っていることが不可欠です。 Web レポートを使用して、クライアントのステータス メッセージを検査し、ソフトウェアとハードウェアのインベントリ エージェントで対象のコンピュータからデータを最後に収集した日時を確認する必要があります。 これが最新ではない場合、管理者は強制的にクライアントにインベントリ サイクルを実行させる SMS 提供情報を作成し、Web レポートをチェックすることによってインベントリの進捗状況を追跡する必要があります。 表 5 には、テクノロジ ソリューションがリリースの計画プロセスをサポートすることを確認するために実行すべきテストを一覧します。 表 5: リリース計画のテスト
リリース開発 リリース チームのメンバは、リリース計画に同意するときに、リリースを実稼動に展開するために必要なプロセス、ツール、テクノロジの開発を始めることができます。 このプロセスの実行中に、リリース メカニズムの選択、リリース パッケージのデザイン、構築、およびテストを行う必要があります。 選択するリリース メカニズムによって、リリースの展開に必要な作業が決まります。 このメカニズムは、少なくとも、修正プログラム管理中に設定されているベースラインを満たすことができる必要があります。 また、このメカニズムでは、実稼働環境を最新状態に保つことができ、複数の計画されたイメージ更新の間に追加された新しいコンピュータを考慮した、最も効果的な方法で更新を配信する必要があります。 表 6 には、テクノロジ ソリューションがリリースの構築プロセスをサポートすることを確認するために実行すべきテストを一覧します。 表 6: リリース開発のテスト
受け入れテスト この時点までのテストの目的は、開発環境内でのリリースおよびリリース パッケージの正常な動作を確認することでした。 開発者およびビジネスの代表者は、受け入れテストにより、実稼働環境を忠実にミラー化する環境で、リリースおよびリリース パッケージが共にどのように機能するかを確認できます。 場合によっては、企業規模の展開に進むために必要な信用を築くために、パイロット テストが必要になることもあります。 リリースが実稼動環境に悪影響を与えないことを確認するには、各リリースのテストを実稼動環境を事実上モデル化した設備で実行する必要があります。 表 7 には、テクノロジ ソリューションが受け入れテストプロセスをサポートすることを確認するために実行すべきテストを一覧します。 表 7: 受け入れテスト
展開計画 リリース計画には、リリースを実稼動に物理的に展開 (ロールアウト) するのに必要なすべてのタスクと作業が含まれる場合もあります。 しかし、複雑なリリースの場合、リリース計画には、リリース プロセスの特定の段階の期間や担当者だけを示すいくつかの上層レベルの作業しか含まれていないかもしれません。作業の担当者は、展開計画の作成と、そこで示された期間内に実施されるように資源を用意することに責任を負います。 表 8 には、テクノロジ ソリューションが公開の計画プロセスをサポートすることを確認するために実行すべきテストを一覧します。 表 8: 展開計画のテスト
展開準備 新しいリリースごとに、実稼働環境を準備する必要があります。 この準備に必要なタスクと作業は、リリースと選択したリリース メカニズムによって異なります。 共通のタスクは、リリースに関する情報をユーザーやその他のスタッフ、トレーニング サービス デスク、およびテクニカル サポート担当者に通知し、重要な IT コンポーネントのバックアップを作成することです。 表 9 には、テクノロジ ソリューションが展開準備プロセスをサポートすることを確認するために実行すべきテストを一覧します。 表 9: 展開準備のテスト
リリース展開 実稼動環境にリリースを移行するプロセスは、リリースの種類と性質、および選択したリリース メカニズムによって異なります。 ただし、すべての場合においてリリース マネージャにステータス レポートが提供される必要があります。また、場合によっては、展開の進捗状況の追跡および監視に役立つツールやテクノロジが提供される必要があります。 このセクションでテストするテクノロジはありません。 変更レビュー 修正プログラムに注目した変更レビュー段階は、他の変更の場合と同様に、変更が目標を満たしているかどうかを確認するために実施されます。 このセクションでテストするテクノロジはありません。 寄稿者プログラムマネージャ Anthony Baron, Microsoft Corporation Nigel Cain, Microsoft Corporation 主執筆者 Nigel Cain, Microsoft Corporation Kamal Patel, Microsoft Corporation その他の寄稿者 Josh Bradbury, PCR Recruitment Andrew Savvides, consultant QA マネージャ Jim Ptaszynski, Microsoft Corporation テクニカルライタ Jerry Dyer, Microsoft Corporation 編集者 Matt Baszner, Volt Technical Services Bill Karn, Volt Technical Services Patricia Rytkonen, Volt Technical Services 編集者 Kevin Klein, Volt Technical Services このドキュメントに記載されている情報は、このドキュメントの発行時点におけるマイクロソフトの見解を反映したものです。 変化する市場状況に対応する必要があるため、このドキュメントは、記載された内容の実現に関するマイクロソフトの確約とはみなされないものとします。また、発行以降に発表される情報の正確性に関して、マイクロソフトはいかなる保証もいたしません。 このドキュメントは情報提供のみを目的としており、 明示、黙示、または法律上の保証に関わらず、これらの情報についてマイクロソフトはいかなる責任も負わないものとします。 お客様ご自身の責任において、適用されるすべての著作権関連法規に従ったご使用を願います。このドキュメントのいかなる部分も、米国 Microsoft Corporation の書面による許諾を受けることなく、その目的を問わず、どのような形態であっても、複製または譲渡することは禁じられています。 ここでいう形態とは、複写や記録など、電子的な、または物理的なすべての手段を含みます。 ただしこれは、著作権法上のお客様の権利を制限するものではありません。 マイクロソフトは、このドキュメントに記載されている内容に関し、特許、特許申請、商標、著作権、またはその他の無体財産権を有する場合があります。 別途マイクロソフトのライセンス契約上に明示の規定のない限り、このドキュメントはこれらの特許、商標、著作権、またはその他の無体財産権に関する権利をお客様に許諾するものではありません。 別途記載されていない場合、このソフトウェアおよび関連するドキュメントで使用している会社、組織、製品、ドメイン名、電子メール アドレス、ロゴ、人物、出来事などの名称は架空のものです。 実在する会社、組織、商品、ドメイン名、電子メール アドレス、ロゴ、個人名、場所、出来事などとは一切関係ありません。 © 2003 Microsoft Corporation. All rights reserved. Microsoft、Outlook、および Windows は米国 Microsoft Corporation の米国またはその他の国における登録商標または商標です。 記載されている会社名、製品名には、各社の商標のものもあります。
|
目次
|
