”観点”が重複しないこと
ソフトウェアテストにおいて「単体テスト」と「結合テスト」の区別は、
どのような単位でテストするか？
というテスト粒度に依存するといえます。
実際にテストする対象は同じソフトウェア、テストツールが同じこともありますし、テストデータを再利用することだってあります。確認方法や確認対象が同じことだってあるでしょう。
ですが、全てが同じでは２度同じことをやっているだけで、品質は何一つ向上していませんし、新しい保証もされていません。とりわけ理由もなく２度行うことによって得られるのは「自己満足」であり、失うのは「期限までの残時間」「価値のないコスト」そして「信用」です。
とはいえ、何を「単体（1つの単位）」とするかは、システム特性やテスト方針によりさまざまで、一概に「単体テストはこのように実施すべし」とくくって定義できるものでもありません。モジュール単位とするのか、画面単位とするのか、イベント駆動単位とするのかは、プロジェクトで決めればいいこととなります。
しかし、観点が重複することだけは避けましょう。
観点が重複すると、コスト増やスケジュール破綻を招くだけでなく、品質の低下すら起こりえる事態に陥ります。
「え、何度もやった方が品質上がるんじゃないの？」
と思ってしまうかもしれませんが、一般的には全く同じ内容である以上、"上がりもしないし下がりもしない"ものです。
ですが、これらに該当せず、品質が低下するケースもありうるのです。
最終的にソフトウェアテストにおいて求められるスコープ（範囲）は実装したプログラム量と、テスト対象とする量は常に等しくなければなりません。
仮にプログラムの方が多い（テストが足りてない）場合は、その未実施のテスト分だけ品質は保証できていないということになります。先日の東証で起きた事故と同じようなことが発生する可能性を残すことになります。
上図のように、作ったもの全てをテスト対象とするのは、原則として必須です。これは"網羅性確認"の観点からも当然のことです。
単体テストであれば、プログラムカバレッジ(C0/C1)100%とすることで保証でき、結合テストであれば、基本設計で作成するであろうシーケンス図のカバレッジ(C2)を100%とすることで保証できます。
しかし、テスト観点そのものが重複するということは、テスト内容が重複してしまうということです。まったく同じレベルの品質しか保証できないうえに、一度保証できた品質を再度保証しても、冗長コストのみが増幅するだけでメリットがなく、挙句、計画されたスケジュールを圧迫するだけで、マネジメント品質を損ねる結果となってしまいます（ちなみに、マネジメント品質が低下すると、次に直撃で影響を受けるのは、いつの時代も成果物品質となる）。
また、単体テストと結合テストでは異なる手法、異なる角度から確認するため、きちんと理解できていれば同じレベルの品質が保証できますが、見え方、確認の仕方が少し変わると、異なった解釈をしてしまう可能性も出てくるため、結果として品質が低下してしまうリスクを負うことになります。
こうした無意味かつ無価値で、デメリットしかないリスクを"回避"するためには、そもそも最初から
テスト観点を重複させない
ことが重要になってきます。
この重要性が理解できてくると、
・なぜこのテスト工程で、この確認が必要なのか？
・なぜこの確認方法で大丈夫と思ったのか？
・ほかの工程で、（品質が）担保されているのか？
と言った厳しい視点を持つことができるようになります。それだけでおそらくは現在保証できている品質より、格段に品質が上がっていることでしょう。
なぜなら100与えられたテスト実施時間のうち、重複するポイントが20あったとして、それらが改善できれば『20の時間が余って、前倒しに完了する』ことを意味するからです。ですが、そのあまった20をそのまま前倒しにして終わらせるチームやプロジェクトというのは存在しないでしょう。特に日本人はそう言う気質を持っています。
おそらくはあまった20の時間を使って、「他に過不足がないか」「誤ったポイントはないか」を探し、徹底して改善に努めることが多いのではないでしょうか。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。