フロントエンドエンジニアとQAエンジニアの協働による自動テストを増やす開発プロセス

TechRAMEN Conference 2024で発表した資料です。
https://techramenconf.net/

1. フロントエンドエンジニアと QAエンジニアの協働による 自動テストを増やす開発プロセスの実現 Tech RAMEN Conf 2024 @92thunder 2024/7/27
2. 国定 凌太 @92thunder テックタッチ株式会社のフロントエンドエンジニアとして 全てのWebシステムの価値を向上するサービスを開発 フロントエンドからDevOpsをサポートする取り組みが好き 岡山県の津山高専（旭川と同じく街から離れた坂の上にある） → ソニーデジタルネットワークアプリケーションズ → テックタッチ株式会社（当時創業1ヶ月 1人目社員） 2023年6月に北海道旭川市に移住 好きなラーメン：らーめん玄の醤油
3. デジタルアダプションプラットフォーム (DAP)：テックタッチ • WebサイトにJavaScriptを組み込むことで、 ノーコードでガイドやツールチップでの案内を追加 • JavaScriptスニペット / ブラウザ拡張で提供 DX支援 （社員向け） CX支援 （顧客向け）
4. フロントエンド エンジニア QA エンジニア 自動テストだけで 品質を担保できる？ どのテストが自動化 されているか管理したい 手動テスト前提の テストケースをそのまま 自動化しにくい テスト分析・設計って難しそう 素早く高品質な 機能を届ける！ 💪 自動テストって何？ ⬆ DevOpsを信じる心 🔥❤ ⬆ 様々な課題 Q Aと 対 話 し な が ら １つ ず つ 乗 り越 え て い く
5. 本日のお題目 フロントエンドとQAで自動テストを増やす取り組み 1. 自動テストとは？ QAエンジニアとは？ 📝 2. テックタッチのフロントエンドにおけるテストとは？🤔 3. QAエンジニアとフロントエンドでテストの状況を可視化する 🤝 4. 自動テストが増える開発プロセスの導入 🏃
6. 手動テスト /自動テストとは
7. 手動テスト、自動テストとは 手動テスト - 人が実際にシステムを操作して、期待値通りの結果となるか確認すること 自動テスト - 人が手作業でテストすることなく、プログラムやツールを使って 自動でテストを実行すること - プログラミング言語やアプリ/ブラウザ/APIなどのプラットフォーム向けに 多様なテスティングライブラリ / フレームワークが存在する
8. Playwrightによるコンポーネントテストのデモ - UIモードでコンソールや ネットワークを 確認しながらデバッグ - Headedモードで実際の ブラウザでの動作を確認可能 - page.pause() で途中のUIを確認 - Watchモードでファイルの変更を検 知して自動実行 （2024/7/27現在ではexperimental) デモに使ったリポジトリ https://github.com/92thunder/playwright-ct-react-demo
9. QAエンジニアのお仕事
10. QAエンジニアのお仕事（参考資料： QAファンネル） テックタッチで は今ココ QAのロールをファンネルで表現したもの 組織内での役割の整理などに使われる 出典 ：https://www.slideshare.net/slideshow/quality-management-funnel-3d-how-to-organize-qarelate d-roles-and-specialties/249498558#3
11. テックタッチの開発体制 フロントエンド ReactやTypeScriptを使い、Webフ ロントエンドの開発に取り組む 仕様の策定に関わることも多い QA(品質保証)エンジニア テスト実施だけでなく、開発プロセスの 早期から密に連携し、テスト分析やテス ト設計で品質に貢献する バックエンドエンジニア デザイナー データエンジニア プロジェクト 異なる職能のメンバーが 集まって機能開発💪
12. テックタッチの開発体制 フロントエンド ReactやTypeScriptを使い、Webフ ロントエンドの開発に取り組む 仕様の策定に関わることも多い QA(品質保証)エンジニア テスト実施だけでなく、開発プロセスの 早期から密に連携し、テスト分析やテス ト設計で品質に貢献する バックエンドエンジニア デザイナー データエンジニア プロジェクト 異なる職能のメンバーが 集まって機能開発💪 リグレッションテストの工数 - リリース前に行う手動テストの工数が多い - QAチームだけで自動テストを増やすのが難し い テストのシフトレフト エンジニア主体のテスト活動を増やしたい 開発者のためのテストを超えない テストを書く文化は根付いてきたが、 QAチームが実施する手動テストを減 らすまで繋がらない
13. フロントエンドとQAの共通目標 自動テストを増やすことで 手動テストの工数を減らし 安定したリリースを実現する
14. フロントエンドと QAで 自動テストの分類を揃える
15. どんなテストがある？ - URLからドメインを抽出する処理は正しい？ - 1週間後の日付を算出する処理は正しい？ - アプリを操作してDBに正しいデータが保存されているか？ - UIに意図しない変更が入ってない？ - バックエンドまで繋いだ状態で動作する？ - localhostで起動したサービス/サーバで動作する？ - 実際にデプロイされたサービスが一通り動作する？ - 明日12時に設定したリマインダーが正しく通知されるか
16. どんなテストがある？ - URLからドメインを抽出する処理は正しい？ - 1週間後の日付を算出する処理は正しい？ - アプリを操作してDBに正しいデータが保存されているか？ - UIに意図しない変更が入ってない？ - バックエンドまで繋いだ状態で動作する？ - localhostで起動したサービス/サーバで動作する？ - 実際にデプロイされたサービスが一通り動作する？ - 明日に設定したリマインダーが正しく通知されるか 複数の関数の組み合わせでも ユニットテスト？ UI, 外部API, DBに依存するなら インテグレーションテスト？ E2Eテストで時間差で動作する機能を 動作確認できる？
17. テストスコープとテストサイズによる分類 テストスコープ - 関数、モジュール、アプリといったテスト対象の結合度による分類 - ユニットテスト/インテグレーションテストはチームによってブレやすい テストサイズ - 基準が明確なのでテストスコープと比べて分類がブレにくい - Small: 1プロセスで実行可能 - Medium: 1マシンで実行可能 - Large: 複数マシンで実行可能
18. テストスコープ /サイズを掛け合わせて考えるコスパ 詳しくはt-wadaさんの過去の発表資料を参照してください 🙏 https://speakerdeck.com/twada/automated-test-knowledge-from-savanna-202303
19. なぜテストの分類が必要か - フロントエンド・QAの双方 - テストの分類という共通の定義によって、 テストケースをどのテストで自動化するべきかといった会話が捗る - QAエンジニア - E2Eテスト以外の自動テストを知ることでテストケース分解した後の 自動テスト実行のイメージができる - フロントエンドエンジニア - テストのパターンができるため、テストへの心理的ハードルが下がる - 開発成果に対してどんなテストができているのか整理できる
20. テックタッチのフロントエンドにおけるテストの分類 - ユニットテスト - UIを必要としないロジックのテスト。主に開発者のためのテスト - コンポーネントテスト - ロジックを含むUIコンポーネントを対象としたテスト - バックエンドAPIはモックとして、仮のレスポンスデータを返す - インテグレーションテスト - SPAやブラウザ拡張をビルドした成果物に対してのテスト - バックエンドAPIはモックして、それ以外は実際の動作環境と同じ - E2Eテスト - 実際に動作するバックエンドAPIを使ったテスト
21. テックタッチのフロントエンドにおけるテストの分類 - ユニットテスト：UIを必要としないロジックのテスト - コンポーネントテスト：UIコンポーネントを対象。バックエンド APIはモック - インテグレーションテスト：バックエンドAPIはモック、それ以外は実際の動作環境と同じ - E2Eテスト：実際に動作するバックエンド APIを使ったテスト 分類で大事にしたこと • 分類に迷いにくいようにわかりやすい基準を使う • テストサイズの分類を参考に • QAエンジニアにレビューしてもらいながら作成
22. テックタッチの自動テストでテストのコスパを考える Small Medium Large ユニットテスト Jest ユニットテスト インテグレーション Playwright コンポーネント Playwright インテグレーション E2Eテスト Playwright E2E UIコンポーネントに対して直接テストできる 致命的に遅いわけではないので、 Watchモードも実用的 テストサイズ テスト スコープ 内部でViteでビルドしてPlaywrightでテスト実行するため、1プロセス実行ではない→厳密にはSmallと呼ばないかも
23. テストピラミッド / テスティングトロフィー テストサイズによるテストピラミッド：Smallを増やすとテストのコスパが良い テスティングトロフィー：インテグレーションテストが信頼性とコスト/速度のバランスが良い https://speakerdeck.com/twada/automated-test-knowledge-from-savanna-202305-edition https://kentcdodds.com/blog/the-testing-trophy-and-testing-classifications
24. テストピラミッド / テスティングトロフィー テストサイズによるテストピラミッド：Smallを増やすとテストのコスパが良い テスティングトロフィー：インテグレーションテストは信頼性とコスト/速度のバランスが良い https://speakerdeck.com/twada/automated-test-knowledge-from-savanna-202305-edition https://kentcdodds.com/blog/the-testing-trophy-and-testing-classifications Playwright コンポーネントテストは どちらとしても理に適っている
25. テスト管理ツールの導入と 自動テストの連携
26. テスト管理ツール Qase の導入 - 以前はGoogleスプレッドシートで大量のテストケースを管理していた - QAチームでテスト管理ツール Qase を導入 - メリット - 対象のテストケースが手動なのか自動なのか管理できる - 定期実行している自動テストの結果の一覧を確認できる - JestやPlaywrightなどのテスティングフレームワークと連携できる
27. Qaseの機能紹介：テストケースの管理、登録 https://docs.qase.io/general/get-started-with-the-qase-platform/test-cases テストスイート・テストケースの管理 テストケースの登録 Automation Statusも管理できる
28. Qaseの機能紹介：テストランで実行するテストの管理 https://docs.qase.io/general/get-started-with-the-qase-platform/create-a-test-run テスト実施するケースの決定やアサイン テストの実行状況を確認
29. Qase Playwright Reporter - Playwrightで記述したテストを テストケースとしてQaseに登録できる - テストの実行結果をQase上で 確認することができる https://www.npmjs.com/package/playwright-q ase-reporter
30. 自動テストを増やす準備は整った！ - フロントエンドのテスト分類 - QAエンジニアとフロントエンドで実施しているテストの認識を揃えた - Playwrightでどんな自動テストが実現できるのかわかった - Qaseでのテスト管理 - 手動テストと自動テストの総数がわかるようになった - PlaywrightとQaseの連携 - テストケースの自動化とテストの実行結果が可視化された
31. 自動テストが増える 開発プロセスを実現する
32. テストのシフトレフト シフトレフトとは？ - 開発プロセスの早期にテストに取り組み、品質を高める活動 - セキュリティの文脈で語られることが多いが、 テストやQAとしてもShift Left Testingとしてトレンドになっている 開発プロセス 要件定義 設計 実装 テスト 結合 小さくテスト テスト分析で貢献
33. テックタッチにおけるテストのシフトレフト - インプロセスQAとして、実装と並行でテスト分析 /設計、 テスト可能な粒度で細かくテスト実施 - TIY : QAチームが考案したTIY(Test It Yourself)というテックタッチ社内活動 - 開発者が主体的にテスト活動を行い、品質とアジリティが同時に高まることを期待　 - プロジェクト内のQAメンバーにサポートしてもらいつつ、 テスト分析・設計から開発者が取り組み、テストケースを作成する - https://www.qbook.jp/column/1846.html - TIYによって開発者がテスト活動に直接関わることで、テスト活動への関心が高まる →　実際に後続の取り組みに繋がる
34. TIY(Test It Yourself)とテスト自動化の課題 - テスト分析・設計に深く取り組む負担が大きい - QAのテスト技法はそれだけでお金を稼ぐこともできる職能スキル - 仕様策定から設計・実装まで時間をかけている開発者に さらに工数の負担を増やすことになる - テストケースの手順を作成すると、E2Eテストを前提にしたものとなり メンテナンスコストの低い自動テストに繋がりにくい
35. 手動テスト (E2E)を前提としたテストケースの例 例：ToDoリストアプリ タスクの期日を設定できること 1. アプリケーションのURLを開く 2. タスク一覧のページを開く 3. タスクAを作成する 4. タスクAの詳細を開く 5. タスクAの期日を設定する 前提となる操作が必要 → 他の影響によってテストが故障しやすくなる 対象機能だけでなく、 ページ遷移も動作確認する必要がある コスパ良く自動化するには分解が必要 作成 / 詳細を開く / 期日を設定
36. 仕様から駆動する開発 + TIY 仕様策定 設計 実装 テスト分析・設計 テストケース作成 テスト実施 フロントエンドエンジニアが担当 することが多い テスト技法・工数の 負担が大きい 手動テストを前提とした テストケースはそのまま 自動テストになりにくい 仕様策定で得た知識が 設計に役立つことが多い
37. 仕様から駆動する自動テストへ 仕様策定 設計 実装 テストリスト作成 テストリスト レビュー フロントエンドエンジニアが担当 することが多い 仕様策定で得た知識が 設計に役立つことが多い テストケース 登録 仕様・設計を元に テストしたいことリストを作成 テストリストを元に 自動テストを追加 QAエンジニアに追加すべき観点を教えてもらい 少しずつテスト分析・設計力を向上 QAエンジニアによるテスト分析 /設計やテストケース作成も引き続き並行
38. 実際の例：仕様 →テストリスト →自動テスト
39. 仕様書から駆動する自動テスト - 仕様や設計によってテストリストが生まれ、自動テストに繋がる - メリット - QAエンジニアから見て、テストリストのほとんどがテスト自動化 されるという認識を持つことができる - 自然言語で確認項目を記述するため、フロントエンドエンジニアにとって書きや すい - テストケースは作らず、テストしたいことを元にテストを書くので テストサイズの小さいテストが生まれやすい
40. 自動テストがテストの主役になってきた …！ - QAエンジニアによるテストリストのレビュー、テストリストを元に 自動テスト書いてますよーというコミュニケーションを続けていた - ある日、QAチームからの新機能を対象としたテスト内容のレビューにて - 基本的な機能のテスト 　→ 各チームの自動テスト - 機能全体を通して機能の動作を確認するテスト 　→ QAチームによるシステムテスト、経験ベースのテスト - 自動テストをテストの中心として考えるようになってきた！！
41. 残っている課題：手動テストの自動化 機能の追加時には、自動テストを基本的なテストとして追加できるようになった 既に作成されている大量の手動のテストケースを どう分解して自動テストに置き換えていくか・・・ 手動テスト 🆕 自動テスト 手動テスト 機能 追加 自動テスト
42. 本日の発表のまとめ フロントエンドとQAで自動テストを増やす取り組み 1. 自動テストとは？ QAエンジニアとは？ 📝 - フロントエンドのテストはPlaywrightコンポーネントテストが便利 - QAエンジニアはテスターではなく、品質の改善に取り組む職能 2. テックタッチのフロントエンドにおけるテストとは？ 🤔 - 分類を作ることで、QAとフロントエンドで自動テストの認識を揃えた 3. QAエンジニアとフロントエンドでテストの状況を可視化する 🤝 - QaseとPlaywrightを連携して自動化状況や実行ステータスの可視化 4. 自動テストが増える開発プロセスの導入 🏃 - 仕様→テストリスト→自動テスト という繋がりによって 自動テストをテストの主役に近づけることができた
43. 今日の発表内容の多くは t-wada さんの アウトプットを何度も読んで着想を得て 現場で実践してきた内容です この場を借りてあらためて感謝 🙏 t-wadaさんの資料をたくさん読んで 心の中のt-wadaさんとテストに取り組もう！