この記事はニーリーアドベントカレンダー2024の19日目 その1の記事です。
こんにちは、ニーリーでQA/SETをしている宮内です。 今年の10月に入社し、現在3ヶ月目になります。 アドベントカレンダーに何を書こうか迷いましたが、入社後の最初のメインタスクであるE2Eテスト自動化について携わるのが人生で3回目となるので、過去の経験を振り返りながら意気込みを書きたいと思います！
自己紹介
私は新卒から11年間IT業界で働いており、8年間は開発エンジニア、その後3年間はQAエンジニアとして活動してきました。なぜ開発からQAへ転身したのかについては、また別の機会にお話します（入社エントリーより先にアドベントカレンダーを書いてしまいましたが笑）。
ニーリーでは、開発経験を活かしたくQA/SETというポジションで入社しました。 ただ、SETというポジションの必要性は事業やプロダクトの状況による部分もあり、そもそもSET領域を推進していくかどうかは現在模索中です。その第一弾として「E2Eテスト自動化」に取り組んでいます。
E2Eテスト自動化との出会い
私が初めてE2Eテスト自動化に触れたのは、2020年の開発エンジニア時代でした。 当時はE2Eテスト自動化が今ほど一般的ではなく、ノーコードツールもまだあまり使われていなかったと思います。自動で進んでいく様子を見て現代的ですごいなあ、と感動したことを覚えています。
このプロジェクトでは、WEBプロダクトを対象にLaravel Duskを用いてコードベースで構築しました。エビデンスのスクショ量が多めだったので自動でスクショが撮れるのはとても助かりました。メンテナンス作業はロケータの修正が主だったので、「華やかな自動化」の裏にある地味な作業の重要性を認識しました。
2度目のE2Eテスト自動化
2度目は2021年、モバイルアプリを対象としたプロジェクトでMagicPodを用いてノーコードで自動化しました。非エンジニアでも操作できる点は魅力的でしたが、コードベースを経験していたので処理の柔軟性やバージョン管理がちょっと厳しいかなあと感じました。
クラウド端末を使用してOSのバージョンや多端末対応にも挑戦しましたが、画面サイズが変わってしまうことによるフレーキーテストにはかなり苦戦しました。この時期にはリーダーとして提案や調整も経験をさせていただきました。
これまでの経験を振り返って
E2Eテスト自動化に携わる中で、嬉しかった成功もあれば、悩みや失敗から学んだことも多くありました。
- 成功体験
- 開発チームからの信頼を得て、リリースの安定性を支える存在になった。
- 特にHotfixリリースやライブラリ更新時の基本導線テストで、効率的に品質を担保できた。
- 苦労したこと
- シナリオ設計の迷い: パターンを出そうとすればいくらでも出せる中でのシナリオの選定が大変でした。
- 関係者との期待値の調整: 周りから自動化でなんでもできると思われてしまい、単体試験粒度の確認をE2Eテスト自動化で行うのは実行速度とメンテナンスコストの観点で相性が悪いのに対応し、結果的には着手開始から序盤で対応工数が膨れ上がりすぎて、他のタスクとの優先度を考慮すると止めた方が良いとなり、頓挫してしまいました。。
- 運用負担の増加: フレーキーテストの修正に多くの時間を割かれてしまった。自分はリーダーをやっていましたがメンバーがこのロケータ不備に工数が取られコンテキストスイッチの増加にも繋がることがとても残念でした。
- バグの検知率: リグレッションテストかつテスト工程の終盤に流していたのもあり、バグの検知率は低かったので周りからバグの検知数に期待されてしまうと厳しいものがありました。。
そして3度目となるE2Eテスト自動化
ニーリーでは昨年、手動で行っていたリグレッションテストについて、刷新を行いながらAutifyへ取り込んでリリース頻度を上げる施策を行いました。
↓以前QAチームの関井が登壇した記事。
↓こちらの記事の中でも触れています。 note.nealle.com
ただ、数年間運用していく中で以下の課題が生まれ、現在ツール移行を優先的に進めています。
- 料金体系上、実行頻度を増やしづらい
- 実行速度を上げて開発サイクルの効率を上げたい
- ノーコードツールを使用しているが、現状でもJavaScriptで対応している箇所が多いため、そもそもコードで表現するのも選択肢としてありではないか
ツール選定については予算との兼ね合いもあり難しいところではありますが、現在技術的な検証を進めています。 そして、ただ移行を行うのではなく、過去の経験を活かして未来に繋がる課題解決を行っていきたいと考えています！
- 実際のユーザー行動に近いシナリオ作成
- 過去の経験では機能一覧から対象機能を選んでシナリオを組んでいましたが、開発チームやユーザーの行動分析などを行っているメンバーを巻き込み、実際のユーザー行動により近いシナリオを作成していきたいです。クリティカルユーザージャーニーなども参考にしていく予定です。
- 他のテストプロセスとの役割分担
- 冒頭で記述したように細かい粒度の確認をE2Eテストで行い失敗してしまったことがあるので、適切な粒度で作成していきたいです。
- 静的解析やユニットテストとの役割分担を決め、適切なタイミングでバグを発見できるように設計していきます。
- シナリオの分割
- 現在は冗長で実行時間の長いシナリオがあるので、適切に分割を行っていきたいと思います。
- 実行タイミングの見直し
- 過去の経験では終盤に流すことが多かったので、開発プロセスの序盤で流すことでバグの検知率の向上と手戻り工数の削減を行いたいです。
- ノーコードとコードベースのハイブリッド活用
- せっかく両方を経験した身なので、どちらか一方に寄せ切るのではなく、ハイブリッド的に最適な形を模索したいです。
- 最新の動向を知るために外部イベントにも伺う機会を増やしていきますので、お会いした際にはよろしくお願いします！
最終的にどう着地したかは来年書きますのでお楽しみに！！
最後に
今回のアドベントカレンダーでは、これまでのE2Eテスト自動化の経験を振り返りながら、現在取り組んでいる課題や目標について書かせていただきました。テックブログを書くのは思った以上に大変で、自分の経験を言語化する難しさを改めて感じましたが、振り返ることで多くの気づきを得られたように思います。今後も外部発信をやっていきます！
現在の取り組みはまだ道半ばですが、チームの皆さんと一緒により良いE2Eテスト自動化を実現していきたいと思っています。同じようにE2Eテスト自動化に取り組んでいる方やこれから始める方に、少しでも参考になれば嬉しいです。
最後までお読みいただきありがとうございました！
