この記事の対象者

・新人SE
・とりあえずテストを書かないといけない人

テスト項目の書き方

だいたいテスト項目はこんな感じの表で作っていくことが多い。

No	分類	テスト手順	期待値
1	売上	売上伝票入力のメニューをクリックする	売上伝票入力画面が起動する
2	売上	売上伝票入力で単価と数量を入力する	単価ｘ数量が計算されて金額が自動表示される
3	売上	登録ボタンを押下する	データが登録される
・・・	・・・	・・・	・・・

テストを作成する、と言われたら、テスト手順と期待値を作る作業だと思って差し支えない。

テスト手順の書き方と注意点

テストの操作手順（テスト内容）を書く。期待値は書かない。
自分以外が見ることも考慮して、誰が読んでも同じテストになるように書く。（文言は正確に、略語を使わない、操作を省略しない、etc.）
可能であれば具体的な入力値を記載する。テスト実施時に考えたり判断したりが無いように。

期待値の書き方と注意点

テスト手順の通り操作した結果、「何が」「どうなるべきか」を書く。（「何が」はテスト手順に書く場合もある、読みやすさを考慮して）
テスト結果の判断基準は明確に書く。「正しく登録できる」はダメ、何をもって正しく登録できたと判断するのか不明なので。「登録完了のMSGが出る」ならOK。
憶測で書かない。基本は設計書に書いてあることに忠実に期待値を設定する。設計書に書いていない場合は、設計書の記述不足の可能性あり。
1つのテストで確認する期待値は基本1つにする。そうしないと、どこかでNGが出たとき課題管理に困るので。
可能であれば具体的な出力値を記載する。テスト実施時に考えたり判断したりが無いように。

テストフェーズ（単体／結合／総合）ごとのテスト内容

単体テスト
Vモデルで内部設計（詳細設計）に紐付けられるのが一般的だが、内部設計の定義がプロダクトによって異なる場合があるので、一概には言えない。
文字通りプログラム単体でチェックすべきテスト、実装した内容を確認するテスト、くらいで考えるのが良い。
画面制御、処理結果、登録結果、etc.すべてテストすることになるので、テスト項目数はかなり多くなるのが普通。
結合テスト
外部設計（概要設計）に紐付けられるのが一般的だが（ｒｙ
他PGとの連携を考慮したテスト、テスト手順と期待値確認が複数のPGにまたがるレベルのテスト、くらいで考えるのが良い。
基本的なテストを単体テストで行っているので、単体テストよりは項目数が減るが、ブラックボックステストが絡んでくるのでそれなりの項目数になる事が多い。
総合テスト
要件定義に紐付けられるのが一般的。
運用フローを想定した一連のテストや、インストーラのテスト、性能テスト、などがここに含まれる。
また外部システムとの連携がある場合、実際に連携させるテストをここで行う場合がある。
ここまで来るとテスト項目自体は割りと減ってくるが、そのかわり1項目当たりの内容が重くなる場合が多い。

#漏れのないテスト項目を考える（テストの組合せパターン）
対象プログラムの機能を網羅したテストを実施するためには、入力する値や操作のパターン（パラメタという）を吟味して、適切にそのパターンを組合せてテスト項目を作ると良い。

組み合わせパターンを考えるコツとして、
　1. まず考えうるパラメタをとにかく列挙する。ついでに取りうる値も列挙する。
　2. その後、列挙したパラメタについて、マトリクス（表）に書き出して組合せパターンをもりもり作る。
の2段階で行うと良い。

マトリクスを作る時、縦にパラメタ１、横にパラメタ２、という書き方をしてしまうと２つのパラメタしか組合せられなくなるので、
パラメタは縦か横だけで表現して、もう片方はパターンNoに当てると良い。

例）パラメタを列挙

内税？外税？
税計算は明細単位？伝票単位？締単位？
etc.

例）マトリクスをもりもり作る

No	税計算単位	内税or外税
1	明細単位	内税
2	明細単位	外税
3	伝票単位	内税
4	伝票単位	外税
・・・	・・・	・・・

こんな書き方も

No	1	2	3	4	・・・
明細単位	◯	◯			・・・
伝票単位			◯	◯	・・・
締単位					・・・
内税	◯		◯		・・・
外税		◯		◯	・・・

###組合せパターンの絞込み

組合せパターンはパラメタの数だけパターンが倍々になっていくので、膨大な数になることもしばしば。
そんなときはパターンの削減を検討する。

削減する方法はいくつか考えられるが、ざっくり経験的に削減する方法と、真面目に組合せ手法によって削減する方法がある。

経験的に削減する方法
ホワイトボックス的に考えてこのパラメタは不要だったな、とか、このパラメタとこのパラメタは関連性が薄いから掛け算する必要は無いな、とか、
システムを理解した上でパラメタを見直してしまう方法。
お手軽に減らせるが、ご都合主義で減らしてしまわないように注意。

