APIテストの自動化対応(Phase.1)
いきなりですが、テスト自動化推進やってます。
イオンスマートテクノロジー CTO室QA の @show_chan です。
テストの自動化への取り組みを進めてたものの1つが運用段階に入ったので、自戒の意味を込めて書いておこうと思います。
テスト自動化の目的
今回弊社にて実施したプロダクトに向けてのテスト自動化の方針・目的は以下になります。
- 自動化テストはリグレッションテストを対象とする
- リグレッションテスト項目の増加に伴う、人為的ミスの軽減を行う
- 継続的なリリースに伴う、頻繁なリグレッションテストの実施を可能とする
- 予期しない変更点、計画外の相違箇所を検出する
- テスト実施結果のメトリクスの自動収集を行う
その中でも今回はAPIテストを優先的に取り組んだ理由は以下になります。
- 弊社はAPIを提供する基盤システムが多いこと
- 機能拡張、追加を伴った開発項目が多いこと
- 変更・改修にともなってAPIの予期せぬ影響が発生した(ことがある)
- 基盤のリリース時にサイト閉塞を伴う時間を短くしたい
テストツールの選定
APIテストツールの選定については、以下を満たすことを確認しています。
- 複数のAPIを順次実行するシナリオが作成可能であり、これを実行することが可能であること
- APIの実行結果を(正常応答か否か、返却された内容が仕様通りか など)検証することが可能であること
- テストデータを複数パターンで設定・用意することができ、シナリオ実行時に選択可能であること
- 実行環境を複数パターンで設定・用意することができ、同一テストシナリオを別環境で実行する事が可能であること
- テストシナリオ、実行環境、テストデータのエクスポートおよびインポートが可能であること
これらを満たすツールとしてApidogを選定しました。
補足として、基盤システム別でAPI定義書の書式相違やメンテナンスがされてないものがあったのですが、ApidogはGUIでテーブルを記入することでAPI定義書が作成可能であることが魅力的でした。テストの実装
導入にあたり現在のリグレッションテスト項目の目的を精査し、テスト項目・内容が、以下の場合はAPI動作テストから除外しました。
- 画面遷移を行うことが確認の目的となっている項目
- 表示内容の確認が目的となっている項目
これらの精査により、項目数ベースにて約50%を自動化可能と判断しました。
さてここからがテスト実装の本番となる訳ですが、実はここからが課題山積でした。
が、ここは一旦課題を列挙するだけとさせていただきます。
- 実装コスト負担
- 対応人員不在
- 対応環境毎のセキュリティ対策
- API定義書の不備に関わる問い合わせ
などなど
実装を行なって運用を行なっていく上で、API自動テストの継続を通して改善点は確認していきますが、
テスト自動化はここで終わりません。第一段階が終わった時点での次の自動化課題が発生してきました。
- 自動テスト実施によるワークフローは未考慮のまま(手動テストと同様)
- APIテストとして、シナリオに沿った正常動作以外も拡張が必要と考えられる
- テスト項目のメンテナンスタイミングの計画を立案する
- E2Eのテストを実施する必要がまだまだ残っている
実装しての感想
実際に、テスト自動化を進めたことで改めて思ったことを記載しておきます。
- 要件がふんわりしているものはテストしても結果はふんわり
- APIのレスポンスってそんなに適当に返して大丈夫なの?フロントでよしなにしてくれてる?
- パラメーターエラーとかちゃんとチェックしてない場合もあるけど、これフロントが頑張ってる?
- APIの自動化だけではやはり物足りない。品質確認のためにはE2Eも不可欠
まだまだ継続的にテストの自動化を適応する領域は広げていきますが、計画時に全ての問題点を解決できるわけではないですし、品質を改善する目的のためのテスト自動化が新たな問題を発生させる可能性をきちんと理解する必要があると再認識しました。
今後
有象無象な課題はありますが、自動化の改善を継続して積み重ねていきたいと思います。
次回は、E2Eの導入または別プロダクトへの横展開について導入が進んだものから発表できたらな。と思っています!
イオングループで、一緒に働きませんか?
イオングループでは、エンジニアを積極採用中です。少しでもご興味もった方は、キャリア登録やカジュアル面談登録などもしていただけると嬉しいです。
皆さまとお話できるのを楽しみにしています!
Discussion