最近、思うテストのことを書きます。
私のようにテストについて、腹落ちしていない人の手助けになればと。

本内容は、私の経験に基づく、個人的な主観になります。

そもそも、何故、テストをするのか？

システムを使って、意図した通りのことができるか？を確認するため。

意図した通りとは？

業務フロー、操作フロー通りってこと。

そしたら、業務フロー、操作フロー通りにテスト仕様書を書いて、テストすればよい？

フローが全てを網羅していれば、それで良い。
が、現実的には、問題がある。

テスト仕様書を作るに当たっての問題点

フローは、全てを網羅しているわけではない（概略レベル）。枝葉は、書いていない。
要件定義書、設計書に分かれている。
　　業務フロー
　　　A
　　　↓
　　　B　★ Bの中の細かな話は、要件定義書、設計書に書かれている
　　　↓
　　　C
→業務フローだけなぞっても、ケースが足りない。

テスト実施に当たっての問題点

テスト実施時に、フロー通りだと、手間。

A → B → C → D

Cのテストをするのに、A → Bをやらないといけない。

あれ？じゃあどうするの？

テスト仕様書を作るに当たっての問題点に対してのアプローチ

→ 業務フロー以外に、要件定義書、設計書を見て、単純に増やせばよい。

テスト実施に当たっての問題点に対するアプローチ

→ Cだけ切り出してテストをすればよい

テストっていつする？

最後にまとめてやる？それとも、パーツ単位でやる？

最後にまとめてやると。。

メリット

単体テスト、内部結合テスト、外部結合テスト とかフェーズを分けることなく、テスト仕様書が一本化され、重複するケースが減る。

デメリット

規模が大きいと、テスト仕様書が膨大になり、テスト実施が遅くなり、バグが出たときに死ぬことになる。

細かくやる？

メリット

テスト実施の開始時期が早くなり、バグの検出が早くなる。

デメリット

単体テスト仕様書、内部結合テスト仕様書、外部結合テスト仕様書等、テスト仕様書が沢山増え、ケースの重複が増える。

回帰テストってどうする？

自動？手動？

自動でやると

メリット

改修が怖くなくなる！

デメリット

回帰テスト用のコードを書くため、テスト開始まで時間がかかる。

手動でやると

メリット

テスト開始が早くなり、バグの検出時期が早くなる。

デメリット

改修が怖くなるｗ

まとめ

走り書きのように内に秘めてた内容を整理してみました。
結論としては、回帰テストの自動化は、メリットが大きいと思う。
フェーズ分け（単体、結合、総合）は、単体は必須で、残りは状況次第かな～って思う。