この記事はベリサーブ Advent Calendar 2020 - Qiitaの６日目です。昨日はSelenium＋axeでWebアクセシビリティの世界に足を踏み入れる - Qiitaでした。２日連続で伊藤です。どうも。

今日のアドベントカレンダーでなにかこうか決まってないとTwitterでつぶやいたら、にしさんからネタを頂きましたので、タイトルありきで中身を考えてみました。

※TOFU=豆腐で、私がソフトウェアテスト界隈の一部から「豆腐」と呼ばれているという背景があります。豆腐メンタルの豆腐から来ているのですが、「確かに以前は絹ごしだったが、いまでは厚揚げくらいにはなっている」というのが私の主張です。

前提

タイトルはテスト自動化の8原則にかかっています。（おそらく）

これはテスト自動化研究会が公開しているもので、以下のような位置づけのものです。

これらの原則は、どのようなドメイン、プロセス、ツールの現場におけるテスト自動化であっても共通して言える、テスト自動化に取り組む前に留意しておくべきことがら＝原則を、テスト自動化研究会のメンバーによる議論のうえ、絞り込んだものです。これからテスト自動化に取り組まれる方、現在取り組まれている方、これから見直しをされたい方にご参考いただければ幸いです。

私も普段テスト自動化を広める立場としてお仕事をしていますが、テスト自動化は一部バズワードのようになった時期もあり、過度な期待や誤解をうける機会も非常に多くありました。このテスト自動化の8原則は、テスト自動化を行う上でやるべき（そしてやるべきでない）ことや考え方が端的に表されていて、よく引用させていただいています。

今回のものは「４減速」と、原則でなく減速という漢字が当てられています。

自動テストが進まなくなる、もしくは廃れるポイントをT・O・F・Uの4つの頭文字で表してみましょう。

自動テストとテスト自動化

これは厳密な言葉の定義がなく、組織や人によってさまざまな使い分けがなされています。この記事中においては、以下のような定義をします。

  • テスト自動化：ツールなどを用いてテスト実行を自動化すること
  • 自動テスト：
    • 狭義：テスト自動化で作成した、自動で動作するテストそのもの（ソースコード、もしくはツール固有の実行形式）
    • 広義：狭義の自動テストを利用して開発プロセスにおけるテストを行うこと、またそれを継続していくこと

自動化のスコープ

システムテストレベルを主に想定します。元ネタになっている「テスト自動化の8原則」を公開しているテスト自動化研究会も、

主としてV字モデルにおけるシステムテスト以降のテストタイプの自動化を研究対象とする

としているためです。

あらためて、今回書くこと

広義の自動テスト、「自動テストというテクニックではなく、自動テストというカルチャー」を「減速」させる要因について書きます。

（おそらく、固定秒数の待機を乱用すると自動テストが遅くなるとかそういうミクロな話のつもりで振られたネタではない、と思っています。）

自動テストの４減速：TOFU

（わりと無理やりあてました）

Tiredness（疲れ）

1つ目はTiredness、疲れです。

自動テストに限らず、アジャイルのアクティビティでも何でもそうですが、実践している人たちが効果を実感できていないと続きません。自分にとってメリットがあると思えないままに自動テストをなんとか生かし続ける、ような状態になると、自動テストは廃れていきます。

過去に聞いたことがあるのは、以下のようなケースです。

  • 「テストチーム」なる4名が手動テストでこなしていたところに、自動テストを導入した
  • テストケースの何割かが自動化できた（つもりになった）
  • テストチームが1名に減らされ、残った1名は自動テストをひたすら回してFailしたケースを調査＆修正することになった

テストチームの上司は「テストのコストを削減しました！」という報告をして、評価されるかもしれません。

が、このあとにテストが崩壊する予感、しますよね。結局「自動化によって効率がよくなった」ように見せかけて、自動化を理由に残った1名に負担を全部のせしただけという状態です。 この先待っていそうなシナリオとしては、自動テストのメンテナンスが追いつかず、結局手動でカバーする日々が続く。残業続きでまともなテストもできず、不具合が見逃され、重大な不具合を残したままリリースされてしまう、でしょうか。

実際に自動テストを使うエンジニアが効果を実感できず、自動テストのせいで逆に疲れていってしまうような状況にもしあるとすれば、一刻も早く手を打たなければいけません。

関連する8原則

    1. 手動テストはなくならない
    1. テスト自動化の効用はコスト削減だけではない
    1. 自動テストシステムの開発は継続的におこなうものである
    1. テスト結果分析という新たなタスクが生まれる

これらを忘れていると、自動テストがあるせいで辛い、という状態になってしまいます。

Obstacle（障害）

自動テストを続けるための障害があると、当然ながら次第に減速していきます。

