ユーザーファーストのためのE2Eテスト / E2E testing for users

Transcript

1. ユーザーファーストのための
 E2Eテスト
 MagicPod 5周年記念セミナー 2022/8/5

2. 自己紹介
 岸 健（キシ タケシ）
 ロコガイド技術部品質向上グループ
 QAエンジニア
 メーカー系SI→第三者検証会社を経て、
 2020年12月にロコガイドに入社
 トクバイというアプリを中心にリグレッションテストの 自動化・新機能QA・プロセスの見直しなど色々やっ ています。
 @takeya0x86
 最近のできごと
 高いワークチェアを買ったのですが、納品 が4ヶ月待ち……
 はたして納品まで腰はもつのか！？

3. 突然ですが……

4. ユーザーファースト
 とはなんだろう？

5. ユーザーファースト
 ユーザーファーストとは？
 定義はいくつかありますが、QAエンジニアである私の考えは
 「ユーザーが安心してサービスを使えること。負の驚きがないこと」
 だと思います。具体的には、ユーザーが不具合に遭遇しないようにすることがその一つ だと思っています。
 不具合を防ぐためにできることはいくつかありますが、ここでは
 • 自動テストを活用することで開発の現場がどう変わるのか
 • さらに自動テストを活用するのにどんな方法があるのか
 を紹介したいと思います。
 私の考え

6. 目次

7. 目次
 1. トクバイについて
 2. トクバイにおけるMagicPodの導入
 3. ダッシュボード活用
 4. さいごに

8. トクバイについて

9. トクバイについて
 アプリの解説
 買い物を、たのしく、かしこく
 国内最大級のチラシ・買い物情報サービス 

10. トクバイについて
 アプリの解説
 近くのスーパーやドラッグストアなど のお得な情報にアクセスできるチラ シ・買い物情報サービスです。
 
 Android、iOSでアプリを中心に展 開。
 
 生活者のニーズに寄り添った情報 を提供できるように日々開発をして います。
 
 ウェブ版もあります。
 https://tokubai.co.jp/

11. トクバイにおける
 MagicPodの導入

12. トクバイにおけるMagicPodの導入
 導入前の状況
 • ユニットテスト・APIテストは自動化されて随時実行されている
 • E2Eのリグレッションテストは2週間スプリントの最終日近くに手動で実施
 ◦ 不具合が見つかった場合、修正の時間が少ない
 ◦ 余裕を持った開発ができず、不具合が生まれやすい環境
 導入の背景
 より早い段階での不具合検出が必要

13. トクバイにおけるMagicPodの導入
 メンテナンスの手間がポイント（Appiumでコードを書く場合との比較）
 • スマホネイティブアプリの自動テスト環境は維持が大変
 ◦ Xcodeのバージョンが上がると動かなくなる…… 
 • XPathやidを調べるのが大変
 ◦ ツールで調べて、コードへコピペして…… 
 SaaSならサービス提供側が環境をメンテナンスしてくれる
 ノーコードなら画面のUIをドラッグ&ドロップでシナリオを作れる
 選定の内容
 ほかに、他社での実績も考慮してMagicPodを選択

14. トクバイにおけるMagicPodの導入
 現在はAndroid、iOSのネイティブアプリで活用中
 
 現在の状況
 Android iOS シナリオ数 11 11 実行時間 18分〜23分 50分〜60分 実行タイミング
 CircleCIからトリガー 
 • Pull Requestがマージされた時 
 ◦ 1日あたり4~8回
 • デイリーで夜間実行 
 
 
 実行環境
 • クラウド端末
 ◦ 実行環境のメンテナンスをしなくて良いた め選択
 
 

15. トクバイにおけるMagicPodの導入
 1スプリント2週間あたりのリグレッションテスト実行数 
 導入前との比較
 1回 50回 MagicPod導入で変わったこと
 開発期間の途中にデグレのフィードバックができる 
 デグレの発生はもちろん、発生がないことが早期にフィードバックでき、 より安心して開発ができるように なった。
 リグレッションテストに使っていた時間が空き、余裕ができた 
 新機能のQAなど自動化が難しいタスクに時間が割けるようになった。 
 自動化によって時間の使い方を変えられるようになった。 
 

16. ダッシュボード活用

