こんにちは！
株式会社LegalOn TechnologiesのLegalForceキャビネ開発部SET（Software Engineer in Test）のひきもち（@rmochioo）です。
昨年8月に入社し、LegalForceキャビネのAPIテスト、自動E2Eテストなどの自動テストの導入、QA業務まで幅広く携わっております。
APIテストに関しては先日、記事出ていますのでご興味があれば見ていただければと思います。
LegalForceキャビネではE2Eテストの自動化ツールとしてmablを利用していましたが、この度Playwrightへの移行を行いました。
現在LegalForceキャビネで運用しているE2Eテストは全てPlaywrightで実行されており、リリース可否判断やQA環境でのマニュアルテストのサポートとして利用されています。
LegalForceキャビネでのQA、SETの関わり方と、自動テストについて
まず初めに、LegalForceキャビネでのQA、SETの関わり方と自動テストがどのように利用されているかについてお伝えします。
QA、SETの関わり方
製品の機能群ごとに開発組織が分かれておりQAもその開発組織に含まれ、開発者と連携してテスト計画から実施までの品質保証業務にあたっています。
また、横断的なポジションとしてのQAもおり、QA組織全体の管理・改善や、機能群から外れる施策のテストも担当しています。
SETも横断的なポジションとして存在しており、機能全体の自動テストや静的解析の基盤作りを行なっています。
リリースフローについて
LegalForceキャビネのリリースフローは以下のような流れになっています。また、移行前後で流れは変わっていません。
- 開発者は開発を行い、テストが可能になった状態でテスト環境にデプロイを行います。
- デプロイ後、自動E2Eテストが走ります。
- 自動E2Eテストの結果確認後、QAがマニュアルテストを行います。
- テストがPassするとステージング環境へのデプロイを行います。
- ステージング環境にて自動E2Eテスト、APIテストが走ります。
- 自動E2Eテスト、APIテストが全てpassし、ステージングでの動作確認がPassすれば本番へのリリースを行います。
テスト自動化戦略について
LegalForceキャビネの自動E2Eテストではリスクベースでテストケースを作成しています。
- 機能の重要度
- 影響の深刻度
これらを機能が壊れた（= 多数の顧客への影響があった）と仮定してS、A、B、C、Dとランク付を行い、上位のランク（自動化による効果が大きいもの）から実装を進めています。
現状はS、A、Bまで実装可能なものは全て実装されています。
また、今後は障害再発防止の観点からもテストケースを増やしていきたいと考えています。
E2Eテストとは
E2EテストはテストピラミッドのSystem Testに含まれるテストになり、システム全体を通してアプリケーションが期待通りに動作するかを確認するテストになります。
E2Eテスト自動化ツールについて
E2Eテストは全て手動で行うとテスト工数が膨大になるため、自動化するツールが普及しています。プログラミングの知識がほとんど必要ないローコードのテストツールと、プログラミングの知識が必要なコードベースのテストツールが存在します。本記事で取り上げている2つのE2Eテスト自動化ツールを紹介します。
mablとは
mablはローコードでE2Eテストを自動化できるサービスです。ブラウザの操作の記録を行いテストケースの作成を行います。機械学習によるオートヒーリングが強力でテストのメンテナンス工数を削減することができます。
Playwrightとは
コードベースのE2Eテスト自動化ツールです。ブラウザの操作だけではなく、要素の出現まで待つAuto-waitなど、自動E2EテストのFlakyさ（失敗しやすさ）をできるだけ軽減するための機能があるのが特徴です。
移行理由
移行する理由は大きく分けると以下の4つになります。
QAのスキルの幅を広げることで、新たな視点からテストが行える
現状のLegalForceキャビネ開発部のQAは開発経験がなく、コードの読み書きやソフトウェア設計の経験がない人も多いです。そのため、ブラックボックステストが中心となります。これ自体は決して悪いことではないですが、プログラミングを通してホワイトボックスの視点を持つことで、実装内容も考慮したより効率的なテストの設計や、システムの裏側まで考慮した品質の作り込みを行えるようになることを期待しています。
コードベースのE2Eテスト自動化ツールであるPlaywrightを利用し、テストコードを開発者と同じように実装していくことをその一歩目にしようと考えました。
GitHub上でレビューができる
また、コードベースの場合はGitHub上でレビューをすることができるため、差分等が確認しやすいだけでなく、開発者と同じフローでレビューを行うことができ、GitHubの利用方法も併せて学習することができるというメリットもあります。
柔軟な実装を可能にしたい
要素指定のカスタマイズや、条件分岐、細かい検証などの柔軟な実装がコードベースの方がしやすいこともあります。
例えばローコードのテストツールの場合実装難易度が高かった以下の操作が、Playwrightでは比較的容易に実装することができました。
アカウント管理コストの削減
mablを利用する場合、アカウントはmabl上で管理されているため、追加や削除依頼があった場合は管理者が対応をする必要があります。
コードベースの場合は、GitHubのアカウント管理をそのまま利用することができるためアカウント管理コストの削減につながります。
移行までの流れ
リリースフローの説明でも記述しているように、自動E2Eテストはリリースフローの一部としてリリース可否判断の役割を担っており、その部分を止めずにPlaywrightに移行する必要がありました。
そのため、以下の段階を踏んでPlaywrightへの移行を行いました。
- PlaywrightのCI連携
- mablとPlaywrightの併用、Playwrightへの書き換え
- Playwrightのみでの運用
1. PlaywrightのCI連携
ローコードテストツールの場合、SaaSでありAPIやCLIも用意されているため、CIとの連携が非常に容易です。ここもローコードテストツールを選ぶ理由の一つになるかと思います。コードベースのテストツールを利用する場合はこの部分は自前で構築する必要があります。
LegalForceキャビネはGCPを利用しているため、テスト実行環境の構築もGCPで行いました。
大まかな構成は以下のようになっています。
- テストコードに変更が入るとGitHub Actionsにより、テストコードを含むPlaywrightイメージがビルドされコンテナレジストリに格納されます。
- 各テスト環境へのデプロイの最後にCloud Run Jobsを発火させ、テスト実行を行ないます。
- 秘匿情報を含むパラメータはSecret Managerから実行時に渡します。
- テスト終了時にテストレポートをCloud Storageに格納し、Slackに結果通知を行ないます。
テスト実行が終われば、Cloud Run Jobsも終了するのでサーバーコストも抑えることができます。
2. mablとPlaywrightの併用、Playwrightへの書き換え
CIによる実行環境が整備できれば、あとはテストケースを書き換えていくだけです。
テストケース自体はそこまで多くなかったため、2週間程度で書き換えを完了することができました。
3. Playwrightのみでの運用
書き換えが完了すればあとは移行するだけなのですが、1点問題が生じました。
Playwrightではテスト実行速度は上がったものの、期待する挙動や要素の出現までの待ちの時間が足らないことによるテストのFlakyさ（失敗しやすさ）が目立ちました。このままではリリースの際にテストが失敗する頻度が増え、リリースの妨げになってしまいます。
ここでは適切にtimeoutを伸ばすことやwaitを挟むことで、テストの安定化に繋げました。
安定して全てのテストが通るようになった段階で、mablを停止し、切り替えを行いました。
移行時の工夫
コードベースのツールを運用する上でボトルネックとなるのは学習コストとメンテナンスコストです。これらをできるだけ軽減するために以下の施策を行いました。
学習コストの軽減
QA向けハンズオンの実施
Playwrightのドキュメントを確認してもらうのではなく、ハンズオンを通して学習してもらう形にしました。
ページ内の要素やセレクタ、ロケータの話から、Playwrightでの操作、検証、メンテナンス工数を減らすためのデザインパターンであるPage Object Modelまで、実際のテストコードを実装しながら学んでいただきました。
現在はQA全員がテストケース実装を進めており、実際の運用にも乗っています。
メンテナンス工数の軽減
Locators APIの利用
Playwrightではv1.27.0よりTesting Libraryから発想を得たLocators APIが導入されました。
従来のXPathやCSS Selectorと比較して、ページの階層構造を気にせずに要素を指定することができるため、より壊れにくい要素の指定ができるようになっています。
基本的にはこのLocators APIを利用する方針にしています。
結果確認の工数を下げる
テストケースを実装する際は、コメントで日本語の手順を必ず入れる運用にしています。これにより、Playwrightから出力されるテストレポートを確認する際にどのような手順で失敗したかを判断しやすいようにしています。
また、テスト結果確認までの手順を少なくすることも心がけています。
以下はSlackへの通知ですが、対応するテストレポートはボタンをクリックするだけで確認できるようになっています。
移行による効果
開発者との距離が縮まった
「コードに触れることでエンジニアのプルリクなども何をしているのか、なんとなく分かるようになってきた。」という声や、「プログラミングを行うことの楽しさが分かってきた。」等の声をQAから頂くこともあり、移行をきっかけに少しは開発者との距離を縮められたのではないかと感じています。
今後は、1つ目の移行理由で期待している効率的なテストの設計や、システムの裏側まで考慮した品質の作り込みに繋げるため、その他の施策も併せて行いながら、引き続き効果を計測したいと考えています。
コスト削減
目に見える効果として一番大きかったのはコストの部分になります。
前述したテスト実行環境の構成では固定費を除くと、テスト1実行（約80テストケース）あたり$0.1以下に抑えられています。
このようにコストに気を使わなくても良くなったため、テストケース追加、実行のハードルも下がりました。
フィードバックの高速化
mablを利用していた頃は、実行コストのこともありQAによるマニュアルテストが完了した段階の最終確認としてmablを実行していましたが、現在はテスト環境へのデプロイが行われた段階でPlaywrightが回っています。
これにより、Playwrightでマニュアルテスト開始前にバグを検知することができ、QAのテスト工数の削減にも繋がっています。
レビュー容易性の向上
レビューの際にGitHubを利用するになったことで差分も確認しやすく、非同期でのレビューがほとんどになり、レビュー容易性の向上に繋がりました。
テストケース数の増加
柔軟な実装ができるようになったことや、テスト実装に携われる人員が増えたことでテストケース数を増やすことができました。現在は80ケースまで増え、mablで運用していた時と比較すると5倍以上になっています。
課題
Playwrightへの移行は無事できましたが、まだ課題もあります。
運用における属人化
mablを利用していた時期にも生じていた課題なのですが、リリース前のテスト結果確認や、テストメンテナンスなどを素早く実施するにはまだまだツールに慣れる必要があり、その部分がまだ属人化してしまっています。
引き続き、テスト実装や運用を通してツールに慣れてもらい、QA全員が運用に加われるような状態を目指しています。
学習コストの高さ
コードベースのテストツールはローコードのテストツールに比べて、当然学習コストは高くなります。これは課題でもありながら1つ目の移行理由でも述べた通り、長期的に見ると価値になるものであるため、許容すべきと考えています。できるだけ学習コストを低くする工夫と、QAが所属するチームに理解してもらうことは必要になります。
メインのQA業務との両立
QA、SETでの関わり方で記述した通り、SETは自動テストの推進をメインに業務を進められますが、開発チームに所属しているQAは担当する機能群に対するテストがメインの業務になっています。その中でコードベースのPlaywrightを導入することは、その業務に負担を掛けることに繋がります。引き続き、負担を軽減するだけではなく、メインのQA業務でも活用できるような状態にするために策を講じていきたいと考えています。
QAメンバーからの声
QAメンバーから頂いたその他のコメントを最後に記載します。
良かったこと
- コードでテストを書くことでテストの確実性が上がったことを実感している。
- 何が原因でテストが失敗したのか分かりやすくなった。
- LegalForceキャビネの機能全体を幅広く検証しているため、簡単なデグレ確認ではマニュアルテストを極力行わない運用に持っていける。
- テストケースが拡充され、プロダクトコードの変更を検知しやすい分、失敗する頻度はmablより多いが、バグの検出率も上がっている。
- mablでのカスタムセレクタ実装の経験があったため、Playwrightでも実装の内容が理解しやすかった。
要改善
- マニュアルテスト開始前の自動テスト失敗時の確認、メンテナンス工数により、マニュアルテストへの着手が遅れることもある。
おわりに
mablからPlaywrightへの移行は、QAメンバーの理解とフロントエンドやSREなど色々なメンバーのアドバイスや協力があってこそ実現することができました。改めて感謝したいと思います。
弊社ではテスト自動化のみならず、質とスピードを向上させるためのチャレンジングな課題がまだまだあります。
もし興味があれば下記の募集要項をご覧ください！
