※本記事では、「テスト」についてざっくりと説明しています。※
前回の記事で「コーディング」についてご説明しました。
今回説明する「テスト」については、このコーディングとセットで実施される場合が多く、作成したプログラムに対して、想定した機能が正しく動作しているのかを確認するステップになります。
そのため、クライアントに対してプログラムの動作の保証をするために、テストについても設計書を作成する必要があります。
テストの設計書って?
例えば、建物を建築する場合は耐震強度や地盤の調査、調理器具を販売する場合は耐熱性や使用限度回数など、様々な視点から安全性を保証した上で販売しています。
そのためには、どのようなことを行えば安全であるかを基準としてテストを行う必要があります。
プログラムについても同様で、作成したプログラムが安全である(正しく動作する)ことをクライアントに示す必要があります。
それでは、消費税計算システムを例にテスト設計書を作ってみたいと思います。
テストの範囲を決める
消費税計算システムでは、「商品の値段」、「商品の個数」、「消費税率」の3つの項目を使用しています。
商品の値段、商品の個数については小数点となることは考えにくいため、整数を取り扱うこととします。
一方で、消費税率については2018年現在8%(0.08)であるため、小数点以下の取り扱いについても定義する必要があります。
今回は、小数点は切り捨てとして取り扱うこととします。
また、上記で挙げたテストの他にエラーについてのテストも実施する必要があります。
エラーのテスト範囲としては、「数字のみ」を取り扱うこととし、「文字」の入力は不可能とします。
では、以下プログラムで試してみましょう。
「テスト」を甘く見ていると痛い目を見る
上記のプログラムについては、分かりやすさを優先させるために簡単に作りましたが、実際の現場では以下の例の様にもっと厳密にテストの範囲を決める必要があります。
- 商品の値段、商品の個数については、整数第何位(一の位、十の位など)まで検証するのか。
- 消費税率については、8%(0.08)のみ検証するのか、それとも前回の消費税率5%(0.05)についても検証するのか。
- 合計金額の小数点は、四捨五入するのか、切り捨てるのか。
ここまでの工程を経てようやくクライアントにシステムを納品することになります。
ここまで読んでいただき、ありがとうございました。
他の記事についても、ご覧いただければと思います。