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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

突然ですが…… 

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

トクバイについて 

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

ダッシュボード活用 

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

さいごに 

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

Happy Testing!