細かいものも含めると障害はたくさんありますが、たとえば以下が考えられます。（それぞれ完全に独立しているわけではなく、密接に関わり合っています。）

  • 周囲の無理解（特に、過度な期待やノルマ）
    • 「自動化ってことはテスターは要らないんだよね？」
    • 「一度自動化したらあとはもうほっといていいんだよね？」
    • 「自動テストやってるのにバグ発見率が上がらないんじゃ意味ないよ」
  • 抵抗勢力の存在
    • 「自分プログラム書けないので自動化とかできません」
    • 「仕事がなくなるのは嫌です」
    • 「手作業の温かみ！１セル１セル感謝の気持ちを込めてテスト結果を記載すると品質が上がる！」（※冗談です）
  • 割り込み
    • 「きみ、コードが書けるなら開発のほうやってよ」

関連する8原則

8つ全部ですね・・・

Fragmentation（分断）

3つ目の減速ポイントは分断です。（単語の意味だけで引っ張ってきたので変だったらおしえてほしい）

自動テストまわりで「分断」が起きる箇所がけっこうあります。

たとえばテスト考える人と自動化する人がスパっと分かれる場合。

テストを考える人は（CPM法などでなければ）何らかの意図を持ってテスト設計を行います。それを具体的な手順に落とし込んでツールで自動化する際に、もともとのテストの意図がすっぽり抜け落ちてしまう、ということがあります。その結果、自動テストをパスしているにも関わらずリリース後に不具合が出たりします。「やばい、協力して再発を防ごう！」となるチームなら良いのですが、テスト設計者が「そのくらいわかるだろ」、テスト自動化エンジニアが「ちゃんと書かなきゃわからないだろ」と争いになる、という可能性も。

他にも、

  • 「手動テストチーム」と「自動テストチーム」がいて、それぞれ何やってるかわからない
  • APIテストとGUIテスト、別々に自動化されていて他方がどんなテストをしているかわからない

など、謎の壁で分断されてしまうと、一見自動テストがうまくいっているように見えても、全体として見るとだんだんと良くない状態に向かっていっている、というケースはちょこちょこ見受けられます。

関連する8原則

    1. 自動テストは書いたことしかテストしない
    1. 自動化検討はプロジェクト初期から

他のも関わってきますが、特に上に挙げたエピソードに関係するのはこのへんでしょうか。

手動であれば人間が空気を読んで、ついでに、見ていたようなポイントについて自動テストが見逃してしまうということはよくあります。 特に手動テスト用に設計したケースを自動テストに単純コンバートしようとすると、観点が抜け落ちがちです。

こうした事態や、そもそも分断自体を防ぐために、プロジェクト初期段階から自動テストを行う前提で進めておくことが有効です。

Unbelievable（信じられない）

英語では肯定的に使われることが多いような気がしますが、ここでは「信用できない」という意味で通します。

自動テストが信用できなくなると廃れていきます。

大きく2通りの「信用できなくなるパターン」が考えられます。

一つは「自動といいつつ自動でない」パターン。これは、自動テストを実行しても行いたかった動作の途中で止まることが多く、結果的に人手での介助が頻繁に発生する場合です。 自動テストのメンテナンスをしたことがある方は経験があると思いますが、退勤前に実行設定した自動テストが翌朝出勤してみると半分も終わらずに失敗していた、なんてことは（特に自動テストの導入直後は）よくあります。Windowsや組み込みなんか特に。

次第に安定してくればいいのですが、あまりにもずっとこの「実行しても完遂できない」状態が続いてしまうと、周りからは「自動テストなんていってるけど、結局使い物にならないじゃないか」と思われてしまい、協力が得づらくなってしまいます。

もう一つは「自動で動くけれども結果が信用できない」パターン。特に、人間が判定するとOKなのに、自動テストだとNGと判定されることが続くと、だんだんと「どうせ実際にはOKなんだろう？」と思われるようになります。そうなったころに、自動テストがNGと判断した不具合がするっと見逃されてしまい・・・

実行が最後まで完遂できる自動テストだったとしても、判定結果が不安定で信用に足らないと、こちらも「使い物にならない」と判断されてしまいます。

関連する8原則

    1. 自動テストシステムの開発は継続的におこなうものである
    1. テスト結果分析という新たなタスクが生まれる

信頼できる自動テストにするためには継続的な開発が必要で、テスト結果分析における「本当はOKだけどNG」やその逆を可能な限り減らす取り組みをしないと、信用を得られません。

まとめ

わりと強引にひねり出した感はありますが・・・

記載している「よくある失敗パターン」的なものは実際に自動化した方にとっては「あるある」だと思っています。

テスト自動化の8原則を参考に、テスト自動化の4減速：TOFUを避けて、みんながHappyになる自動テストを作って使っていきましょう。

参考