属人化したE2E自動テストをひも解く！改善の道のりとこれから【イベントレポート】
こんにちは！オープンロジでQAエンジニアをしています。honamin です。
2024年12月7日（土）に開催された ソフトウェアテスト自動化カンファレンス2024 にて「属人化したE2E自動テストをひも解く」というタイトルで登壇させていただきました！
登壇では「課題が複雑化したE2E自動テストにどう向き合ったか」「今何に取り組んでいるか」について主にお話ししました。いただいたコメントやご質問への補足も含め、当日伝えきれなかったことを本記事で補完できればと思います。
自己紹介
気がつけばQAに関わり始めて12年になろうとしています。カスタマーサポート＞テスト実行者＞テスト設計者＞QAエンジニアをしてきている人です。途中でカスタマーサクセスやWEBマーケもかじっています。4年程前からテスト自動化に取り組みはじめ、今後しばらくはテスト自動化メインでお仕事をしていく予定です。
登壇のきっかけ
2024年4月時点でオープンロジでE2E自動テストの継続的なメンテナンスを行なっていたのは、QAチームメンバー全8人中1人だけでした。まずその状態を見て「属人化」というキーワードが出てきました。
ノーコードツールも登場し、世の中にプラクティスも増えきている中、数年前よりも格段にE2Eテストの自動化はしやすくなってきていると感じていますが、「知識のある」「経験のある」「実装した」人に担当が偏りやすいという現状があると思います。それ自体が悪いことだとは思いませんが、世の中のQAエンジニア（もしくはテスト自動化エンジニア）の中で、既にテスト自動化が導入されている企業に今後転職をする人も増えてくるのではないか、入社してみたら少数の担当者が一定作りあげた自動テストに遭遇することも多いのではないか、と考え、オープンロジで私が実践したことをお伝えできればと思いました。
登壇の内容
オープンロジにおけるE2E自動テストの道のり
オープンロジでは2018年にE2E自動テストを導入しています。当時は CodeceptJS x Puppetter を利用したコードベースのE2E自動テストを採用しました。
数年運用した後、担当していたエンジニアが転職し、残されたQAチームメンバーに自動テストが引き継がれました。しかし様々な課題が発生したため、2021年にノーコードツールである Ghost Inspector を選定し、再スタートを切っています。
ノーコードツールは何を変えたのか
まずはメンテナンスコストの減少です。直接的に、というよりはメンテナンスコストに含まれる学習コストが抑えられたため間接的に下がった、というのが正しいように思います。コードベースのE2E自動テストを継続的に運用、改善していくためにはコーディングの基礎知識と継続的な学習が不可欠です。
次にテストカバレッジの増加です。新しい機能に対するテストは作りやすくなりました。一方で、現行のリグレッションテストに対しての自動化率についてはそこまで高くなく、まだ理想の姿には至っていないというのが現状です。
QAチーム全体でのメンテナンスについては先に記載の通り、私が入社した時点でE2Eテストのメンテナンスができる人は限られていたため、まだ達成できていません。ノーコードツール＝誰でも使えるというイメージがあるので、意外なところだと思います。
E2E自動テストに対する解像度をあげる
私がオープンロジに入社した当時、E2Eテストのメンテナンス担当者が限定的だったため、E2E自動テストの解像度がQAチームの中でも低い状態でした。
自動テストに限ったことではありませんが担当制をとっている以上、情報の不透明性は少なからずあります。担当者が意識的に透明性をあげていく活動が不可欠だと思います。
不透明なものは何なのかを分解するために、幾つかの要素を調査していきました。
調査して分かったことについては発表時のスライドにまとめていますのでご興味があれば参照ください。
調査から判明した課題の中身と大きさから温度感を定めていきました。※縦軸に意味はありません。
今取り組んでいること・今後取り組むこと
各課題の解像度が上がったことにより、今後取り組むべきことも自ずと見えてきました。
【今取り組んでいること】
目下取り組んでいることはツール選定です。現在利用しているツールの更新頻度が低く、契約更新が迫っていることもあり、それまでには何かしらの選択をしなければならないので大急ぎで進めています。
【今後取り組むこと】
今後取り組むことは以下の3点です。
運用体制の構築
自動テスト戦略の策定と普及
リグレッションテストの自動化率向上＆いつでも気軽に回せるテストへ
ツールの再選定に伴う現行のテストの移行作業や、リグレッションテストの自動化などの実装作業が山のように待っている予定です！（楽しい！）
当日いただいたご質問やコメント
カンファレンス当日にいただいたご質問やコメントに回答します。
◯…質問、コメント
→…回答、感想、補足
◯QAの人は何人くらいなんですか？
→2024/12時点で9名です。
◯E2Eテストでリグレッション観点の不具合が見つかるのは単体・結合（レイヤーのテスト）が少ないかもしれない
→これは本当にその通りです。今回は実装されているリグレッションテストがリグレッションテストとしての役目を果たしているか、という点にフォーカスしました。また、リグレッション観点で見つかるような市場不具合は見当たらないため、リグレッションテスト自体は役目を果たしていると言えます。
一方でリグレッションテストで見つかるような不具合、特にE2Eレイヤーで見つかっているものに関しては、本来であればコンポーネントやインテグレーションテストで見つけられるものが多いとも思っています。ここで見つかった不具合も分析して、各レイヤーのリグレッションテストに反映していければいいなと思います。
もう1点、E2Eレイヤーのリグレッションテストをリリース前のリグレッション期間だけでなく、もっと早い段階で実施できれば、今より小さなフィードバックサイクルを回せるようになると思います。こちらについても取り組みたいことのひとつです。
◯XPath必須なら逆にどのツールにもエクスポート出来ると思うので、逆にそこのポータビリティは良いかもですね
→これはコメントいただいて確かに！と思いました。移植性の観点ではXPathは強いですね・・・！
◯個人的には、やりたいテストを考えたときに、それをなるべく下のレイヤで実装できないか？と考えているかなぁ（テスト戦略からのテストピラミッドの話の時にいただいたコメントかなと思います）
→そうですね！テスト設計している時や不具合の再発防止を考えている時に、なるべく低レイヤーのテストでできないか、は確かに考えているように思います。
◯（QAが実装したE2E自動テストを）開発者に使ってもらう、というところは、開発者たちやマネージャーたちからはどう思われているのでしょうか？
→まだ具体的なことを話しているわけではありませんが、開発チーム内でもE2E自動テストへの関心は高いので、比較的好意的に受け入れてもらえると思います。QAが準備した自動テストを開発段階で取り入れていただく、などできればいいなと考え中です。
◯（E2E自動テストと向き合った際に）既存のE2Eテストシナリオの内容、観点などが分からない、というような話はありましたか？
→テスト自体の話であれば、実装されているテストは対応するリグレッションテストとマッピングされていたので、あまり迷うことはありませんでした。観点についても過不足はあまりない（例えばE2Eテストでフロントエンドのテスト観点をひたすらみているなど）と感じました。
◯定期実行されているリグレッションテスト数はどのくらいのシナリオ数ありますか？
→現行のE2E自動テストはリリース前のリグレッションテストとして、2週間に1度実行しています。実装されているテストシナリオ数は20本ほどですが、”シナリオ”の粒度自体が会社によってまちまちだと思うので、あまり参考にはならないかもしれません。※オープンロジでの”シナリオ”は現状ユーザーシナリオではなく、ひとまとまりで流すテストのことを指しています
◯3時間かけてフレーキーとかになっていないことを祈ってます
→途中のステップで落ちたとしても途中から回し直しができるような設計になっています。また、フレーキーなテスト自体とても少ないです。
その他、現在行っているツール選定について詳しく聞きたい、というお声がちらほらあったので、機会があればまた共有したいと思います。たくさんの質問やコメント、ありがとうございました！また、毎年このような機会を提供してくださるテスト自動化研究会の皆さま、本当に運営お疲れ様です。
We're Hiring!
一緒にテスト自動化を推進してくださる方をお待ちしています！これから2、3年かけてテスト自動化の運用体制を構築したり、ガツガツテスト実装していきます！間違いなく今が一番楽しい時期です！