テスト計画・テスト環境と環境の準備
テスト計画にはテストのための環境とその準備も書いておく
ソフトのテスト計画書にはテスト環境についても具体的に書いておきます。テスト環境とは、テストに使う機材やテスト用の通信路等です。またそれらの機材や通信路を使うため必要な知識や機材の操作方法などについても書いておき、準備で漏れが無いようにしましょう。
どれくらいの数量の機材を何時迄に準備するのか、それらの機材はどこから手配するのか等、テスト環境の準備についてもテスト計画の時点でよく考えてテスト計画書に書いておく事が大切です。この記事では、テスト環境のために必要な機材にはどんな物があるのか、少し具体的に見ていきます。
ソフトを実行するターゲットハードは何時から何台使うのか
テスト対象のソフトを実行するためのターゲットハードは、何よりも重要なテスト機材です、これが無いとテストが始まりません。しかし組み込み機器の新製品の開発の場合には、このターゲットハードの準備がテスト環境の準備の中でも一番難しい課題になります。新製品なので、ハードも同時に新規に開発している事もよく在りますが、その場合にはハードの開発計画にソフトのテスト用にどの時期に何台のターゲットハードが必要なのか、確実に組み込んで貰いましょう。
機能確認のためのテストや安定性の確認のための過負荷エージングテストや最大構成での動作を確認するための大規模テスなど、様々なテストを実施するためにどの時期に何台のターゲットハードが必要になるのか、それぞれのテスト計画を元に必要な台数と必要な期間を洗い出して、ターゲットハードの手配の計画を作ってそれらの台数と時期に若干の余裕を持たせて、ハードの開発計画に織り込んで貰うのが良いです。
ソフトのテストは安定して動作する製品レベルの品質のターゲットハードがある事が大前提です。しかしハードも同時に開発するような場合には、動作の安定したターゲットハードの数を揃えるのが難しい場面も良く起こります。その様な時には、数少ないターゲットハードを複数のテスト担当者で共有する事でターゲットハードの台数不足を補う事もあります。そうなると、テスト担当者を３チームに分けて各チームが１日に８時間ずつターゲットハードを使うというような事もせざるを得なくなり、テストの夜勤体制が必要になる事もあります。そのような事にならないように、ターゲットハードの台数と入手時期の計画には、ある程度の余裕を持たせておきましょう。
テスト対象のソフトはどのバージョンが何時テストチームに渡るのか
ターゲットハードが無いとソフトのテストは始まりませんが、実はそれよりももっと重要な物があります、それはテスト対象のソフトそのものです。もう少し言葉を補うならば、テストをするのに値する程度の品質を持ってるテスト対象のソフトです。
残念ながらソフトの設計・実装が当初の計画どおりに進む事は稀です。大抵は、開発途中での仕様の追加や変更とか、技術的な問題の発生とかで、設計・実装の工程が遅れる事が多いです。そうなると、テスト計画でテストを開始する予定の日が来たのに、テスト対象のソフトはやっと一部の基本機能が動き始めた段階で、まだ動作していない機能もある、というような事も起こり得ます。当然、まっとうなテストになりません。
設計・実装の工程遅れはテストチームでは対策のしようが無いのですが、少しでもテスト工程への影響を減らすためには、テスト版のソフトの前にα版等の段階のソフトを設計・実装チームから入手して、どの部分の機能ならテストを始められそうか、などのテスト日程の再調整をする事を、めテスト計画に組み込んでおくのも、一つの対応方法です。そのために、どんなバージョンのソフトを何時設計・実装チームからテストチームに渡してもらうのか、事前に相談してテスト計画にも書いておきましょう。
上位に繋ぐサーバや下位に繋ぐ端末のバージョンは明確に
テスト対象の製品には単独で使える物もありますが、最近ではネット接続は当然の機能になってきました。製品をテストする時にも、テスト対象の製品を動かすために上位のサーバに繋いだり、下位の周辺の機器や端末に繋いだりする場合も良くあります。
テスト環境として準備する上位サーバや周辺機器や端末は、ハードのレビジョンと搭載されているソフトのバージョンを明確にしておきましょう。上位や下位に接続するサーバや機器との連携に起因する不具合の場合には、ハードのレビジョンやソフトのバージョンが違うと再現しない事もあります。不具合の調査には再現が重要なので、再現性を確実にするためにも、ハードのレビジョンやソフトのバージョンは計画書で明確にするか、実際のテストの時に忘れずに記録をするようにしておきましょう。
上位のサーバや下位の端末を繋ぐ通信路は綺麗な物だけで良いか
ネットワークとの接続を前提とした装置の場合には、上位のサーバとどんな通信経路で接続するのかもテスト環境として大切です。単純な機能の確認をする場合には、綺麗な通信路で良いですが、安定性を確認するのならば本番環境と同じようにある程度は汚れのある通信路を準備する事も考えておきましょう。
綺麗な通信路とは、伝送エラーや通信遅延が殆ど起きない通信路です。テスト環境を１つの室内で構築して、テスト対象とサーバとの接続ケーブルが短い場合には通信路がノイズの影響を受ける事も無く、通信路で信号が減衰する事も無いので、とても綺麗な通信路になります。
ところが、実際に使われる通信路は、長いケーブルによる信号の減衰があったり、通信路の途中で電磁波等によるノイズで信号が一瞬途切れたりと、結構な汚れのある通信路になっています。もちろん、デジタル信号なのでプロトコルの様々な階層でエラー検出・エラー訂正・再送による回復が働いているので、通信データそのものが失われる事はありません。
しかし、汚れた通信路を通ってきたデジタル信号は、これらのエラー修正・回復の結果として応答性の低下や到着の遅れや短時間のパケットの欠落などが発生します。その結果として、テスト対象のソフトでも何等かのエラー処理が実行されます。
そのような現実の通信路に似た汚れた通信路をテスト環境として用意するかどうかは、テスト対象のソフトの安定性の確認についてどの程度のコストを掛けて確認するのかというテスト設計で変わってきます。ですのでテスト計画の段階ではテスト環境を検討する中で汚れた通信路を用意するかどうかを考えておくのが良いです。
同じような事は、下位の周辺機器や端末を繋ぐケーブルにも言えます。高価で短いケーブルで繋げば綺麗な通信路になりますが、安価で長いケーブルで繋げそのケーブルの近くで電気掃除機を動かしたりすると、結構汚れた通信路が作れます。 これも、テスト計画の段階で汚れた通信路を用意するのかどうかを考えておくのが良いです。
通信相手のエラーを生成する補助装置や補助ソフトは使うのか
テスト対象の装置が上位のサーバや下位の周辺機器や端末と繋がって動作する場合には、サーバや周辺機器や端末も必要になります。これらの実物を揃える事も必要ですが、上位のサーバや下位の周辺機器や端末との連携機能での準正常系や異常系のテストを行うには、サーバや周辺機器や端末からの様々な種類のエラー応答が必要になります。
必要なエラー応答を必要タイミングで発生させようとすると、実物ではなかなか難しくて何らかのシミュレータ装置やシミュレーション用のソフトが必要になります。一般的な通信プロトコルであれば市販のテスト装置にエラーパケットを生成する機能があるのでこれを使えますし、特殊な通信プロトコルの場合にはテスト環境用にシミュレーションソフトを自作する必要もあるかも知れません。いずれにしても、テスト計画の段階でこれらのシミュレーション装置やシミュレータソフトの必要性を考えておきましょう。
テスト作業のための場所と電源と事務所はどうするのか
ソフトのテストに使う環境として、ターゲットハードの台数や上位サーバや下位の周辺機器や端末を具体的に洗い出していくと、それらを設置してテスト作業を行うために必要になるテスト作業場所の広さが大まかに判ってきます。それと同時に、どれくらいの電源容量が必要となるのかも見えてきます。
特に、大規模テストとして最大構成のテストを行おうとすると、最大構成の機材を設置する場所とそれを同時に動かすための電源容量が必要なのですが、計画段階によく検討しておかないと、場所が無いとかテストし始めたらブレーカが落ちた、何てことが起こります。
また、テスト作業はテストの結果を記録し、不具合が見つかればそのトラッキングをスタートする事も大切です。そのためには、テスト作業の結果を整理したしシステムに入力したりするための事務作業の場所もテスト担当者の人数に応じて必要です。これらについてもテスト計画の段階で検討しておきましょう。
テストを実施するテスト人員は何人必要なのか
これは改めて説明する必要もありませんね。テスト設計をする設計者と、テスト作業を行うテスト担当者と、設計やテストの管理を行うテスト管理者について、どんな経験と技量を持ったテスト人員が何人必要なのか、作成したテスト計画から必要な人数を推定して、人員計画を立てておきましょう。立てた人員計画に沿った人員が確保できるかどうかは、また別の問題です。。。
テストの計画ができたら次はテスト結果の管理方法です
この記事ではテスト計画書にどんな事を書くのが良いか、グータラ親父が経験してきた事や見てきた事を元に、紹介してきました。テスト計画ができれば次はいよいよテストの実施です。ここで大切なのはテストで発見した不具合の管理ですので、次の記事では不具合の管理について紹介しましょう。