プログラムのテストプランの作り方

プログラムのテストプランの作り方

プログラムの品質を確保(検証)するのにテストは欠かせません。しかし、フリーランスで開発をする場合は、専門のテストスタップがいない場合も多く、一般的な企業で開発する場合よりテストも限られたものになる場合が多くなります。この記事では、最低限のテストプランをどのように作成したら良いのかをまとめてみました。

大切なドキュメント

当たり前ですが、どんな場合でもプログラムがサポートする基本機能の確認は必須です。基本機能が動かないというのは、大きな問題です。従って、どんなに時間と人手が限られていても、基本機能の確認のテストは絶対に必要です。

ところで、会社などでテストの専門チームがテストの計画を作る場合、どのように作るかご存知ですか？

通常は、プログラムのドキュメントを基に作成します。実はこのドキュメントが無いとテストを考えるのは難しくなるのと、テストを行うのも難しくなります。プログラムを開発する場合、求められる機能があるのが普通です。これらの要求事項を満たすようにプログラムを開発します。ところが、その機能を利用する場合、どのような手順でプログラムを使えば良いかは、プログラムをどのように実現するかで変わってきます。プログラムの開発者は、最低でも２種類のドキュメントを作るのが基本です。

＊　プログラムをどのように作ったか（プログラムの仕様書）

＊　プログラムをどのように使うか（操作マニュアル）

プログラムをどのように作ったかをきちんとドキュメントに残しておくと、将来の保守やトラブル時にプログラムを見直す場合などに役に立ちます。きちんとドキュメントを残すことが重要です。作成している場合には、プログラムの詳細が頭に入っている場合が多いので特にドキュメントを書かなくても何とかなる場合も多いですが、時間が経つと詳細は忘れてしまうもので、コードをみながら探すのは大変です。プログラムの詳細は、コードにコメントを残すなどするとある程度カバーできますが、全体の構成やインターフェースなどはドキュメントに残す事が大切です。 テストの場面でもプログラムの中身の動作を詳しく検証する「ホワイトボックステスト」を行う場合には、こうしたドキュメントを参考に詳しいテストを行うことになります。

最低限のテストを想定した場合には、プログラムの仕様書よりは、「操作マニュアル」の方が重要になります。 操作マニュアルは実際に利用者が行う操作になるので、この基本操作が動作しないのは大きな問題です。従って、最低限のテストの出発点はこの操作マニュアルになります。

基本操作の確認

プログラムがサポートしている機能を使うための手順は、プログラムの作成者（開発者）以外はわからない場合が多くなります。 ただ、ボタンを押せば良いだけのプログラムの場合はシンプルですが、大抵のプログラムは機能を使うための「手順」があります。

例えば、写真の編集ソフトを考えてください。写真を編集するための基本的な手順は

1. 画像のファイルを読み込む

2. アプリで画像を編集をする

3. 編集した画像情報を保存する

大きく分けてこの三つのステップが必要になります。さらに細かく言えば、ファイルを読み込むには、ファイルがある場所を指定して開く画像ファイルを特定する必要があります。画像を編集する場合も、いろいろな操作があります。画像の一部を切り取ったり、色合いや明るさを修正したり、他にもたくさんの編集があって、それぞれ細かい操作手順が必要になります。こうした操作のやり方は、きちんとドキュメントに書かないと利用者が機能を使いこなすのは難し区なります。編集した画像を保存する場合も、保存先を指定するなど詳細の手順が必要になります。

こうした操作は、操作マニュアルに細かくわかりやすく記述する必要があります。

これをテストにする場合は、具体的な操作を機能ごとに書き出します。

例えば、画像のファイルを読み込む場合は、

1. メニュの「ファイル」をクリック　 → 　ファイルのメニュが表示される

2. 「開く」を選択　 → 　ファイル選択画面が表示される

3. ファイル選択画面でファイルを選択する　 → 　開いた画像が表示される

のような感じになります。テストプランにはこれらの操作を「テスト手順として書きます」 その上で、その操作を行った場合に期待されるプログラムの挙動を書きます。 期待通りの挙動ならばテストは「合格」で、期待通りの動作をしなかった場合には「不合格」ということになります。

