「テスト推進」という仕事
はじめまして、おかじです。私は、テスト推進というポジションの業務を担当しています。
テスト推進とは、簡単に言うとテスト分野を専門としたPMO（プロジェクトマネージメントオフィス）のような仕事です。PMOはPM（プロジェクトマネジャー）やプロジェクトチームに対して、プロジェクトの計画・実行・状況管理などをサポートし、プロジェクトの品質向上を図る役割を担っていますが、一方テスト推進はテストの計画・実行・状況管理などをサポートし、プロジェクトの品質向上を図る役割を担っています。
本記事は、テスト推進業務の経験を元に「現場で意外と困ることの多いテスト環境利用問題」をテーマにテスト環境利用管理について記載します。
これからテスト推進を担当する方にとって、この記事がなにか参考になればと思います。
意外と困るテスト環境利用問題
テスト環境の利用調整に困っているという声をよく耳にします。「テスト環境の管理なんて必要ですか？」と思う方もいると思います。例えばスタンドアローンのアプリケーションのように、自前で用意した環境だけでテスト対象アプリをインストールしてテストできるものであれば、テスト環境利用の問題は発生しないと思います。しかし複数の機能群（サーバー群）から構成されるシステムや特殊なハード機器がある場合などは、簡単に複数のテスト環境を用意することは難しく、テスト環境の利用管理が必要になってきます。
テスト環境利用管理の検討が必要なケース、テスト環境利用で起きる問題例を以下に記載します。
テスト環境利用管理の検討が必要なケース
- 複数のサーバー群で連携動作するシステムである場合。
- マルチベンダー開発や関連事業者が複数いる場合。
- 複数の案件が同じ環境利用で絡む場合。
テスト環境利用で発生する問題
- テスト環境を利用したいが、他のチームが利用して使えない。
→ テストスケジュールの見直しが発生した。
- 環境を占有利用していたが、他のチームが別作業を行って作業中にトラブルが発生した。
→ テスト実施のやり直しや環境故障の修復作業が発生した。
- 環境を利用し始めた際に想定の環境状態と実際の環境状態が異なり、トラブルが発生した。
→ 予定作業が始められず、スケジュール遅延となった。
などなど。
このようなトラブルが続出してしまうとトラブル対応工数や調整工数の増加、スケジュールの再計画の発生が各作業者の負担を増加させてしまい、その結果より大きなミスを誘発してしまう可能性もあります。
「現場で意外と困ることの多いテスト環境利用問題」に対して、私はテスト環境の利用管理を行うことでテスト環境利用問題を軽減し、テストを推進するよう取り組んでいます。
テスト環境の利用管理
大規模なプロジェクトになると以下のような体制で開発することがあります。
- 体制：複数社・複数チーム
- 環境構成：大規模Webシステム・サーバー数十台単位の構成
- 利用状況：複数案件が並走
上記のように複数のサーバーで構成された環境、複数会社やチームによって複数案件が並走しているプロジェクトでは、テスト環境利用管理が必須となります。
これから私が実際に行ってきた管理方法をベースに、テスト環境利用管理の４つのポイントを紹介します。
【ポイント１】環境利用の管理表を考える
【ポイント２】作業区分の定義を考える
【ポイント３】環境変更区分の定義を考える
【ポイント４】環境管理の運用を考える
【ポイント１】環境利用の管理表を考える
テスト環境利用管理を行うために、把握しやすい管理表が必要です。
私は日単位の管理表と時間単位の管理表の二つをエクセルで作成して管理しています。この二つに分けた管理を行っている理由は俯瞰的な状況と詳細な情報を管理し易くするためです。
日単位の管理表
日単位の管理表は、利用予定の俯瞰的な確認、プロジェクト内での情報共有を図ることに利用します。また、主要な環境状態（資材、マスターデータ、システムの設定状態など）を一緒に記載することで、環境状態も可視化できるようにしています。
時間単位の管理表
時間単位の管理表は同日に複数チーム、複数作業が並走した場合に各作業時間や順序を調整したり、環境変更を伴う作業の記録を残すために利用しています。
この時間単位の管理表があることで、より詳細な作業対象環境、作業時間帯を把握できるようになります。
【ポイント２】作業区分の定義を考える
作業区分定義の目的は、利用調整が必要になる作業なのかを簡易的に把握するために定義します。私は「占有作業」「非占有作業」「部分占有作業（条件付き作業）」の３つの区分で整理しています。
占有作業
環境変更など、他の作業と並走不可能な作業
非占有作業
システム動作を停止しなければならない作業がない。他の作業と並走可能な作業
部分占有作業（条件付き作業）
一部のサーバー、一部のデータ領域のみを占有し、条件によっては他の作業と並走可能な作業
【ポイント３】環境変更区分の定義を考える
環境変更区分定義の目的は、環境の状態が変わるのか、変わらないのか、一時的に変えて元の状態に戻すのかを簡易的に把握するために定義します。
環境変更なし
資材変更、設定変更、マスターデータ変更などを伴わない。
環境変更あり
資材変更、設定変更、マスターデータ変更などを伴う。
環境一時変更あり
資材変更、設定変更、マスターデータ変更を伴うが作業後に元の状態に戻す。
【ポイント４】環境管理の運用を考える
環境管理の運用を考える際の重要なポイントは「続けられる運用であること」です。 ルールが複雑で理解しにくかったり、時間や手間が掛かってしまうものだと、管理の考え方が良いものでも続かなくなってしまいます。
私が現場で設けている運用ルールは大きく以下５点です。
- 日単位の管理表に予定を記載したい場合は、各チームから環境管理者に申告する。
- 環境変更を伴う作業や同日に複数利用者がいる場合、利用者が時間単位表に作業を記入する。
- 時間単位で作業が重複した場合、記入した利用者から環境管理者へ連絡する。
- 環境管理者は各チーム情報をもとに調整が必要な場合、関係者を集め調整を行う。
- 環境占有、環境変更を行う作業は作業開始時、作業完了時にメールで周知連絡を行う。
これらの運用は、管理者を置くことで作業情報を集約すること、また作業重複時の調整役とすることで、認知されていない環境変更の抑止を目的としています。
最後に
本記事では環境利用管理を行う際にポイントとなる考えを記載しましたが、環境利用管理を行うことで以下の様なメリットがあります。
- 環境利用状況を視覚化することで各チームのテストスケジュール計画がし易くなる。
- 調整が必要となる作業を把握し易くすることで環境利用の調整工数を削減できる。
- 環境状態を視覚化することで、各チームが利用開始時に想定と異なる環境状態になっていた場合の作業遅延リスクを低減できる。
- 管理者に環境の利用状況を集約するこで、環境変更に伴うトラブルが発生した際の、変更が行われた作業を特定しやすくなる。
など、環境を利用する作業者の負担を軽減することができます。
ソフトウェア品質の根幹には「人はミスをするもの」という考えが根底にありますが、人がミスし易くなる時を考えると作業者の負担が大きい時にミスを犯しやすくなると思います。逆に考えれば、作業者の負担を軽減することで、ミスは減らせるのではないでしょうか。
些細な環境利用管理という側面からでも、作業者の負担を軽減することで作業者のミスを減らすことに繋がり、ソフトウェア品質の向上への間接的なアプローチになると思います。
最後まで読んでいただき、ありがとうございました。
