開発者とQAの越境で自動テストが増える開発プロセスを実現する

ソフトウェアテスト自動化カンファレンス2024 で発表した資料です。
https://testautomationresearch.connpass.com/event/333442/

Transcript

1. 開発者とQAの越境で 自動テストが増える開発プロセスを実現する ソフトウェアテスト自動化カンファレンス2024 @92thunder 2024/12/07
2. 国定 凌太 @92thunder テックタッチ株式会社のフロントエンドエンジニアPOとして 全てのWebシステムの価値を向上するサービスを開発 🆕 2024年12月からプロダクトオーナーになりました！ 岡山県 津山高専 → ソニーデジタルネットワークアプリケーションズ → テックタッチ株式会社（当時創業1ヶ月 1人目社員） 2023年6月から北海道旭川市に移住 🆕 10月に家を建てたので東神楽町に引っ越した
3. なぜ自動テストが増える開発プロセスを目指すのか - 主な機能追加リリースは3ヶ月に1度に留まっていて、リグレッションテスト手動テストから自 動テストに置き換えることで顧客に価値を届ける頻度を向上できる見込みがあるため（組 織） - フロントエンドとして機能開発をしながら、クオリティチームという品質向上を担うサブチーム 活動に取り組んでいるため（チーム） - DevOpsを信じる強い心があるため 変化を味方につけて顧客に確かな価値を届けたい（自分） - > DORA’s research shows that it also drives improved software stability, reduced team burnout, and lower deployment pain. DORA | Capabilities: Test automation
4. テックタッチにおける テスト自動化の課題
5. デジタルアダプションプラットフォーム (DAP)：テックタッチ • WebサイトにJavaScriptを組み込むことで、 ノーコードでガイドやツールチップでの案内を追加 • JavaScriptスニペット / ブラウザ拡張で提供 DX支援 （社員向け） CX支援 （顧客向け） ※1 弊社調べ、MAU換算 ※2 出所：株式会社アイ・ティ・アール「ITR Market View コミュニケーション/コラボレーション市場2023」 「デジタル・アダプション・プラットフォーム市場:ベンダー別売上金額推移およびシェア(2021～2023年度予測)」 ※1 ※2
6. テックタッチの開発体制 フロントエンド ReactやTypeScriptを使い、Webフ ロントエンドの開発に取り組む 仕様の策定に関わることも多い QA(品質保証)エンジニア テスト実施だけでなく、開発プロセスの 早期から密に連携し、テスト分析やテス ト設計で品質に貢献する バックエンドエンジニア デザイナー データエンジニア プロジェクト 異なる職能のメンバーが 集まって機能開発💪
7. テックタッチの開発体制 フロントエンド ReactやTypeScriptを使い、Webフ ロントエンドの開発に取り組む 仕様の策定に関わることも多い QA(品質保証)エンジニア テスト実施だけでなく、開発プロセスの 早期から密に連携し、テスト分析やテス ト設計で品質に貢献する バックエンドエンジニア デザイナー データエンジニア プロジェクト 異なる職能のメンバーが 集まって機能開発💪 リグレッションテストの工数 - リリース前に行う手動テストの工数が多い - QAチームだけで自動テストを増やすのが難し い テストのシフトレフト エンジニア主体のテスト活動を増やしたい 開発者のためのテストを超えない テストを書く文化は根付いてきたが、 QAチームが実施する手動テストを減 らすまで繋がらない
8. QAファンネルから見るテックタッチの QA テックタッチで はココに取り 組んでいる QAのロールをファンネルで表現したもの 組織内での役割の整理などに使われる 出典 ：https://www.slideshare.net/slideshow/quality-management-funnel-3d-how-to-organize-qarelate d-roles-and-specialties/249498558#3
9. TIY(Test It Yourself)というテックタッチの社内活動 - TIY : QAチームが考案したTIY(Test It Yourself)というテックタッチ内の活動 - 開発者が主体的にテスト活動を行い、品質とアジリティが同時に高まることを 期待　 - QAメンバーにサポートしてもらいつつ、 テスト分析・設計から開発者が取り組み、テストケースを作成する - 持続可能なQA開発のために - https://www.qbook.jp/column/1846.html - TIYによって開発者がテスト活動に直接関わることで、テスト活動への関心が高ま る →　実際に後続の取り組みに繋がる
10. TIY(Test It Yourself)とテスト自動化の課題 - テスト分析・設計に深く取り組む負担が大きい - QAのテスト技法はそれだけでお金を稼ぐこともできる職能スキル - 仕様策定から設計・実装まで時間を使っている開発者に さらに工数の負担を増やすことになる - テストケースの手順を作成すると、E2Eテストを前提にしたものとなり メンテナンスコストの低い自動テストに繋がりにくい
11. 手動テスト (E2E)を前提としたテストケースの例 例：ToDoリストアプリ タスクの期日を設定できること 1. アプリケーションのURLを開く 2. タスク一覧のページを開く 3. タスクAを作成する 4. タスクAの詳細を開く 5. タスクAの期日を設定する 前提となる操作が必要 → 他の影響によってテストが故障しやすくなる 対象機能だけでなく、 ページ遷移も動作確認する必要がある コスパ良く自動化するには分解が必要 作成 / 詳細を開く / 期日を設定
12. 継続的な開発に求められる自動テストとは - QAエンジニアが信頼できる自動テストになっていること - 自動テストに任せても良い、と思える文化が育っていないと手動テスト中心の開発プ ロセスになる - テストケースと自動テストが連携できていること - 連携されていないと、自動テストを増やしたところでリリース前に実施する手動テスト （リグレッションテスト）の工数は減らない - 開発プロセスの中で自動テストを増やし続けること - 手動テスト(E2Eテスト)を自動テストにするためにはテストケースの分解コストが必要 となってしまうため、始めから自動テストを前提としたテストケースを作る
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. Playwrightによるコンポーネントテストのデモ - UIモードでコンソールや ネットワークを 確認しながらデバッグ - Headedモードで実際の ブラウザでの動作を確認可能 - page.pause() で途中のUIを確認 - Watchモードでファイルの変更を検 知して自動実行 （2024/12/7現在ではexperimental) デモに使ったリポジトリ https://github.com/92thunder/playwright-ct-react-demo
23. テックタッチの自動テストでテストのコスパを考える Small Medium Large ユニットテスト Jest ユニットテスト インテグレーション Playwright コンポーネント Playwright インテグレーション E2Eテスト Playwright E2E UIコンポーネントに対して直接テストできる 致命的に遅いわけではないので、 Watchモードも実用的 テストサイズ テスト スコープ 内部でViteでビルドしてPlaywrightでテスト実行するため、1プロセス実行ではない→厳密にはSmallと呼ばないかも
24. テストピラミッド / テスティングトロフィー テストサイズによるテストピラミッド：Smallを増やすとテストのコスパが良い テスティングトロフィー：インテグレーションテストが信頼性とコスト/速度のバランスが良い https://speakerdeck.com/twada/automated-test-knowledge-from-savanna-202305-edition https://kentcdodds.com/blog/the-testing-trophy-and-testing-classifications
25. テストピラミッド / テスティングトロフィー テストサイズによるテストピラミッド：Smallを増やすとテストのコスパが良い テスティングトロフィー：インテグレーションテストは信頼性とコスト/速度のバランスが良い https://speakerdeck.com/twada/automated-test-knowledge-from-savanna-202305-edition https://kentcdodds.com/blog/the-testing-trophy-and-testing-classifications Playwright コンポーネントテストは どちらとしても理に適っている
26. テスト管理ツールの導入と 自動テストの連携
27. テスト管理ツール Qase の導入 - 以前はGoogleスプレッドシートやXray+Jiraで大量のテストケースを管理していた - QAチームでテスト管理ツール Qase を導入 - メリット - 対象のテストケースが手動なのか自動なのか管理できる - 定期実行している自動テストの結果の一覧を確認できる - JestやPlaywrightなどのテスティングフレームワークと連携できる
28. Qaseの機能紹介：テストケースの管理、登録 https://docs.qase.io/general/get-started-with-the-qase-platform/test-cases テストスイート・テストケースの管理 テストケースの登録 Automation Statusも管理できる
29. Qaseの機能紹介：テストランで実行するテストの管理 https://docs.qase.io/general/get-started-with-the-qase-platform/create-a-test-run テスト実施するケースの決定やアサイン テストの実行状況を確認
30. Qase Playwright Reporter - Playwrightで記述したテストを テストケースとしてQaseに登録できる - テストの実行結果をQase上で 確認することができる https://www.npmjs.com/package/playwright-q ase-reporter
31. 開発プロセスにテスト活動を 馴染ませる ”場” づくり ↓ テストスクラム
32. 仕様から駆動する開発 + TIY 仕様策定 設計 実装 テスト分析・設計 テストケース作成 テスト実施 フロントエンドエンジニアが担当 することが多い テスト技法の習得・工数の 負担が大きい 手動テストを前提とした テストケースはそのまま 自動テストになりにくい 仕様策定で得た知識が 設計に役立つことが多い
33. 開発者 QA エンジニア “テストスクラム ” というプラクティスを考案 テスト プランニング テストリスト 作成 テストリスト レビュー 自動テスト レビュー テスト 分析・設計 実装 仕様策定 テストケース作 成 - 自動テストを増やすために開発者とQAエンジニアが越境する場であり、 開発者にとって自然に品質を作るプロセスを求めてために考案した - いくつか自動テストを増やすためのイベントを設定しているため、スクラム開発に ちなんでテストスクラムと名付けてみた
34. テストプランニング 開発者とQAで自動テストを増やす目的と進め方を整理する。 何のためにテスト自動化するのか認識を合わせる。 アジェンダ - テストスクラムの目的の確認 - テストスクラムの流れを確認 - 開発内容を確認して、どこのテストを自動テストにできるか考える
35. テストリスト作成 開発者が集まって、仕様書を元にテストすべきことリスト（＝テストリスト）を作成する。 TDDでも最初にTODOリストを作ることから着想を得ていて、仕様書からテストしたいこ とを列挙するのは開発者にとって自然な開発スタイルだと考えている。 - 仕様書の作成 - 仕様書を元にテストしたいことを列挙する - 自動化できるテストにマークをつけてわかるようにしておく
36. テストリストレビュー 開発者が作成したテストリストをQAエンジニアにレビューしてもらう。 テスト観点の不足をチェックしつつ、どんな自動テストが実装される予定なのかイメージを掴んで もらう。 テストリストをQAエンジニアにレビューしてもらうことでそのままテストケースに繋げる狙い レビュー観点 - 他にテストすべき観点はないか - 自動テストは実際のブラウザ上で動作するテストで実現されるか - デシジョンテーブルや状態遷移図を使った分析が有効な部分はないか
37. 自動テストレビュー テストリストを元にして、実際にどんな自動テストが実現できたか確認する。 できたこと、できなかったことを分析し、次に改善できそうなことを探す。 改善案の例 - 初期に様々な状態を考慮したAPIモックデータを早めに開発者/QAで 一緒に作っておくとバグを出しやすかったのでは - テストケースをQaseに登録しておくと、テストコードとQase上のテストケースIDの連 携がスムーズになるはず
38. 実際の例：仕様 →テストリスト →自動テスト
39. ここまでの取り組みから得られた学び Problem & Concern - テストリスト作成は仕様書を作成した開 発者からしたら仕様をなぞった確認とな りやすく二度手間に感じるのでは - テストしたいことを元にテストリストを作 ることはできるが、テスト技法を使った分 析までは距離を感じる - Qaseと自動テストの連携がユースケー スに合わない部分がある - リグレッションテストの計画において、自 動テストがあるから手動テストを減らす ことに繋がるかはこれから Keep - テストの分類によって QAと開発者で協 力して自動テストに対する共通の認識を 持つことができた - ブラウザ上で動作するテストは QAエン ジニアにとって信頼が得られやすい - テストリストの作成とレビューによって、 テストケースを意識した自動テストに繋 げることができた - 自動テストを認識する場ができたことで QAエンジニアは経験ベースのテストに 集中しやすくなった
40. おわりに - まだまだ試行数も少なくリグレッションテストの工数減までは 到達していないが、着実に改善を重ねて理想に近づいている - テスト自動化においてもDevOpsのケイパビリティのカテゴリである 技術・プロセス・文化のアプローチが揃わないと成功が難しい - 前にトランクベース開発やフィーチャーフラグの導入といった DevOpsのアプローチによる改善に取り組んだが同じことを感じた - 現場によって改善アプローチは異なりますが参考にしてもらえると嬉しいです！