「ソフトウェア設計についてのつぶやき」を書き終わった直後に、「ああこれ書けば良かったっ」というのがありました。それはレビューとテストについてです。

（要件定義が大事という貴重なご意見も頂きました。ありがとうございます。もちろん何を作るのかが分かっていなければ設計どころの話ではありません。一応そこはなんとか乗り越えたとして話を続けたいと思います）

ソフトウェア・レビュー

業界によるのかも知れませんが最近レビューというと「ソースコード・レビュー」と考える方が多くてびっくりしています。もちろん「ソースコード・レビュー」は大事ですし、さらにレビューを活かすための方法論も大事だと思います。しかしながら、そもそも何をレビューすれば良いのかを踏み外すと効率的なソフトウェア・レビューにならないのではないでしょうか。

「ソフトウェア設計についてのつぶやき」で、ソフトウェア設計には３つの重要なステップがあると書きました。

分析: 責務を考える
設計: インターフェースを考える
実装: 実装を考える

このうち「ソースコードレビュー」は３番目の実装フェーズのレビューにあたります。つまり、分析も設計も終わっている後工程の成果物のレビューということになります。

テストやレビューが何のために存在しているかといえば、もちろんアウトプットである製品や商品、システムが間違いなく期待通りに動くことを確認・担保するということなのですが、もうひとつ製造プロセス上の重要なポイントが、「間違っていた時、勘違いしていた時、不具合が見つかった時に、素早くローコストで訂正・修正するため」、ということだと思います。
Qiita記事の仕様／設計レビュー手法から下記を引用させて頂きます。

問題が発生した場合の修正コストは、下流工程に行けば行くほど大きくなることが知られています。
特に仕様漏れや設計ミスなどで手戻りが発生すると、プロジェクトの計画に影響を及ぼしかねない膨大な修正コストが発生します。
上流工程で問題を検出し、下流工程での問題発生を未然に防止することがレビューの大きな目的です。

であるならば、レビューはコーディングなどよりも上流工程である分析、設計の段階でを行う方が効率的なのではないでしょうか。

特に実装者と設計者が異なる場合は、実装者が設計の意図をちゃんと汲み取り、基本設計に忠実に実装（詳細設計）を考えているかは、重要なポイントになります。詳細設計書を作成する時間が無い場合でも、できる限りコーディングの前に基本設計者に実装方針の説明をしてアドバイスを貰うこと（ウォークスルーレビュー）は大事だと思います。

ソースコードが言語的に効率的に書かれていないとか、冗長であるとか、コーディングルールに沿っていないとか、Typoがあるとか‼️ はそのあとの問題です。（必要ですよ、必要ですけどね・・・という話）

ソフトウェア・テスト

テストについても同様に違和感を感じることが多いので、それにも簡単にふれておきます。

上の図はhttps://webrage.jp/techblog/v_shaped_mode/より引用しています。ありがとうございます。

これをよくウォーターフォール開発の図と勘違いする方がいます。が、そうではなくて開発プロセスの順番と、設計フェーズとテストフェースの関係を表した図となります。例えばアジャイルのような場合でも、これらのプロセスの一部を切り取ってイテレーションするような視点を持っていると良いのかも知れません。
それぞれの左側の設計と実装フェーズに対して、右側に対応するテストが存在し、そのテストは同じ階層の要件定義、設計、実装などからやるべき内容が導き出されます。

これを簡単に言えば、

テスト=設計
設計=テスト

ということではないでしょうか。

設計書（または要件定義書）に書いてある通りのことをテストするのがテストフェーズです。設計書（または要件定義書）に書いてなければテストはできません。何が正しいかが分からないからです。
テストの観点からプロセスを逆に見てみると、下記のような表になると思います。（内容は思いつき、かつ代表例なのでもっと良い表現があるかと思いますが）

一般にエンジニアは単体テストに注目することが多いのですが、上流工程ではそれ以外の一連のプロセスがすべて下流工程であるテストに直結しているという視点を持つことはが大事なのではないかと思います。

ここまで書いてなんですが、そうは言っても設計書をきちんと書いて行くのは、時間的に、体力的になかなか難しいものがあります。自分への戒めも込めて本記事を書かさせて頂きました。