UbieのプロダクトにE2Eテストを導入して起きたことの振り返り
はじめに
Ubie Discovery組織に所属するQAエンジニアの山口（やまぐち）です。2022年1月21日にUbieに入社して丸3年になります。
その間にいくつかのテスト自動化（*1）にチャレンジして、それらを振り返ってみると良かった点やあまり良くなかった点が見えてきたので、今後に活かすためにまとめました。
（*1）テスト自動化: この記事では、スクリプトによって自動で画面操作を行うE2Eテスト（End-to-End Testing）を指します
今までに作成したE2Eテスト
Ubieのプロダクトは生活者向け（toC）の「ユビーAI受診相談」と医療機関向け（toB）の「ユビーAI問診」があります。それぞれのプロダクトに対してE2Eテストを作成しており、以下のような内容となります。
医療機関向け
toB版E2Eスモークテスト
toB版E2Eシナリオテスト
生活者向け / ユビーAI受診相談
toC版E2Eスモークテスト
名称はこの記事のために便宜的につけたものです。今までに大きく分けて三種類のE2Eテストを作りました。順を追って説明します。
toB版E2Eスモークテスト
Ubieで一番最初に作られたE2Eテストです。このE2Eテストは「ユビーAI問診」というtoBプロダクトのスモークテスト（*2）を行います。原作者は筆者ではないのですが作者から引き継いでメンテナンスを行なっています。
（*2）スモークテスト: この記事では、プロダクトの基本的な機能が動作するかどうかをざっと確認することを指します
目的や用途
「ユビーAI問診」には主に患者さんがタブレットを使って問診を行うための「患者向け画面」と医師や看護師が患者さんの問診結果を閲覧する「医師向け画面」の二つのサービスがあります。
「ユビーAI問診」では「患者向け画面」と「医師向け画面」の二つのサービスが確実に稼働していることが必須になります。それは「患者向け画面」で患者さんが行なった問診の結果をリアルタイムで「医師向け画面」上に表示して閲覧できる必要があるためです。
「患者向け画面」→「医師向け画面」の流れをシンプルなシナリオにしてE2Eテストを作り、Slackと連携することで必ず最後に表示されていなければならない画面が出ているかをコマンド一つで簡単にチェックできるようになっています。
右下の画像がテストの期待値となる「医師向け画面」のスクリーンショットです。この画像が表示されない場合はサービスに何らかの障害が発生している可能性が高いため緊張が走ります。
良かったこと
プロダクトのリリース後（デプロイ後）にサービスに致命的な問題が起きていないかどうかをクイックに確認することができる
手動で確認するより素早く確実に実行できる
Slackからコマンドひとつで実行できて確認もSlack上で行える
補足: 他のメンバーに共有しやすい
コア機能を対象にしているためエラーになると高い確率でサービスに問題が起きていることを知ることができる
手軽に実行できるため、プロダクトのリリース確認だけでなくSREチームによるインフラの設定変更後の疎通確認にも使われている
良くなかったこと
クイックな動作確認という前提だが少し欲が出てプラスアルファの動作確認を追加している
テストの壊れやすさとバランスを取る必要があった
1回の実行時間が長くなりすぎないように気をつける必要があった
度重なるプロダクトの更新によりE2Eテストのコードも更新を重ねて複雑になりメンテナンスが属人化している
各環境に適用されているリリース内容に応じてE2Eテストのコードを変える必要がある
補足: QA環境は最新版で、Stagingや本番環境は一つ前の旧版といったケースが生じる
よって、各環境ごとにコード（ビルド）を分けて保持する必要がある
プロダクトには問題は起きていないがE2Eテストの実行環境やコードの作りの問題でE2Eテストが動作しなくなることがある
補足: 優先順位を上げて対応することが多いため割り込みの作業となってしまう
toB版E2Eシナリオテスト
前述のスモークテストのE2Eテストは問題を抱えながら今でも十分活躍しているのですが、シナリオテスト（*3）の方は一時的に大活躍したものの現在はメンテナンスが困難になり開発が終了しています。
（*3）シナリオテスト: この記事では、利用者が実際にプロダクトを操作するときの手順に沿って画面の操作を行い、問題なく利用できるかどうかを確認するテストを指します
スモークテストのE2Eテストの存在は開発チームに一定の安心感をもたらしましたが、カバーできる範囲が狭いため確認できない機能が多くありました。
そこで、スモークテストのE2Eテストを元にさまざまなユースケースに対応するためのE2Eテストの開発を行いました。
目的や用途
ユーザーシナリオを元にしたE2Eテストの多くは筆者一人で開発していたのですが、2019年4月〜2020年3月くらいまでのコミットの数が多くなっていて、それ以降は急激に減って2021年4月には完全に更新が止まっています。
2019年4月〜2019年8月くらいまではユビーAI問診プロダクトの基本機能を次々に開発しており、2019年9月〜2020年3月ごろに断続的にプロダクトのコードのリファクタリングが行われていた時期になります。
プロダクトのリファクタリングを行なった理由としてはプロダクト初期に積み上げられたコードの状態では今後開発したいと思っている新機能の実装が難しい、または実装に時間がかかってしまうなどの問題が顕在化したために必要との判断で行われました。
合わせて資金調達の話も同時に動いており、そのためには新機能の開発も必要でした。
そのため、以下の三点を維持しながら開発とテストを行なって安全にリリースすることに迫られたので、よりカバー範囲の広いユーザーシナリオベースのE2Eテストを急ピッチで開発する必要がありました。
リファクタリングを行なってもプロダクトに悪影響が出ないこと
新機能も順次リリースすること
本番環境で障害を起こさないこと
これらを守るには人の手だけでは限界があったのでE2Eテストを作るという選択をしました。結果的に資金調達（シリーズB）は成功し、リファクタリングもひととおり完了、新機能も順次リリースできていたのでその効果は大きなものがありました。また、本番環境における大きな障害の発生も未然に防ぐことができました。
最終的には突貫で開発したこともあり、維持にはメンテナンスにはコストもかかるため、「目的は達成された」ということでお役御免（開発終了）になっています。
良かったこと
主要なユーザーシナリオをカバーしており、何度か行われた大きなリファクタリングによる悪影響を本番環境へリリースする前に検知することができた
不具合の再現をほぼ確実に行うことができ、その説明コストの省略や再現手順の簡略化ができた
このユーザーシナリオのE2Eテストを完了させておけば安心という信頼があった
懸念だった三つの「目的」を同時に達成できた
良くなかったこと
E2Eのテストコードは可能な限り共通化を行なっていたが、それでもプロダクトに変更が加わったときのメンテナンスコストがとても大きかった
補足: 一時的にはコストが高くてもその分のリターンはあったのでムダではなかった
開発やメンテナンスが属人化していた
増やしたテストシナリオを維持することにこだわって捨てる判断ができなかった
補足: シナリオは日々増えていって最終的には100件近くなっていた
toC版E2Eスモークテスト
toB版を元に改良を加えたE2Eテストです。このE2Eテストは「ユビーAI受診相談ユビー」というtoCプロダクトのスモークテストを行います。
目的や用途
「AI受診相談ユビー」は、生活者向け（一般ユーザー向け）のプロダクトで誰でも利用することが可能です。いくつかの質問に答えると結果画面で関連する病気や対処法が分かり、近隣の医療機関や診療科情報を見つけることも可能です。
「AI受診相談ユビー」にも開発者が安心して開発とリリースができるようにE2Eテストが必要になり、toB版と同様にSlackからコマンドひとつで実行できて確認もSlack上で行えるようにしました。
右下の画像が期待値となる「結果画面」のスクリーンショットで、この画像が表示されない場合はサービスに何らかの障害が発生している可能性が高くなります。
良かったこと
toB版の教訓を活かして期待値である「結果画面」を表示することに特化した
ランダムでボタンやリンクをクリックする機能を追加したので実行回数を増やすとさまざまな操作バリエーションをカバーできるようになった
toB版と同じく手軽に実行できるため、プロダクトのリリースだけでなくSREチームによるインフラの設定変更後の悪影響の確認にも使われるようになった
SREチームによりスケール化が行われてtoCプロダクトの性能テストに用いられた
性能テストに使われるのは完全に想定外だったのですが自分の作ったコードが活用されたのは単純に嬉しかったです。同時起動数を増やしRPS（Request per Sec.）とエラーレートを監視しながら性能のボトルネックを探したり、性能を向上させるためのチューニングしていたようです
良くなかったこと
このtoC版E2Eスモークテストに関しては良くなかったことはあまり見当たりません。強いて挙げるならコードの作者（筆者）のコーディング能力があまり高くないため、他のメンバーがコントリビュートするときにイケていない作りのために生産性が上がらない可能性がありそう。
他のメンバーが取り組んでいるE2Eテスト
Cypress
Ubie のソフトウェアエンジニアである「sys1yagi」さんがtoBプロダクトに導入しているE2EテストフレームワークのCypress導入の話です。
開発者目線で開発者間のプロダクトの仕様の共有や開発による影響範囲を開発の時点で検出するための試みです。QAを開始する前に問題が検出される可能性が上がりますし、Cypressのシナリオでカバーされている部分はスキップできるので非常に助かっています。
mabl
UbieのQAエンジニアの増原さんが生活者向けの「ユビーAI受診相談」（toC）プロダクトにノーコードE2Eテストサービスの「mabl」を導入した時の記事です。
スピードと品質を両立させて開発者にも学習コストを少なく使ってもらえるツールとして「mabl」を選んでおり、CI/CDのパイプラインにテストを組み込んで、その実行結果をSlack上で開発に関わるメンバーに共有しています。
筆者の作ったE2Eテストツールはコーディング力がある程度必要、かつ属人化も進んでいたので、増原さんの取っているアプローチはこれからUbieの開発チームがスケールしていく上で必要なことだと思っています。
今後のUbieのテスト自動化について
コーディングしてE2Eテスト作る場合でもノーコードのE2Eテストツールを使うにしても「効率よくテストの作成や更新、メンテナンスを行なっていくか」という課題は共通に存在するように感じています。
Ubieでは目的に応じた手段やツールを選び、時には大胆に取捨選択しながら品質目標と向かい合って事業を成長させていきたいと考えています。
スタートアップで医療向けの事業開発を行うことに興味があり、自分の思い描いた方法を大きな裁量を持って実践してみませんか？
UbieではQAエンジニアだけでなく多くのポジションを募集中です。この記事では省略した苦労話やツールの選定の話などもありますので、ご興味がありましたらカジュアル面談（Meety）でお話することも可能ですのでお気軽にお申し込みください。
ユビーAI受診相談
「AI受診相談ユビー」はどなたでも利用できますのでお試しいただければと思います。
この記事が気に入ったらサポートをしてみませんか？