E2Eテスト自動化の裏話。開発生産性やプロダクト品質の向上を目指して

2023-02-08

LINE株式会社およびヤフー株式会社は、2022年11月17日・18日の2日間にわたり、技術カンファレンス「Tech-Verse 2022」をオンライン（ライブストリーミング形式）にて開催しました。特別連載企画「Tech-Verse 2022 アフターインタビュー」では、発表内容をさらに深掘りし、発表で触れられなかった内容や裏話について登壇者たちにインタビューします。今回の対象セッションは「開発生産性や品質向上を目指してE2Eテストをとことん自動化したら得られたもの」です。

一般的にテスト自動化というと、すでに運用されているプロジェクトのリグレッションテストの自動化を指すことが多いです。しかし、「プロジェクト初期からの自動化」や「リグレッションだけでなくスクリプトテスト全般の自動化」を行うことで、開発生産性やプロダクトの品質が向上するといったメリットがあります。

LINE Fukuoka株式会社のQA Engineering1チームではノンコーディングツールであるMagicPodを活用して、実際にプロジェクトの初めからテスト自動化を推進しました。今回はセッションの発表内容についての秘話を、QA Engineerの奥田浩行にインタビューしました。

MagicPodはノンコーディングかつ多機能なツール

――QA Engineering1チームの担っている役割や、奥田さんの業務内容について教えてください。

私はよくQA Engineering1チームの業務内容を「プラットフォームのQAを担当するチーム」と紹介しています。「LINE関連のシステム」と聞くと、多くの方はエンドユーザーが使うプロダクトをイメージします。ですが、プラットフォームというのはそれらのプロダクトが動く土台となるようなシステムのことです。

例を挙げると、私はセッション内でLINEやヤフー、PayPayなどのID連携プロジェクトを担当していることについて話しました。このプロジェクトでは、ID連携の仕組みを作るチームと、その仕組みを使ってエンドユーザー向けのプロダクトを作るチームの大きく2つに分かれているのですが、前者がプラットフォームにあたります。QA Engineering1チームでは、他にもLINEが提供するWebアプリのプラットフォームのLINE Front-end Framework（以下、LIFF）なども担当しています。

私は3つのプロジェクトを兼務しており、プロジェクトの初期段階から参画して全体な品質戦略の検討からテスト設計、テスト実施などの一連の活動を担当したり、リグレッションテストの自動化を担当したりと、プロジェクトの状況や体制によって働き方がさまざまです。

――セッション内ではノンコーディングのAIテスト自動化プラットフォームMagicPodを使用されている旨を解説されていました。ノンコーディングでテストを自動化できるツールはいくつも存在しますが、他のツールと比較してMagicPodの利点は何でしょうか？

一般的に、コードを書いてテストを自動化するツールは自由度が高いものの非エンジニアにとって利用が難しく、反対にノンコーディングツールはコードを書く必要がないため非エンジニアでも利用しやすいものの実現できることに制約がある場合が多いです。

しかし、MagicPodは利便性の高いツールで、テストに必要な機能をかなり網羅してくれます。「こんな機能があるといいな」と思って調べてみると、実際にその機能が用意されていることが多いです。もしほしい機能が存在しない場合でも、MagicPod社にリクエストを出すとその意見をもとに実装してくれるケースもあります。

それから、MagicPodを導入している企業の事例インタビュー記事などでもよく語られている利点としては、実行回数に制限がないことと、Slack上でMagicPod社の社員へカジュアルに問い合わせができて返事も早いことがあります。

魚を与えるのでなく、釣り方を教える

――セッション内で奥田さんはStudyとLearnの概念の違いについて触れ「計画を立てたらすぐ実行し、そこで学んだことをもとに計画をくり返しアップデートすることが大事」と述べられていましたね。

そうですね。実際に過去の事例でも、数週間かけて綿密に計画を立てた後に実装を始めたらそこで初めて問題に気づいたり、逆にテスト自動化やMagicPodの利用方法について学んだうえで計画を見返すと修正すべき点が判明したりしました。

もちろん計画を立てることは大事ですが、それ以上に実践をしてそこから学び、計画に反映させるサイクルを回すことが重要だと思います。取り組みをスケールさせるフェーズでは入念に計画を立てたうえで実行すべきですが、その前の試行錯誤の段階ではまず積極的に手を動かして、そこから学びを得ていくほうが効率的です。

――世の中には、自動テストの文化がまだ根付いていない会社やチームもあると思います。そういった組織へ自動テストをうまく導入するコツはありますか？

自動テストを導入できていない理由としては「そもそも自動化という選択肢を知らない」「知っているけれど導入に二の足を踏んでいる」「やってみたけれど結果が出なくて途中でやめてしまった」など、さまざまなパターンが考えられます。

私が思う、自動テストの導入を成功させるコツは大きく2つです。まず組織の一部でチャレンジもしくは成功した実績を作り、それを組織の他の箇所に横展開すること。今回の「Tech-Verse2022」のように、プロジェクトで実績を作って、横展開のためにイベントなどで広めるといったのがまさにこのパターンですね。

