目的
現場でバグが発生、分析したところ、本来、単体テストで抽出されるべきバグであったことが発覚した。ここで作業漏れが出ると、後々大きな問題になってしまうということを目の当たりにして、限られた時間の中でも、効率的かつ効果的なテストの実施を行うために、考え方をまとめたいと思いました。
なぜテストが必要なのか
開発したシステムが正しく動作するものであることを保証するためにテスト工程が存在しています。
例えば、私たちが何か商品を購入した時に、その商品の質を保証する保証書や証明書などが同封されることがあると思います。システム開発では、商品の質を保証するためにテストをすると考えることができます。
単体テストの立ち位置
テスト工程は
①単体テスト(PT)
↓
②結合テスト（IT）
↓
③総合テスト（ST）
以上の順に3つの工程が存在します。
開発するときは要件定義→基本設計→詳細設計と大雑把なところから細かくしていくのに対し、テストするときは細かい部分から大きな領域に向かって統合していかなければなりません。個々のプログラムの品質が確保されていないまま統合しようとしても問題の発生率が高くなり、どこに原因があるかの判別も難しくなる為です。
単体テストでは実装したプログラムが想定通り（詳細設計書通り）の挙動をするかどうかをテストします。
テストパターンを考える上での2つの視点
テストパターンを作るにあたって、意識する視点をまとめてみました。
ホワイトボックス的視点
①順次
プログラムの各命令が、きちんと命令されていることを確認する観点で、命令網羅とも呼ばれます。変数に値が正しく設定されているか、計算がされているかなどを確認していくものです。
②条件、分岐
IF文などの条件文が正しく、判定され、想定している命令を実行するかどうか、想定している関数などに分岐するかなどを確認する観点で、条件網羅とも呼ばれます。
③繰り返し
繰り返しまたはループとも言いますが、想定している回数分繰り返されているかどうかを確認していきます。
ブラックボックス的視点
ソフトウェアはユーザーニーズを実現するための『機能』の集合体であり、機能の内容は設計書に記述されている。
・全てのソフトウェア機能は【入力条件】→【処理】→【出力結果】というモデルで説明できる。
・【処理】の正しさは【入力条件】に対する【出力結果】が正しいことで確認できる。
・【出力結果】はそれぞれ性質・特徴を持ち、評価するための視点がある。
テストケース作成手法
全てのとりうるパターンを網羅してテスト実施をしようとするととんでもない数のテストパターンとなり、時間がいくらあっても足りません。
値だけをみれば確かにパターンはいくつもあるかもしれませんが、その値の示す意味を紐解けば、必要なテストパターンは自ずと見えてくると思います。
例えば「年齢」という値に1〜100までの数値が入るとしましょう。
そしてあるプログラムでは、この数値をから、
1から20未満を「子供」
20から65未満を「大人」
65以上を「高齢者」
と捉えるとしましょう。
100通りありそうに見えたテストパターンですが大分減らせそうです。
無駄のない効率の良いテストケースを考えるためにも、テストケース作成手法は役立ちます。
以下にまとめてみました。
同値分割
起こりうる全ての事象をいくつかのグループに分け、各グループから代表値を選ぶ手法
（例）
・15（子供）
・30（大人）
・67（高齢者）
境界値分析
境界値分析は、同値分割によって分けられた各グループの境界値付近をテストする手法
仕様書の「以下」と「未満」を取り違えたり、プログラムのif文中で不等号「＜」と「≦」を誤るなどして混入したバグは、この手法を用いて検出することが出来ます。
（例）
・19,20で検証
・64,65で検証
さらに具体的なテストパターン
前回の記事に引き続き、観点やら考え方を長々と書き連ねましたが、じゃあ実際にどんなテストパターン考えてんだってことで現場で培った知識をより具体的に纏めていきます。
重要なのは今までの考えを踏まえて、考えているということをお忘れなく。
1.入力チェック
入力値をテストします。
大きく分けて3つ存在します。
①単項目チェックテスト
１つの入力項目に注目してテスト
対象の項目が許容する値に注目します。
（例）
・未入力
・1桁
・最大値±1
・最小値±1
・not null
・非 not null
②単項目関連チェックテスト
複数の項目に注目してテスト
特定の項目が入力されていたら、ある項目も入力されているはずだ、という観点がこのチェックです。
（例）
名前とフリガナの入力4パターン
・名前とフリガナが入力されているパターン
・名前が入力されているのにフリガナが入力されていないパターン
③関連チェックテスト
入力値に紐作くDBの状態に注目するテスト
入力値に紐付く「有効な」レコードが存在するはずだ的な
（例）
・入力の商品IDに紐付く販売可能な商品のレコードが存在するパターン
・入力の商品IDに紐付く売り切れの商品のレコードが存在するパターン
・入力の商品IDに紐付く商品のレコードが存在しないパターン
2.データ0件テスト
DBから抽出した結果が0の時の挙動を確かめる。
3.閾値テスト
照会結果0、1、複数などデータの境界値でテストをする。
4.限界値テスト
DB照会時の項目最大文字出力を確認するテスト
文字が途中で途切れてないか確認する。
5.DB編集
入力値が想定通りのテーブルのカラムに更新されてるか確認するテスト
（ポイント）
どの入力項目がどのDB項目に入ったか分かるように入力値を被せない
5.出力IF項目確認
出力値に想定通りの値が設定されているか確認するテスト
（ポイント）
上に同じ
6.論理削除状態判定
テーブル照会時、論理削除状態を意識するかしないか確認するテスト
（例）
レコードがない、ある、あるけど無効状態
7.入力バリエーション
カナや英字など様々な文字種を入力するテスト
8.データアクセス
初期値設定を確認する
DBに登録、更新の際の初期値が正しく設定されているかを確認する
（例）
会員登録したら、オンライン運用日が初期値として設定されるはずだ的な
9.照会項目の確認
照会値が想定の箇所から照会されているかのテスト
（ポイント）
どのDB項目から参照させてるかはっきりするようにDBにあらかじめ登録する値を被せない
エビデンスの残し方
最後にエビデンスの残し方についても少し解説します。具体的にエビデンスとして残すものとして以下のものが挙げられると思います。
・入出力ファイル
・DBの前後比較
・マスタテーブル値
・カバレッジレポート
カバレッジとはソフトウェアテストにおいて、全体のうちどのくらいまでテストを実施したのかを割合で表したものです。
カバレッジを計測することにより、テストのヌケ・モレを防ぐことができます。
そしてエビデンスは
①間違いなく検証されていること
②検証した結果、設計書通りの挙動していること
を証明するために残します。
ただ画像を貼り付けたものや入出力ファイルが置かれているだけでは、実施者が目視でしっかり確認していたとしてもそれを証明することはできないことがあります。
場合によっては、エクセル関数などを使い、機械的に検証したエビデンスを残す等工夫するといいと思います。
まとめ
・テストは納品するシステムが正しく動作することを保証するために行われる
・単体テストでは実装したプログラムが想定通り（詳細設計書通り）の挙動をするかどうかをテストする
・ホワイトボックス的視点、ブラックボックス的視点を意識して、テストケース作成手法を用い、無駄のないテストケースを考える
・第三者が再現可能、結果の判断ができるテスト仕様書作成を心掛ける。
・エビデンスは検証していること、検証結果が正しいことを証明するために残す。