最近、思うテストのことを書きます。
私のようにテストについて、腹落ちしていない人の手助けになればと。
本内容は、私の経験に基づく、個人的な主観になります。
そもそも、何故、テストをするのか？
システムを使って、意図した通りのことができるか？を確認するため。
意図した通りとは？
業務フロー、操作フロー通りってこと。
そしたら、業務フロー、操作フロー通りにテスト仕様書を書いて、テストすればよい？
フローが全てを網羅していれば、それで良い。
が、現実的には、問題がある。
テスト仕様書を作るに当たっての問題点
フローは、全てを網羅しているわけではない（概略レベル）。枝葉は、書いていない。
要件定義書、設計書に分かれている。
業務フロー
A
↓
B ★ Bの中の細かな話は、要件定義書、設計書に書かれている
↓
C
→業務フローだけなぞっても、ケースが足りない。
テスト実施に当たっての問題点
テスト実施時に、フロー通りだと、手間。
A → B → C → D
Cのテストをするのに、A → Bをやらないといけない。
あれ？じゃあどうするの？
テスト仕様書を作るに当たっての問題点に対してのアプローチ
→ 業務フロー以外に、要件定義書、設計書を見て、単純に増やせばよい。
テスト実施に当たっての問題点に対するアプローチ
→ Cだけ切り出してテストをすればよい
テストっていつする？
最後にまとめてやる？それとも、パーツ単位でやる？
最後にまとめてやると。。
メリット
単体テスト、内部結合テスト、外部結合テスト とかフェーズを分けることなく、テスト仕様書が一本化され、重複するケースが減る。
デメリット
規模が大きいと、テスト仕様書が膨大になり、テスト実施が遅くなり、バグが出たときに死ぬことになる。
細かくやる？
メリット
テスト実施の開始時期が早くなり、バグの検出が早くなる。
デメリット
単体テスト仕様書、内部結合テスト仕様書、外部結合テスト仕様書等、テスト仕様書が沢山増え、ケースの重複が増える。
回帰テストってどうする？
自動？手動？
自動でやると
メリット
改修が怖くなくなる！
デメリット
回帰テスト用のコードを書くため、テスト開始まで時間がかかる。
手動でやると
メリット
テスト開始が早くなり、バグの検出時期が早くなる。
デメリット
改修が怖くなるｗ
まとめ
走り書きのように内に秘めてた内容を整理してみました。
結論としては、回帰テストの自動化は、メリットが大きいと思う。
フェーズ分け（単体、結合、総合）は、単体は必須で、残りは状況次第かな～って思う。