QAエンジニアが「開発者になる」と自動テスト運用は上手くいく

はじめに

こんにちは、ソーシャル経済メディア「NewsPicks」の西薗（X: @yurizono ）です。2021年6月にひとり目QAエンジニアとして入社して以来、テストをしたりQAチームの立ち上げをしたりしています。

この記事は NewsPicks アドベントカレンダー 2023 の16日目の記事です。昨日は @edvakf@github さんによる『データ基盤まわりのシステムの変遷について』でした。

2023年12月09日に、ソフトウェアテスト自動化カンファレンス2023に登壇させて頂きました。講演タイトルは『QAエンジニアが「開発者になる」と自動テスト運用は上手くいく』で、本日はこちらの講演内容を文書に起こし、少し構成などを見直したものをお送りします。

testautomationresearch.connpass.com

このイベントですが、私が2017年に初めて聴講したときは確か Yahoo Japan オフィスでの開催で、聴講者は300名弱でした。2020年以降はオンライン開催となり、今年は参加登録が初めて1000人を突破したとのこと。ソフトウェアテスト自動化、というテーマでこれだけの方が集まるというのは凄いことですね。聴講者層はSET（Software Engineer in Test）一筋XX年という猛者ばかり……ではなく、どちらかというとテスト自動化をやっていきたいがまだできていない、という層が多いイベントとなっています。これから自動テストをやりたい方には手放しでお勧めできるイベントですので、ぜひ来年はご参加くださいませ。

とあるE2E自動テストの話

ニューズピックスにはたくさんのチームが存在します。エンジニアも70名からいますので、それぞれがさまざまなプロダクトの、さまざまな部分に修正を行います。それこそリリースは日に何度も実行されており、朝から晩までリリーススケジュールは取り合いです。対して、QAエンジニアは現時点で2名です。

開発エンジニアに対するQAエンジニアの割合が小さいため、バグ管理やリグレッションテスト管理、高リスクプロジェクトでのQAなどでもういっぱいいっぱいです。それでも元々QAなしで回っていた組織ですので、自動テストはそれなりに存在しており、いくつかの開発チームによって実際に運用されています。そのうちQAが内容を把握し、修正できるのはほんの一部です。今回の話は、まだQAが手を出せていなかった自動テストの話です。

なお、これは一応、自動テストの話ですが、特に技術的な話はしません。

自動テスト運用

サーバーのリリース時に、Canaryで自動テストが動きます。リリースの開始もSlack、自動テストの結果通知もSlackです。動作確認が済んだ後は、Slackからワンクリックで全サーバーへのデプロイが行われます。

今回の自動テストは、WEB APIや、WEBページに対するテストを行ないます。テストケースは130程、実行時間はそれほど長くなく、また安定しています。したがって普段であればリリースの邪魔になることもありませんでした。その証拠に、開発者からも特段の不満は聞こえてきませんでした。

ただこの自動テスト、毎回のリリースで動いてはいるものの、特にオーナーがいませんでした。古くからあるコアな機能、つまりほとんど変更されない機能のテストケースが多かったため、最近では自動テストに変更が入ることも稀でした。たまに変更の必要があると、そのときその場にいた誰かが古いドキュメントを引っ張ってきて、何とかかんとか自動テストを動かし、動作確認をするという状態だったようです。実際、私が修正したときは結構苦労しました。

自動テストが壊れた

ある時期を境に、自動テストの安定性が極端に低下します。しかし先述の通りこの自動テストにはオーナーがおりませんので、誰かが飛んできて直してくれる、ということはありません。リリース担当者が自らなんとかするしかありません。しかしテストは古く、ケースの意図は分からず、ローカルで動作確認するのも一苦労です。できれば修正したくありませんね。

とりあえずリリースを優先した

リリースをしようとして準備し、意気込んでいたところに自動テストが失敗したら、リリース担当者は困ります。困りますが、いまやりたいことはリリースですから、とりあえずはリリースを優先させたい。そのため、以下のようなフローを辿ることになりました。

自動テストが失敗した、という通知がSlackに送られてくる。
Slackメッセージに貼ってあるAWS管理コンソールへのリンクを踏み、テストの再実行ボタンを押す。
自動テストが成功したら、リリースを継続する。（どうしても成功しない場合、手動確認をしてリリースを継続する）

手動確認してリリース、の是非は一旦置いておくとしても、テストの再実行は毎度のように行われるようになりました。それでも何度か再実行すればテストは成功していましたし、実行時間を加味しても待てないほどの時間はかかりませんでした。結果、安定性が低下した後もリリース担当者はみな、失敗率が上がったことは認識しつつも、再実行ボタンを押し続けました。

なぜ直ちに対処できなかったか

