「自動化するテストを選ぶ」というときに気をつけたいこと #テスト自動化

はじめに

よく「全てのテストを自動化するのは困難」「自動化する/しないを考えるのが大事」と言われます。最初はこの投稿も「どのテストを自動化してどのテストを自動化しないかの選択」について書こうと思っていたのですが、書いているうちにその前段の話を言いたくなってきたのでこっちの話題にしました。

今回言いたいのが

どのテストを自動化してどのテストを自動化しないか、を考えることは、どのテストケースを自動化してどのテストケースを自動化しないか考えることとは別ですよね

ということです。

そりゃそうだ、という方は別にいいのですが、そこ混同している方もたまにいるので、改めて考えてみてほしいなと思っています。

本記事では、システムテストのテスト実行自動化を主なターゲットにしています。他のテストレベルでも当てはまる点があるかもしれませんが、メインはここです。

「テスト自動化」という単語を「今現在手動で行っているテストケースを自動実行できるものにコンバートすること」という意味で使っているのを目にします。こういう考え方をしていると、「自動化率」のような危険な指標が出てきます。

手動でやっているものを自動実行できるようにそのままコンバートすると何が問題なのでしょうか。いくつか例を挙げます。

など、そもそもテストの実行に人間の判断の余地が残っている場合が多いです。

判断の余地が残っていること自体は必ずしも悪ではなく、そのチームが色々考えた結果のテストがそうであったのならば、私は良いと思います。

しかし、多くの場合はそういった意図が無い状態で単にあいまいな書き方になっています。（個人の感想です

そういった曖昧なテストケースやテスト手順をそのまま自動化しようと思うと、都度都度「ここでは具体的にどんな結果になればいいのか」「データはどれを使うのか」など詳細を詰めていかないといけません。

私としては、この手の「既存のテストケースの詳細化」は全く無意味ではなくて、これまでにテスト実行者依存でやってきた部分が明らかになる等のメリットはあると思っています。

が、「テスト自動化＝テスト実行コスト削減」だと考えているチームでこの問題が起きると、「自動化しても手間が増えて実行コスト減らないじゃん」と言って自動化を止めてしまう可能性があります。

自動化の経験はないけれどテスト設計にはこなれてます、という方がテスト設計をすると、無意識のうちに「手動で実行したときの効率の良さ」を考えたテスト設計になっています。

細かい点でいうと、テスト手順書上でのテストケースの並びを工夫して前のケースで使ったデータが次のケースで使えるようにしたり、ログインログアウトやデータ読み込みなどの処理をなるべく少なく済ませるような工夫をしたり、などです。

こういった「手動実行向けの工夫」が、例えばデータ駆動テストをしよう等と考えたときにやりづらかったりします。その結果、実行時間が延びたり、自動テストが安定しなかったり・・・という状況につながっていきます。

5年くらい前は「自動化のROIがー」みたいな話がすごくされていた気がしますが、特に「自動化率」を気にする方が多くいました。

この「自動化率」は私はあまり有効な指標ではないなぁと思っていまして、率というからには全体があるわけですが、その全体が「既存のテスト」でいいの？というのが主な疑問です。

今あるテストがイマイチだったら、それを100%自動化しても、自動でイマイチなテストが実行されるだけです。

また、お金と時間が無限にあるのであれば「100%自動化だ！」とチャレンジしてもいいかもしれませんが、実際にはそんなことはありません。

のざっくり４パターンのうち、仮に上から３つはやったとしても、一番下までやる必要があるのかは考えたほうがいいでしょう。

今あるテストケースのうち、どのケースが自動化できてどのケースが自動化できないのか、を考えるのではなくて、テスト設計もしくはさらに前の段階からどんなテストを自動化するのかしないのかを考えていきましょうね、という話です。

そのへんの具体的な話はyasuaki_hirutaさんの自動テストを考慮したテスト設計　〜概念〜 - Qiitaおよび今後の投稿を読むとわかると思います！（丸投げ）

私もいつも「テストケースで今あるものを自動化するんじゃなくて、自動化ツールやら自動化の知見を含めてテスト開発を行うべきなんですよ」と他人には言っているものの、正直な話体系化までは出来てなくて、「たとえばこう考える」とかポイントでの要素しか持ってない状態です。考えを小出しに公開していくつもりです。

自動化考慮したテスト設計はかくあるべし、的な確固たるものがすでにある方はぜひ公開いただけると嬉しいです。