このような手順で、サポートしている全ての機能を使う手順を基に、想定されるプログラムの挙動と一緒にドキュメントにしたものがテストプランになります。これが、テストの手順（操作）と合否判定基準（期待される動作）です。

最低でも、各機能の操作は１回は必要です。できれば、同じ操作を別のデータで幾つか試すとより確実になります。 ファイルを開く場合には、別のフォルダの場所や、違うフォーマットの画像（JPEG 形式とカメラの RAW データなど）や、複数のファイルを一度に選択した場合などや。フォルダーの選択を間違えたので戻った場合などです。

さらに、操作のキャンセルも考えられる操作になるので、テストを行う必要があります。

一つの機能でも、テストという観点で考えると、テストの項目は複数になる場合が殆どです。

正規の手順以外の操作もテストする

通常の操作だけでも、テスト項目はかなりの数になる場合が殆どですが、そのほかに必要なテストは正規の手順以外のテストです。 先の例で、画像情報を読み込む場合でも幾つかのケースが考えられます。

＊　画像ではないファイルを選択した場合の動作

＊　画像選択の画面を開いた後に、ファイルを削除したり移動してしまった場合の動作

＊　他の画像を編集中に新たに画像を開いた場合の動作

などは、正規の操作とは少し違いますが、現実に起こりうる操作です。このような操作を行ってもプログラムが期待通りに動くかを確認します。どのような動作になるかドキュメントに書かれていない場合でも、やってみてプログラムが「暴走」したり「固まって」しまうことが無いかを確認する必要があります。

多くのプログラムでドキュメントに書かれている機能とその手順の操作の場合、多くの昨日は問題なく動作します。それは、ドキュメントに書かれている時点で、設計者が想定していることなので、プログラムもそれに合わせて書かれる場合が多く動作する可能性が高くなるという理由です。しかし、ドキュメントに書かれていない手順や操作の場合、プログラムがどんな動きをするかは実はやってみないとわかりません。設計者も想定していない場合も多く、そうした場合には意図しない動作をする場合があります。

こうした、正規の手順以外の操作のテストが計画に盛り込まれていると、よりきちんとしたプログラムのテストが行われていることが一眼でわかります。この分野のテストのカバーする範囲を広げることでプログラムの品質は高くなります。

テストプランを作るとプログラムの品質が上がる！

大きな企業の場合、プログラムのテストは専門の人が割り当てられる場合も多く、テストも充実したものになります。 しかし、フリーランスの場合は、開発もテストも同じ人が行う場合が殆どです。大変ですが、テストプランを作成すると、プログラムの品質は確実に向上します。一つには、きちんとした操作マニュアルがないとテストプランの作成が難しくなるというのがあります。しかしそれ以上に、正規の手順以外の操作を考えることで、プログラムの「拔け」が確実に減って、コーディング終了時の品質は大幅にアップするものです。

ホワイトボックステストを含む詳細のテストはフリーランスの場合難しくても、操作を基にしたテストプランでも、フリーランスの開発するプログラムの場合、多くの不具合を見つけることが可能です。

大切なのは、開発者としての視点だけではなく、テスト実行者としての視点を持つことで、プログラムの「想定外」の動作をかなり減らすことが可能になるからです。

まとめ

フリーランスのプログラマが開発を行う場合、テストも自分自身で行わなければならない場合が多くなります。 人手と時間の関係で、会社で開発するようなプログラムのテストは現実的には難しくなります。

しかし、テストの計画をしっかり作ることで、ドキュメントは充実しますし、必要な機能の確認ステップの詳細と期待される機能を意識するために、プログラムの品質は大きく向上します。テストを意識したコーディングも可能になるので、結果的にプログラム完成後の不具合も減るので、多くの場合開発にかかる時間も短縮できる場合が多くなります。

テストも計画があるとやることがハッキリするのでテストの実行効率も上がります。

プログラム開発の早い段階でテストプランを作成することで、詳細のテストができない場合でも、開発全体の効率アップとプログラムの品質がアップします。