テスト稼働の削減とフロントエンドの品質担保を行うE2Eテスト

Transcript

1. テスト稼働の削減とフロントエンドの品質 担保を行うE2Eテスト 川又由雅
2. 自己紹介 • 川又 由雅 • 2018 年入社 • Chat Dealerの開発、運用に携わっています ◦ バックエンド ◦ フロントエンド • 学習、趣味で Vue.js を用いて簡単な SPA を作ったりしていました 2
3. 本日お話しすること • ChatDealer とは • ChatDealer が抱えていた課題について • ↑の課題をE2Eテストによって解決 • E2Eテストにより実際に出た効果 • 今後やりたいこと 3
4. ChatDealerとは • サービス概要 ◦ サイトに専用スクリプトを埋め込んで利用するチャットシステム ◦ ボットを用いて自動的に応答することが可能 4
5. まず前提 5
6. まず前提 • チャットボット（自動応答処理）機能 ◦ エンドユーザからの質問 → 想定した回答を返す ◦ チャットシステムにとってはプロダクトの大前提 ◦ 想定通り動かないのはNG ◦ テストはきわめて重要 6
7. まず前提 • チャットボット（自動応答処理）機能 ◦ ChatDealer は毎月新機能をリリースしている ◦ ほぼ毎回チャットボットに何らかの改善が加えられる ◦ 絶対に不具合を出せないので毎回テストが必須となる 7
8. ChatDealerが抱えていた課題 8
9. ChatDealerが抱えていた課題 • チャットボット機能のテストを手動でやっていた ◦ これがめちゃくちゃ大変 ▪ ケース数が多い ▪ にも関わらず機能がどんどん追加される ▪ その結果ケース数が膨大になっていく 9
10. 実際どんなテストを行っているか 10
11. ChatDealerが抱えていた課題 • 前提条件に関するテストケース ◦ アクション実行のトリガーとなる条件 11
12. ChatDealerが抱えていた課題 • 実行条件に関するテストケース ◦ エンドユーザの情報や環境によるもの 12
13. ChatDealerが抱えていた課題 • アクションの種別によるテストケース • 以上3種類のテストケースをさらに色々なパターンに分岐させて行う ◦ 無人対応 / 有人対応 ◦ 営業時間内 / 営業時間外 ◦ チャットの開き方　　など 13
14. ChatDealerが抱えていた課題 • 全テストケース数：642 個 • テストに 16時間ほどかかっていた • 16時間 × 1年（12か月） = 192時間 14
15. ChatDealerが抱えていた課題 • 加えて、手動でテストを行うとテストケースの漏れが発生する ◦ テストの品質は実施する人によって異なる 15
16. そこで 16
17. E2Eテストを導入 17
18. E2Eテストを導入 • 目的 ◦ テストにとられる稼働の削減 ◦ テストの品質を揃える ▪ テストケースの漏れを防ぐ 18
19. E2Eテストを導入 • 内容 ◦ チャットボットのテストを自動化 ▪ ブラウザ環境を用意して、実際にページにアクセス ▪ HTMLの要素をもとにテスト 19
20. E2Eテストを導入 • 例：メッセージを送信 ◦ チャットボットによるメッセージが送信、表示されているか？ 20
21. 技術スタック、構成 21
22. 技術スタック、構成 • 言語：JavaScript（Node.js） • 開発ツール：Puppeteer 22
23. 技術スタック、構成 • なぜ Puppeteer ? ◦ インストールが楽 ◦ npm コマンドで環境構築が簡単に行える ◦ ブラウザ操作が楽 ▪ ドライバとか別に用意しないくていい ◦ JavaScript で書けるので学習コストがかからない 23
24. 技術スタック、構成 • Selenium を使う案もあった ◦ 色々必要なライブラリやミドルウェアがある ◦ 環境構築が大変そう ◦ 結果 Puppeteer を使用することになった 24
25. 環境準備 25
26. 環境準備 • Node.js のインストール ◦ バージョンは 8 以上を使用する 26
27. 環境準備 • E2Eテスト用のディレクトリ内で npm install 実行 ◦ puppeteer のインストール 27
28. 実行コマンド 28
29. 実行コマンド • すべてのテストファイルの一括実行 ◦ package.json にテスト一括実行用コマンドを設定 ◦ “npm （設定したコマンド）” で実行 ◦ チャットボットの設定などの隙間の時間を省くことができる 29
30. 得られた効果 30
31. 得られた効果 • ChatDealerのチャットボットのテストの工数削減効果 ◦ 16時間 → 2時間程度まで削減！ ▪ 約14時間も削減！ ◦ 毎月リリースで年12回のリリースに換算 ▪ 14時間の削減 × 12か月＝ 168時間 ▪ 1年で 168時間も削減できる！ 31
32. 得られた効果 • 実装にかかった工数：約86時間 • 86時間 ÷ 14時間（テスト1回あたり削減できる時間）= 6.14 … ◦ 7回テストをすれば実装時間の元をとれる！ 32
33. 得られた効果 • リリース前に検知できた不具合 ◦ 詳細については省略 ◦ 特定条件が組み合わさったときにチャットボットが正常に動作しなくな るという「致命的」な不具合 ◦ 発動条件がマニアック ◦ だが、網羅的・自動的にチェックできるE2Eテストのおかげで事前検知 できた！ 33
34. 今後やりたいこと 34
35. 今後やりたいこと • チャットボット以外の機能もE2Eテストで自動化したい ◦ テストを自動化したい機能 ▪ エンドユーザと対話するスタッフ側の機能 ▪ マスタメンテ、レポートなどの管理系機能　　など ◦ ケース数：428個 ◦ テスト工数：1か月あたり 16時間 ◦ 16時間 → 約7時間（約 9時間の削減見込み） ▪ 1年間で 9時間 × 12回 = 108時間の削減効果 35
36. 今後やりたいこと • 不安定なところを解消したい ◦ 原因 ▪ ネットワーク遅延で画面表示前にテストが進行してしまう ▪ JavaScript ファイルが取得できないことがたまにある ◦ テスト待機設定を見直したい 36
37. 今後やりたいこと • リファクタリング ◦ テストを突貫で実装してきた ▪ テストコードが粗くなってしまっている ▪ リファクタリングを行いたい 37
38. E2Eテストを導入してみて 38
39. E2Eテストを導入してみて • 良かった点 ◦ Puppeteer の導入コストがかからなかった ◦ チャットボットの動きはインプット、アウトプットともに文字列 ▪ In / Out の定義が楽 • In：エンドユーザーが送信するメッセージ • Out：チャットボットにより送信されたメッセージ 39
40. E2Eテストを導入してみて • 苦労した点 ◦ 初めて実装したとき Node.js の不明点が多く詰まる ▪ Node.js について学習 ▪ メンバーに質問 ◦ 不安定 ▪ 待機時間を設けて遅延を防ぐ 40
41. ちなみに 41
42. なぜ最初からE2Eテストを導入できなかった？ • プロダクト立ち上げ当初 ◦ テスト駆動で開発しようという計画があったのは事実 ◦ が、リリース最優先のためテスト構築は後回しになった • 今後 ◦ テスト構築コストとランニングコストとの比較を適切なタイミングで行い たい（反省） 42
43. まとめ 43
44. まとめ • E2Eテストは以下のような場面で効果絶大 ◦ In / Out がはっきりしている ◦ 手動で何度も同じようなことをやっている ◦ 定期的にテストタイミングが発生する • 費用対効果が見込める場合はぜひやるべき！ 44