こんにちは。AWS事業本部モダンアプリケーションコンサルティング部に所属している今泉（@bun76235104）です。
私は2024年3月14日~3月15日に開催されているJaSSTソフトウェアテストシンポジウム-JaSST'24 Tokyoに参加させていただきました。
今回は聴講したセッションのうち、UIからの自動テスト事例2選について私なりの概要やおすすめだと思ったポイントについてまとめたいと思います。
講演者
- 浅黄 友隆 氏（ヒューマンクレスト）
概要
以下はセッションの内容より引用したセッションの概要です。
Webシステムやモバイルアプリの自動UIテストをどう始めたらよいかわからないあなたへ 昨今のアプリ開発において自動テストをしないという選択肢はありません。必須です。 しかし、「ユニットテストは書き始めた」「TDDはしっかり行なっている」状態でも、UIのテスト（E2Eテスト）は、開発の技術スタックにプラスαしないとなかなか始めることができません。 どんな技術を使っているのか？どのように実現しているのか？どんなテストを実行しているのか？ 事例を使ってご紹介します。
発表資料
私なりのまとめ
講演中のメモをベースにしているため必ずしも正しくありませんが、私としては以下のようにセッションの内容を受け取っています。
- 注意
- 自動テストはE2E(UI)テストを対象としてお話されるとのこと
- ここではUnitテストの自動化などは対象外だと思われる
- 誰かを非難するものではない
- 自動テストはE2E(UI)テストを対象としてお話されるとのこと
- 1 自動テストの山
- 最初の山 始める
- 初期構築を素早くできるか？というのがとても大事だと考えているとのこと
- 次の山 継続する
- テストをリファクタリングできるか？ということを考える
- コードだけでなくテストもリファクタリング対象
- フレーキーなテストの解消
- テストケースが増えすぎてテストそのものが価値を届けられるかという見直し
- 最初の山 始める
- 2 環境の変化
- ウォターフォールからアジャイルへ
- イテレーションの中で以下にうまく継続的に回っているか
- 自動テストもやはり必須だと考えているとのこと
- ツールの変化
- 商用ツール → OSS → SaaS
- テストへの期待
- テストは実施するものではなく実行されているもの
- テストはバグを見つけるものではなく、フィードバックを得られるか
- テストそのものの期待も変わってきていると感じているとのこと
- ウォターフォールからアジャイルへ
- 事例の前に共通している技術の話（よく利用される技術の話）
- フレームワーク
- Selenium
- Appnium
- テストフレームワーク
- JUnit
- Cucumber
- などなど
- フレームワーク
- 事例1
- リグレッションテストができていないなど品質面で不安がある
- 不具合やユーザーからの報告で初めて気づくことも
- じゃあ何を自動テストにする?
- テストピラミッドの考えで
- UI ここから始めることに
- Service
- ユーザーに提供している基本的な機能をテストする
- 機能一覧をざっくりスプレッドシートにまとめる
- 機能単位でリスクの大きさや手動コスト、自動コストなどを整理
- テストピラミッドの考えで
- 自動テストを始める
- 最初の1テストケースを回り始めるまで3週間
- すべてのテストケースが作成完了したのが2ヶ月後
- テスト実行は毎日1回
- 裏でバッチが回っているのでそれに影響を与えないようにする
- テスト失敗はSlackへの概要やスクショを送信
- 変化
- スクラムが導入された
- Unitテストの自動化も始まった
- リファクタリングあできるようになった
- とにかく1テストケースが毎日実行されるテスト実行環境を最速で作る
- （私の感想）
- 耳が痛い
- とにかく毎日実行されるのを最初に作っておかないと、後で腰がどんどん重くなるなぁ
- （私の感想）
- 事例2
- カシオさんの事例
- 自動テストの概要
- 対象アプリ
- 本番アプリ
- 開発アプリ
- （リリース直前）
- テスト内容
- 機能テスト
- 284ケース/スイート
- 対象アプリ
- 時計の実機を使えるようにBlueToothでつなげて自動化している
- BlueToothが切れるのをどうやってつなぎ直すかなども大変
- 自動テスト運用で発生した課題
- テスト失敗時の対応が大変
- 原因調査、修正に数時間かかったり
- 1テストケースの実行で10~30分かかることも
- 原因
- 画面単位のテストケースを自動化していた
- 対策
- 自動テスト用にケースを再設計し分割
- もともとは48ケースが、284ケースに（最終的に500ケース）
- 手動のテストをそのまま自動化するのではなく、自動化用に最適化しよう
- 自動テスト用にケースを再設計し分割
- 効果
- テストが安定した
- 原因調査時間を大幅にtん祝で気た
- テストが不安定すぎる
- ちょっとした画面の変更でテストが失敗する
- テストスクリプトの修正が頻発
- 原因
- 長いXPATH、スクロールで変わってしまう
- 対策
- Appniumで認識できるIDをつける
- （私の感想）
- Webの話ですが、SmartHRさんの以下の記事でも似たような対応をしていたなぁと思いました
- E2E自動テストのロケーターの使い分けを考えてみた - SmartHR Tech Blog
- ちょっとした画面の変更でテストが失敗する
- 継続するためのポイント
- 担当者を決める（まずは属人化）
- 失敗テストを放置しない（24時間以内に方針を決める）
- テストを安定化させる（不安定なテストは捨てる）
- （私の感想）
- これを言ってくれることがとても尊いなぁと思いました
- テストの実行回数や実行時間に対してどのくらい失敗するかとかを総合して考える
- 極端な話、絶対に失敗するようなものは捨てるとか
- 一方でリトライして成功するようなら捨てないでとっておくことも
- （私の感想）
- テストのリファクタリングを常に行う
- テストの目的、価値を再構築する
- 開発者や他のメンバーの協力を得る（コラボレーションする）
- テスト失敗時の対応が大変
- 新しい技術を取り入れる
- 10年自動テストを続けているお客様がいる
- 常に新しい技術を取り入れ、安定したテストを目指す
- 昔はWindowsの実機を使ったり
- そこからJenkins導入したり
- 今ならAWSの利用をしたりとか、コンテナ化したり
- 最近の取り組み
- Firabase Test Lab上での自動テストをしたりとか
感想
- こちらの資料も「今何話しているんだっけ？」という迷子になりにくかったです
- [レポート] サイボウズのQAエンジニア育成 #jassttokyo | DevelopersIOと同じようにわかりやすかったです
- 専門家の方から「極端な話不安定なテストは捨てる」というような話をされるのがとても尊いと思いました
- もちろんなんでも捨てるというわけでは無いと思います
- 一方でもしかしたら有用ではないものにしがみついて、本質的ではないところに集中するのは本末転倒だと感じますし
- 個人的に一番好きなセッションになったと思います
- 技術的な話をしつつも背景や意図が明確でとてもわかりやすかったです
6
