テストが間違ってたら？

「テストが間違ってたらどうするんだ」

自動テストの話をするとよく言われます。テストが間違ってたらわからないじゃないか。手動テストであれば、注意深く目で確認していれば間違いに気づけると言う主張です。
「目で確認していれば気づける」のは間違いではありません。必ず気付けるわけではありませんが、十分な知識を持った人が、十分な集中力と責任感をもってエビデンスを確認すれば、誤りに気付ける可能性は高いと思います。
品質(主に機能性)を目的とした自動テストでも、それを行う必要があります。それがテストコードのレビューです。

手動テストの場合、テスト実施前に手順や確認項目のレビュー、実施中の確認、実施後のエビデンス確認と、人が確認するタイミング*1が三カ所あります。
これに対し自動テストの場合、テストが書かれた時のみ。実行中は勿論、実行結果の確認に注意はありません。ただ成功か失敗かだけなので。ならば、テストコードのレビューにそれなりに力を割いても良いはずです。

まさかテスト仕様書やエビデンスをレビューしていないなんてこと無いですよね。まさかね。

テストは要レビュー。なのに。

自動テストを実施するとなると、全てのレビューを放棄するかのような話を聞きます。
実際、私が自動テストを行ったプロジェクトのいくつかはテストのレビューを行われませんでした。それなのに「自動テストがあるから大丈夫」とか根拠の無い依存をする状態。これは完全なアンチパターンです。トラブルが起こってからテストコードを見直すと、酷い状態でした。
自動テストは繰り返し行う時は勿論、たとえ一回であっても、実施や結果の確認でのミスは混入しないため、非常に強力な道具です。ですが当然のように万能ではありません。実行や検証は自動でやりますが、テスト自体は従来同様確認する必要があります。

テストコードの可読性

自動テストがレビューされない理由はいくつかあります。

SEはコードが読めない
PGは読めるコードが書けない

残念ながら両方です。プログラミング言語で書かれていると聞いた瞬間、わからないと放棄するSEは実在します。とても読めたものじゃないコードを書くPGにテストコードを書かせても、やはり読めたものではありません。さらに酷いことに、自動テストはプログラムであり、凝ったことが出来ます。と言うかバグらせられます。テストに慣れていないPGの書くテストコードには if や for のようなの制御構文が当たり前のように出てきます。そんなのになるとテストのテストが必要になります。無限ループ怖い。
ゆえに、レビュー可能なテストコードを書く必要があります。自然言語風に記述出来るテスティングフレームワークはその助けになるかも知れません。もしかしたらDSLを使用するのが良いかもしれません。自動生成させるのも一つの選択かもしれません。とにかく、テストコードの可読性を高める必要があります。プロダクトコード以上にです。極限まで可読性の高いコードには、バグが混入する可能性は限りなく低いです。
手動テストがあたりまえの文化の中で自動テストを行うならば、説得力のあるテストコードを記述できるようにならねばなりません。さもなければ、過剰に依存され破綻するか、相手にされないだけです。