17. ダッシュボード活用
 ダッシュボードとは 

18. ダッシュボード活用
 自動テストが安定してくると……
 • エラー発生時など個別の実行では結果を見ているが、全体を通して見ることが少な くなっていく
 • 気づかない間に実行時間が増加していたりすることがある
 • 自動テストは随時見直して改善していくことが必要
 • 改善の指標となる数値は継続してウォッチしていきたい
 作成した理由
 数値が一覧できるダッシュボードがあると便利

19. ダッシュボード活用
 ダッシュボードを作ろう
 • 残念ながらMagicPodにはダッシュボード的な機能はまだない……
 • なので自前で作成することにして、それを補助するツールを作成しました
 magicpod-analyzer
 • MagicPodのAPIからデータを継続取得してBigQueryなどに格納する
 • データの格納までで、表示機能は持たない
 • データの表示はRedashやGoogle Data Studioを使用する想定
 • オープンソースで公開
 MagicPodダッシュボード 

20. ダッシュボード活用
 実際にできたもの 
 
 ロコガイドでは数値を見ると きにRedashというBIツール を使用しています。
 
 ダッシュボードもそれに合わ せてRedashで作成。 
 
 AndroidとiOSは同じ項目を 表示しています。
 
 毎週金曜日に朝会でチェッ クしてふりかえりをしていま す。

21. ダッシュボード活用
 実行数（Total）
 その期間に実行したテストの数
 テストケース単位と一括実行の単位 それぞれで集計
 テストはPRのマージ時に実行される ため開発が活発であるほど回数は 増えていく
 数値の解説

22. ダッシュボード活用
 成功数（Success）
 その期間に成功したテストの数
 テストケース単位と一括実行の単位 それぞれで集計
 数値の解説

23. ダッシュボード活用
 成功率（Success Rate）
 その期間のテストの成功率
 テストケース単位の集計をベースに 算出
 下の数値は閾値でこの数値を下回 ると文字が赤色になる
 閾値を下回っている場合、デグレの 発生か仕様の変更が対応されてい ない可能性がある
 
 数値の解説

24. ダッシュボード活用
 平均実行時間（Average of Duration）
 一括実行1回あたりの実行時間の 平均
 数値の解説

25. ダッシュボード活用
 日ごとの実行数・成功数
 （Average of Duration）
 1日あたりの実行数と成功数をグラ フで表示
 日ごとの開発の活発さとテストが失 敗した時期がわかる
 数値の解説

26. ダッシュボード活用
 成功率
 順調に成功している。
 数値からわかること 

27. ダッシュボード活用
 平均実行時間
 実行時間が1時間に届こうとしてい る。
 なにか手を打たないとフィードバック の速度に問題が発生しそう。
 数値からわかること 

28. ダッシュボード活用
 日ごとの実行数・成功数
 7/11に多くのテストが失敗してい る。
 この日の開発で仕様変更があり、テ ストの修正が必要になったが、完了 までに何回か実行された。
 この状態が長く続くとしたら、自動テ ストのメンテナンスが追いついてい ないといえる。
 
 数値からわかること 

29. ダッシュボード活用
 まとめ
 自動テストに関する数値を一覧でき るようにすることで、問題に早く気づ いたり、将来の改善点を見つけるこ とができます。
 MagicPodだけでなく自動テストの結 果をまとめた画面を作っておくと便 利です。上手に活用していきましょ う！
 
 まとめ

30. さいごに

31. さいごに
 ユーザーは自分が使うアプリが正常に動作することを期待してい ます。
 自分の期待が外れるという経験をすると、ユーザーはネガティブ な感情を抱きます。
 ユーザーファースト 

32. さいごに
 ユーザーにより良い体験をしてもらうために、自動テストをはじめ 様々なテストを活用してより品質を向上させていきましょう！
 
 なぜテストが必要なのか 

33. さいごに
 今年のJaSST東北で実施したワークショッ プがノベルゲームとなって登場しました。
 プロジェクトへのテスト自動化導入をゲー ムとして体験できます。あなたの選択でプ ロジェクトをHAPPY ENDへ導こう！
 これからテスト自動化を始めるみなさんへ 
 テスト自動化その前に
 https://jasst-tohoku.github.io/gamebook/ 

34. Happy Testing!