テスト計画・計画書はテストの方針を最初に書く
ソフトのテスト計画書はテストの方針を最初に書く
ソフトのテスト計画を作る時に一番最初に考える必要があるのはテストの方針です。テストの方針とは例えば、網羅性を重視するとか、日程を厳守するとか、二次不具合の確認を重視するとか、テストで一番重視する点と言い換える事もできます。テストの方針が大切なのは、実施するテストの目的やテスト日程や投入する工数や日程などの具体的なテストの内容をテスト方針に沿って決めていく事になるからです。そしてテスト方針はテスト計画書の最初に書いておき、そのテスト方針をテストチーム全員が認識して、具体的なテストの設計や実施ができるようにしておく事もまた大切です。
テストの方針とはテストで重視する点の事
ところでテストの方針とは何の事でしょうか？ テストの方針を別の言葉で言い換えるとテストで重視する点です。これでもまだ抽象的でよく判らないですが、グータラ親父がこれまでに見てきたソフトのテストで重視していた点にどんな物があるかを整書き出してみると以下のようになります。これがテストの方針の一例です。
- 機能・性能確認の網羅性を重視する
- 機能・性能の互換性確認を重視する
- ＲＡＳ機能の確認を重視する
- テスト作業の効率性を重視する
- 妥当性確認を重視す
- 二次不具合の有無確認を重視する
ソフトのテスト目的は、テスト対象のソフトの品質改善（バグ取り）か品質保証（バグが無い事の確認）で、上に上げたテストで重視した点はどれも、テストにとって必要な項目のうちの１つに過ぎません。しかし、それらの項目の中で何を重視するのかを決めておくという事は、言い方を変えれば限られた時間と機材を使ってテストをする時に優先的に時間と機材を割り当てるのはどの項目なのかを決めて置く、という事です。
テストで重視する点はソフトの目的によって変わってくる
テストで何を重視するのかは何によって決まるのでしょうか、実はテストで重視する点はリリースするソフトの目的によって決まります。例えば新規製品の発売時にリリースするソフトなら、まずは全機能が動作する事の網羅性を重視しますし、バグ修正版のソフトのリリースであれば二次不具合の影響確認を重視します。そのような視点から、上に例として挙げた項目がどんなソフトのリリースの時に重視するのか、もう少し考えてみましょう。
新製品の初版リリース時は機能・性能の網羅性を重視
新製品の発売開始時に搭載する初版ソフトであれば、まずは全ての機能がちゃんと動作し必要な性能が出ている事が最低限必要です。安定性や保守性互換性など、ソフトとして大切な項目ももちろん他にもありますが、新製品の発売時にはやはり機能・性能がちゃんと出来上がっている事が一番大切です。それを確認するには、機能・性能の網羅性の確認が重要で、これがテストの方針になります。
改訂版や第２版リリース時は機能・性能の互換性確認を重視
新製品の発売が始まってしばらくしてから機能追加などで第２版のソフトをリリースする時には、新しい機能の機能・性能の確認も確かに大切です。しかし、既に市場で初版を使っているユーザがいる製品の第２版のソフトならば、既存のユーザがスムーズに２版を使えるように、初版との機能・性能の互換性の確認がより重要になってきます。機能や性能が改善される方向ならば初版からの変化があっても良い方向なので問題無いのですが、機能や性能が悪くなるようでは困ります。
上流の装置や機器ではRAS機能の確認を重視
エンドユーザが利用する機器ではなく、センターやクラウド内のように、サービス提供の最上流のシステムを構成する設備や機器に搭載されるソフトの場合には、機能・性能よりも安定性・可用性・保守性のいわゆる RAS機能がより重要になります。センターやクラウド内の設備や機器は、差０ビス提供のために24時間・365日安定して稼働し続ける事が何よりも重要です。そのために重要なのが RAS 機能なので、これが最も重視すべき項目になります。
頻繁なリリースを行う製品ならテスト作業の効率化を重視
ソフトのリリースの考え方にも色々あります。例えば金融システムのように間違いが許されないシステムのソフトの場合には、しっかりとテストを行い十分な品質を確保してからソフトをリリースします。一方でエンドユーザが操作する端末、例えばパソコンのOSである Windows などは、リリースした後にも頻繁にバグ修正のパッチを出す事でリリースの後に急速に品質を改善していく、というリリースの仕方もあります。
後者のようなリリースの形態をとる場合には、リリースの間隔が短くなるので短い期間で多くのテストをこなす事が大切になります。そのために、テストの自動化などを駆使してテスト作業の効率化を高める事が一番重要になるという事もあります。
利用される場面が多い時 BtoB 製品のソフトでは妥当性確認を重視
BtoC で直接エンドユーザが触る製品の場合には、製品の使われ方もわりと想定できるのでテストもし易いのですが、BtoB でビジネス用途に使われる製品の場合には、製品の開発元では具体的な用途が十分に把握できない場合があります。このような場合には、ソフトの要求仕様に書いてある内容を保証する設計検証をいくら実施しても、本番運用で思わぬ使われ方をして潜在バグが発覚するという事が起きます。
そのような製品の場合には、要求仕様を満たしている事を確認する設計検証も大事ですが、その製品が使われる場面で必要なサービスを提供できるか、という観点の製品の妥当性の確認を重視する事も必要になります。
バグ修正版のソフトのリリースの場合は影響範囲確認を重視
市場で見つかったバグを修正したバグ修正版のソフトのリリースの場合には、テストで重要なのはやはり修正による二次不具合の有無の確認です。せっかくバグ修正版をリリースしたのに、他のバグを入れ込んでしまっては、元も子もありません。
限られた時間と機材と人員でテストをする時の判断の拠り所がテスト方針
残念な事に、ソフトのテストの現場では時間不足・機材不足・人員不足の状況でギリギリの作業が続く事が多いです。俗にいうデスマーチ状態ですね。そんな時には必然的に、何を実施して何を諦めるのかの判断が常に必要です。その判断の拠り所としてそのテストでは何を重視するのか、テスト方針が決まっていると判断がし易くなります。ですので、テスト方針はテスト計画書の最初に書いておきましょう。
テスト計画書にテストの方針を書いたら、その次にはテストの目標を書きましょう。