組合せ手法による削減
直交表やAll-Pair法といった組合せ手法を用いて機械的にパターンを減らす方法。
具体的なやり方をここに書くとそれだけでQiita1記事書けるので、割愛。詳しくはググれば出てくる。

簡単に言うと、たくさんあるパラメタのうち、完全に全部の組合せを網羅する必要は無いよね？ということで減らす。
ただ組合せ手法は、適用できるパラメタの数に制約があったり、ツールを使わないとパターンを作れなかったり、と取っ掛かりにくい面も。

※正直なところ、力技で全パターン実施できる程度の件数なら何も考えずに実施してしまった方がかえってラクだと思う。

#テストデータの作成
ここまででテスト項目を作ることができたら、次に考えないといけないのがテストを実施するために必要なデータを用意すること。

作り方
基本的にはテスト対象のシステムの入力機能で入力するのが基本（本物のデータ）だが、
テストパターンごとにいろいろなデータを用意しないといけなくて、1件ずつ作るのが大変な場合は、DBに直接データを作る場合もある。

単体テストではDBに直接データを作っても許される場合が多いが、結合テスト以降は極力本物のデータを使うようにしたい。

データの中身
データを検討していると、効率的に1つのデータでアレも確認したいコレも確認したい、と欲が湧いてくることがあるが、
それを考え始めると煮詰まってしまう事があるので、何も考えずに1テスト1データで作ってしまう方が結果的にラクな事が多い。

またマスタデータなど名称やコードを設定できる場合は、どういう性質のデータなのか、あるはどのテスト用のデータなのか、を
名称を見てわかるように設定しておくと、テストを実施するにしても、後からエビデンスをチェックするにしても、負担が減る。

テストデータの保存
テストデータを作成することができたら、テストデータもテストの重要な一部なので、テスト項目に記載しておく。
あるいはテストデータの作り方をテスト項目に記載しておく。
（何かの理由で再テストが必要になった場合に、ちゃんと同じテストができるようにする意味がある）

テストを作るときに知っていると良い知識

###ホワイトボックステスト／ブラックボックステスト
テスト項目を作るときに、プログラムの内部仕様を把握した上で（ホワイトボックス）それに従ってテストするか、
内部仕様を考慮せずに（ブラックボックス）入力と出力のみにフォーカスしてテストをするか。

ホワイトボックステストはより少ないテスト数で全機能を網羅できるが、仕様にない部分はテストできない。
ブラックボックステストは全機能を網羅するのは大変だが、仕様の想定外の不具合等も検出できる可能性がある。
テストに応じて適切に選択、あるいは組合せて使うと良い。

ホワイトボックステストの網羅性

ホワイトボックステストは全ての処理を通るようにテスト設計するのはもちろんだが、
プログラムに分岐処理がある場合の網羅についてはいくつかの考え方があり、処理やテストの内容を考慮して使い分ける。

判定条件網羅
分岐条件網羅

例えば以下のようなコードの場合

if ( joken1 == True and joken2 == False ){ 
　・・・
} else {
　・・・
}

判定条件網羅は、文字通り判定条件のパターンを網羅する。
joken1 が True or False の2パターン、joken2 も True or False の2パターンなので、2ｘ2で4パターンのテストを行う。

分岐条件網羅は、分岐だけ網羅できていれば良いという考え方。
joken1 == True and joken2 == Falseの結果で True or False が網羅できていれば良いので、2パターンのテストを行う。

###同値分割と境界値テスト
例えば正の値のみ入力可能な入力項目があったとする。
その項目について入力チェックのテストを作る場合、入力値は以下の2グループにわけられる。

・・・-3、-2、-1
0、1、2・・・

それぞれのグループ内の値であれば、何を入力しても結果は同じになるはずである。
そのためそれぞれの範囲の値を”同値”と見なしてグループ分けすることを同値分割という。

同値分割した上で、テストをする場合はその境界値をテストする。
上記の例で言えば、同値の境界は -1 or 0 なので、テストをする場合、

-1が入力不可であること
0が入力可能であること

の2つをテストする。
<なのか<=なのかが重要な場合は、3つの値でテストする場合もある。

-1が入力不可であること
0が入力可能であること
1が入力可能であること

###その他の用語
正常系／異常系
仕様の想定通りの操作をするテストを正常系テスト、想定外の操作をするテストを異常系テストと言う。
正常系だけでなく異常系も網羅的にテストすることで仕様の考慮漏れや想定外の動作をテストできる。

回帰テスト
今回実装した箇所以外の動きが変わっていないことを確認するテスト。
予想外の場所に影響を及ぼしていないか、デグレードしていないか、など。

実装箇所以外のテストをするのでやろうと思えばいくらでもテストできてしまう。
なのでテスト作成にあたっては必要なテストを程々にやるための勘所が必要。

非機能テスト
性能テストや負荷テストなど、システムの機能以外を評価するためのテスト。
バグを見つけるというより、色々な指標について評価する目的のテスト。
非機能要件として要件定義に書かれていることをテストする事が多いので、総合テストとして実施することが多い。