もうひとつは、組織内でテスト自動化に興味はあるけれどチャレンジしていない人を見つけて働きかけることです。これも、私が実際にやっています。テスト自動化に興味がありそうな人を対象として、MagicPodを活用しているデモを見せたり、テスト自動化の勉強会を開いたりして、組織内に広めるため尽力しています。

テスト自動化の利点をメンバーに言葉で説明するだけでは、なかなか組織全体には浸透しません。そもそも正論を言うだけでメンバーの行動が変わるならば、もっと前からみんなが自発的にテスト自動化に取り組んでいるはずです。

余談ですが、あるYouTubeの動画で著作家の山口周さんとビジネスデザイナーの濱口秀司さんが「組織変革の方法」について議論されていました。そのなかで「成功事例を作れば、後追いでみんなの考えが変わってくる」という話をされており、まさにその通りだなと私も思います。

――セッション内では「SeleniumやAppiumを使ってエンジニアが1人でテストケース作成や保守を行っていたが、それをQAチームでも対応可能にするためにMagicPodに移行した」という旨の発表がありました。MagicPodへの移行初期にチームメンバーが作成したテストケースは可読性や保守性が低かったとのことですが、メンテナンス性に優れたテストにするために、メンバーに対してどのようなフィードバックをされましたか？

もしも、そのメンバーがMagicPodの特定機能を知らないだけならば、「○○という機能があるので、使うといいですよ」と直接的なフィードバックを返していました。ですが、そうでない場合は基本的に直接的なフィードバックをしないように心がけました。「魚を与えるのでなく、釣り方を教えよ」という格言がありますが、それと近い考え方ですね。

「○○の部分をこう直してください」といった類いの直接的なフィードバックを返すと、他のパターンで応用が効かなくなってしまいます。そうではなく、メンバーが作ってくれたものに対して「ここはどのような意図で○○の実装にしていますか？」とか「もしも画面の改修が入った場合、このテストはどのような修正が必要ですか？」などとメンバーに質問をして、なるべくその人自身が改善すべき点に気づけるようにしています。

「プラットフォームのQA」に携わるからこそ身につくスキルがある

――QA Engineering1チームにいるからこそ習得できたスキルはありますか？

冒頭で述べた通りQA Engineering1チームはプラットフォームのQAを担うため、一般的なQAチームと比べるとテクニカルなスキルを求められることが多いです。たとえば認証認可の仕組みなど、Webアプリケーションそのものの基礎知識を学ぶ機会があります。また、画面のテストだけではなくWeb APIのテストを行うことも多いため、システム同士が何の通信をしているのかといったことを理解したうえでテストを設計する必要があります。

他にも、各プラットフォームのテストをする過程で「開発者たちはどういった目的を達成するためにこの機能を活用するのか」「そもそも、その機能は必要十分なものになっているか」などを考えていくことも求められます。それらの業務を通じて、QA Engineerとしてのスキルを伸ばすことができました。

――LINEでQA業務に携わる面白さはどのような点にありますか？

これはQA Engineering1チームに限りませんが、LINEは誰もがチャレンジしやすい環境です。LIFFプロジェクトでは、もともとSoftware Engineer in Test（SET）のメンバーがテスト自動化の実装・運用を担当していたのですが、その人がプロジェクトを離れたことをきっかけにLIFFのQAチームで自動化に挑戦しました。また、「Tech-Verse 2022」で発表した認証認可のプロジェクトマネージャーは手動でのテストを想定していたのですが、私たちが自動化を提案したところ「ぜひやりましょう」と歓迎してくれました。何かの提案をしたときに、やらない理由を探して否定するのではなく、実現する方法をみんなが考えてくれるのはLINEの良い文化だと思います。

それから、LINEは登壇や情報発信のチャンスがたくさんあります。今回の「Tech-Verse 2022」もそうですし、2021年の「LINE DEVELOPER DAY 2021 」でも私は登壇させてもらいました。それから、LINE社内でテストや品質管理の業務に携わっている組織が、年に一回それぞれの拠点で取り組んでいることを発表する「Global QA Workshop」という社内イベントがあります。そうした情報発信の機会が、仕事のやりがいにもつながっています。

――最後に、奥田さんのQA Engineerとしての今後の目標を教えてください。

私の所属するQA Engineering室は、「プロダクトだけでなくプロジェクトの品質も高める」というミッションを掲げています。その目標を達成できるように、今後もさまざまな業務に取り組みたいです。また、セッションでも発表しましたが、最近はE2Eテストの自動化にかなり力を入れており、それを実現するためにも自分自身だけではなくQA Engineering室全員のエンジニアリングスキルを伸ばしたいと考えています。

また、「Tech-Verse 2022」で話をした認証認可のプロジェクトにおいて、2023年からはWeb APIのテストも自動化することを目指しています。プロダクトを開発するエンジニアはユニットテストのテストコードを書き、QAチームがE2Eテストの自動化をしていますが、その中間層の部分に手を出せていない状態でした。

そうした各種の施策をまずは自プロジェクトで取り組み、スモールスタートで成功事例を作っていきたいです。そして、成功事例をもとに他のプロジェクトにも横展開や啓蒙活動を行い、LINE全体の品質向上に貢献していきたいと思っています。