テストはシステムの安全を保証するための重要な工程です。
その重要なテストを、いかに抜け漏れ無く行えるかは、
テスト仕様書の内容にかかっています。
テスト仕様書の書き方は、システムの内容や、仕様書のフォーマットによって様々ですが、
どんなテストをする時にも使える、ちょっとしたコツをまとめてみました。
よかったら参考にしてみてください。
MAX値とMIN値を意識する
例えば、DBに登録されている金額を表示させる画面があったとして。
その部分が
「3桁毎にカンマ区切りで表示、単位は”円”」
という仕様になっていたとします。
DBの”1000“という値を”1,000円”と表示させるやつですね。
この機能（仕様）が正しく動いているかテストするために必要なテストデータを考えてみましょう。
まずはDBに’1000’という値を入れたテストデータが必要なのはすぐに分かると思います。
しかしそれだけでは十分と言えず、それ以外のMAX値とMIN値を用意しておく必要があります。
MAX値
MAX値はこの場合DBのカラムのlengthによって変わってきますね。
lengthが8桁だったら”10000000“、もしくは”99999999“という値を用意して
それぞれ“10,000,000円”、”99,999,999円”というように表示されることを確認します。
MIN値
MIN値もDBの仕様によって変わってきますが、NULLなのか、0なのかが考えられます。
NULLが入るケースがある場合、この時の画面表示はブランクなのか、
それとも「円」だけ表示されているのか、もしくは「 – 円」というように
別の表示形式になるのか、などを確認しなければいけません。
もし「DBが0だった時の仕様を考えていなかった！」といったことがあれば、
この段階で気づくことが出来て修正することが出来ます。
色々な所でMAX値とMIN値は意識するようにしましょう。
ビフォーアフターを用意する
例えば、仕様書の確認項目として
「hogeテーブルのfugaの値が1になっていることを確認する」
という項目があったとします。
しかしこれだけでは確認項目として十分ではありません。
これは「アフター」だけ書かれていて、「ビフォー」が書かれていないからです。
この場合、第三者から見たら、「値が1にさえなっていればいいの？この前はどういう状態だったの？」
という疑問が湧いてしまいます。
自分にとっては「今更確認する必要もない」と思うようなことでも、
第三者から見たら疑問に思うこともあります。
それを防ぐために、このような「状態が変わる」ことを確認するテスト項目では
ビフォーとアフターを明確にしましょう。
今回の例の場合は以下のように記述すると良いです。
前提条件：hogeテーブルが「実行前」の状態になっていること
確認項目：処理を行った後にhogeテーブルが「実行後」の状態になっていることを確認する
実行前 実行後 fuga fuga 0 1
具体的な値を用意する
「入力された値が消費税込みの価格で表示されること」
はい、これもNGですね。
この確認項目だけでは、テストをする際にいちいち計算をしなければいけないし、
端数が切り捨てなのか、四捨五入なのかも分かりません。
「消費税込みの価格」という曖昧な表現ではなく、具体的な値を用意しましょう。
このような場合は以下のようにしましょう。
入力された値が消費税込みの価格で表示されることを確認する
※消費税は8%、端数は四捨五入して計算すること
「テストデータ1」を使用し、「想定結果」の状態になっていることを確認する
テストデータ1
¥100
¥101
¥120
想定結果
¥108
※1.08倍されていることを確認
¥109
※小数点第一位が切捨てされていることを確認
¥130
※小数点第一位が繰上げされていることを確認
無闇に番号をふらない
最後はちょっとした小技です。
以下のようにテスト仕様書を書いていたとします。
1 . hoge処理の実行
1-1. ・・・・・・
1-2. ・・・・・・
1-3. 「2 . fuga処理の実行」が行われること。
2 . fuga処理の実行
2-1. ・・・・・・
2-2. ・・・・・・
2-3. ・・・・・・
このテスト仕様書を書いている途中に、システムの仕様が変わり、
hoge処理の前にpiyo処理がが入ることになりました。
さあ、テスト仕様書も直さねば！
1 . piyo処理の実行
1-1. ・・・・・・
1-2. ・・・・・・
1-3. 「2 . hoge処理の実行」が行われること。
2 . hoge処理の実行
2-1.・・・・・・
2-2. ・・・・・・
2-3. 「2 . fuge処理の実行」が行われること。
3. fuge処理の実行
3-1.・・・・・・
3-2. ・・・・・・
3-3. ・・・・・・
「piyo処理の実行」が1番目に来てしまったせいで、
全ての番号を振り直さなければいけなくなりました。
よくあることですね。
番号を一つ一つ振り直したかと思いきや、１箇所だけ直っていませんね。
2-3. 「2 . fuge処理の実行」が行われること。
3. fuge処理の実行
はい、この「2 . fuge処理の実行」も「3 . fuge処理の実行」に直さなければいけませんね。
「直せばいいじゃん」って思われるかもしれませんが、まぁ～これがめんどくさい。
1箇所だけならともかく、このような記述が何箇所もあったら結構な時間がかかります。
何より見落としてしまう可能性もあります。
これを防ぐためには簡単です。
最初から
「2 .」は書かずに
「fuge処理の実行」が行われること。
とだけ書いておけばいいのです。
番号が振っていなくても、大して見辛くなることはないし、
これによって修正の手間とミスをする可能性が大幅に減ります。
もし番号を振ることがルールになっているのだとしたら、
「手間とミスを無くすために番号を無闇に振るのはやめませんか」と進言してみましょう！
まとめ
いかがだったでしょうか。
テストでは、とにかく抜け漏れなく行うことが求められますが、
今回紹介したような「ちょっとしたコツ」が分かっていると、どんな時にも役に立ちます。
このような「ちょっとしたコツ」の積み重ねが
自身のエンジニアとしてのスキル・経験値となっていきます。
ぜひ参考にしてみてください。
