「テストのテスト」問題への解答例 --Google Testing Blog より--

このブログには QA らしいことをほとんど書いていませんが, 私は現在 QA として働いています。
2019 年に現在の会社に入社した時が, QA としてのファーストキャリアなのですが, そのため良く言えばフレッシュな疑問が多々あります。

その中の一つ、「テストのテストはどのようにするべきか」について, Google が Test の知見を書き溜めたくれているブログ, Google Testing Blog が 1つの解答を示してくれており, 目から鱗が落ちたので記録しておきます。

「テストのテストはどのようにすべきか」という疑問について
Google Testing Blog の回答
雑感

「テストのテストはどのようにすべきか」という疑問について

まず「テストのテストはどのようにすべきか」という問いについて書いておきます。

私も試験仕様を作ったり, 既存のテストの自動化を行ったりしているのですが, まれに「試験仕様そのものが誤っていた」「試験自動化コードが誤っていた」ということがあります。

厄介なのは, これらのケースでは終了ステータスやレポートされる結果そのものは「正常終了」となっていることがあり, 仕様や自動化コードを積極的に見直さない限りはこの誤りに気づけないことです。

こうした問題が起きないためにどうすべきかを考えると, まず思いつくのは「テストをテストする」ことです。
「この機能は期待される挙動となっているか」を試すテストに対し, 「このテストは期待される内容をテストするテストになっているか」というテストを作る, ということです。

しかし, こんなことをやっていたら, 当然無限ループに陥ります。
「テストをテストするテスト」を作ったら, 「テストをテストするテストをテストするテスト」を作らなければならなくなります*1。
そして, これにはおそらく終わりがありません。

このため, 「注意深く仕様や自動化コードを作る」「レビューを丁寧にする」といった, 当たり前の回答しか, 自分には思いついていませんでした。

Google Testing Blog の回答

他にもやるべきことはたくさんあるので, この問いを深堀することはできていなかったのですが, 『テストから見えてくるグーグルのソフトウェア開発』を読んでいたら, その中で TotT (Testing on the Toilet)*2 という用語が紹介されていました。

初見だったので調べたところ, Google Testing Blog にたどり着き, そこで目に入った記事にこんなものがありました。

Testing on the Toilet: Tests Too DRY? Make Them DAMP!

大事なのは : の後のサブタイトルの方です。
この記事で書かれていることをかいつまんで書きます (以下筆者かなり意訳)。

自動試験コードにおいては, DRY (Don't Repeat Yourself) 原則よりも DAMP (Descriptive and Meaningful Phrases) 原則を優先しよう。すなわち, コード中の繰り返しを避けたコンパクトな記述をするよりも, 多少冗長でも人間が読みやすいコードを書こう。そうすることで, コードは人間が理解しやすいものになり, コード中の誤りを発見できる可能性が高まる, ひいてはテストの妥当性を守ることにつながる。

小学生が思いつくような回答しか持ち合わせていなかった自分には, とてもおもしろく, ありがたい記事でした。
これにより, 何の対策にもなっていない対策から, 一定以上の合理性を伴った対策を選択できるようになりました。

もちろんこれが絶対解なわけではないし, 金科玉条にするつもりはありませんが, 効果的な方策の一つであることは間違いないのではないかと思います。

雑感

以上, 「テストのテスト」の必要性に悩む人に, ある程度の回答を与えてくれる記事の紹介でした。
知ってる人は知っていることかもしれないですが, 個人的には大変勉強になりました。

この例では自動試験コードへの対策でしたが, 似た考え方を試験仕様にも援用することはできそうです。

原文もとても短く, 重要な部分を居徴してくれてたりするので, ぜひ原文で読んでみてください。
この記事にたどり着くきっかけになった『テストから見えてくるグーグルのソフトウェア開発』も, まだ途中ですがグーグルのテスト文化や工夫の歴史が解説されており, テストチームの現状や改善の取り組みに悩む方にはお勧めできる本だと思います。