生物は、同じ刺激を何度も繰り返し与えられると、徐々に刺激に反応しなくなります。つまり刺激の強さは変わらないが、受けるストレスが減っていく、という仕組みです。これによって、取るに足らない刺激を無視し、より重要な他の刺激に認知資源を活用することができる、というわけです（参考：英語版Wikipedia - Habituation）。この生物の仕組みを、心理学の用語で「馴化（じゅんか）」というそうです。馴化が進むスピードは、例えば以下のような条件に依存します。

刺激の間隔が短いと、馴化が早く進む
刺激が弱いと、馴化が早く進む
刺激が単純（単調）だと、馴化が早く進む

今回のケースに当てはめると、こうなりそうです。

【刺激の間隔が短い】リリース回数が多く、エンジニアが短期間に何度もリリースを行い、その度に自動テストが失敗した。
【刺激が弱い】自動テストが失敗したとしても、通知はSlackで送られてくる上、再実行の指示も2クリック程度で済む。多少の待ち時間は生じるものの、リリース担当者の手間はそれほどではなく、ストレスは小さかった。
【刺激が単純】後で分かったことだが、自動テストの失敗原因は多岐に渡っていた。しかしテスト失敗の通知はいつも同じSlackメッセージで、リリースするにあたり大事なのは成功率が100%だったか否かだけ。失敗を確認して再実行するだけならエラーの詳細を見るまでもない。したがって、リリース担当者から見ればただ「いつもと同様に失敗している」というように見えていた。

平たく言えば、短期間に何度も、似たような形で提示され、またそれをやり過ごす手間も大したものではなかったため、「慣れてしまった」のでしょう。

どうしたか

実はこの最中、全く並行してQAチームでは自動テストに挑戦していました。上記の自動テストとは別に、iOSのE2Eテストの保守・運用をモバイルチームから完全に引き取り、QAチームで今後の面倒を見ていくための準備をしていました。その過程で、「自動テストが失敗したらQAチームにSlackメンションを飛ばす」ようにしました。この通知対象に、先述のE2Eテストも入れました。

すると間もなく、QAチーム宛に1日に何度もSlackメンションが飛んでくるようになりました。QAチームは自分ではリリースを行うことはないのですが、一時的に、「開発者の気持ち」を体験することになったというわけです（タイトル回収）。これで事態を把握したQAエンジニア（私）が、テンパリつつも毎回のリリースに付き合い、自動テストの失敗箇所を特定し、再実行や手動確認の指示をしつつ、徐々に問題の全体像を把握していきました。何日かそんなことを続けていると、いい加減、嫌になってきました。

そしてこの新鮮な気持ちが消えてしまう前に、つまり「馴化が進んでしまう」前に、手元のタスクをなんとか剥がし、対策に乗り出したのでした。結果、なんだかんだ対策を打ったおかげもあり、自動テストは安定していきました。

学び

長年動いてきた自動テストがある日壊れ、それをなんとかした、という体験談を今回の登壇用に整理していく中で、自動テスト運用が「慣れとの戦い」である、ということに気付きました。常に自動テストに困らされている開発者より、一時的に「開発者になってみた」QAエンジニアの方が、より開発者の（当初の）気持ちがわかるものなのですね。自動テストに限らず、リリースフローやインフラ、問い合わせ体制などなど、運用を伴う仕組みをうまく回し、かつ改善を進めていくためには、慣れ、今回の言葉でいうと「馴化」をうまく乗りこなす必要がありそうです。

「不便に馴化する」よりも早く「不便を解消する」を心がけましょう。

提案

……って言われてもどうすればいいのよ、という方のためにひとつご提案を。

自動テストの運用を長期間にわたって行うにあたり、たとえば「自動テストの成功率」「自動テストのカバレッジ」という二つのKPIを用意したとします。SETが一人でこれを追い続ける場合、どちらも同じくらい重要であれば両方をバランスよく追っていこう、いずれは人が増えればそれぞれの担当チームを決めて……というのが王道かなと思います。ただ私自身、特に馴化が早く進む体質、言い換えると飽きっぽい性格でありますので、ずっと目標が変わらないというのはキツイものがあります。

毎日同じ目標に向かってやり続けて習慣化することが何より大切だ、という考え方もありますが、馴化が進んで刺激を得られづらくなることによる弊害も考えられます。であれば、例えば「月ごとにKPIを入れ替えてみる」とどうでしょうか。今月は安定化、来月はカバレッジ向上、その次はまた安定化……というように目指すところを入れ替えることで、「同じ刺激が続くことによる馴化」を抑えることができそうです。

なおこの場合、飽きたら変える、というよりも、あらかじめ期間を切ってシステマティックに変えた方が良いと思います。人間、どうしても現状維持バイアスが働きます。新しい刺激を迎え入れる、言い換えると脱馴化する、ということはストレス増に繋がりますから、自らの強い意志でそこのスイッチができる人間ばかりではないでしょう。

素人の考えたことが上手く働くかは分かりませんが、こういった研究はすでにされているでしょうから、一度、調査してみたいですね。