自動テスト - 講義編【サイボウズ新人研修2025】

Transcript

1. 自動テスト サイボウズ開運研修 福元 春輝 (Garoon QA)
2. この資料の想定読者 ▌自動テストに携わるかもしれない、あるいは携わりたいので、自 動テストの基本的な知識やお作法をおさえたい方 ▌自動テストを導入したい方 ▌自動テストの運用や改善もやっていきたい方 2
3. サイボウズの自動テスト周りの状況 ▌自動テスト導入初期からずいぶん時間が経ち、自動テストの導入 は一般的になってきた ▌自動テストそのものは知っており、またそれを使うことはできて いるけれど、その先にある運用で苦労している 3
4. この資料のスコープ ▌スコープ o 自動テストを導入するメリット o 自動テストを運用していく上で立ちはだかる課題との向き合い 方 ▌スコープ外 o 特定のツールやソフトウェアの具体的な使い方 4
5. 目次 1. なぜテストを自動化するのか？ 2. テストを自動化するメリット 3. 自動テストの種類 4. 自動テストの理想と現実 5. バランスよく自動化を進めましょう 6. 優先順位をつけて自動化しましょう 7. チーム全体で自動化しましょう 8. まとめ 5
6. なぜテストを自動化するのか？ 6 ▌Garoonのスケジュールのテストの一例を見てみましょう Steps (ja) [準備] 1. ユーザー（user1）を作成する。 2. 施設（facility1 ~ facility5）を作成する。 [手順] 1. user1 でログインする。 2. スケジュールアプリを開き、"予定を登録する" をクリックする。 ”通常予定” を選択し、以下のとおり項目を入力する。 + 参加者 : user1 + タイトル: appointmentA + 日時: 8:00 ~ 9:00 + 施設: facility1~ facility3 3. 施設の候補リストのドロップダウンリストに表示されている施設をすべて選択する。 4. "参加者と施設の空き時間を確認する" をクリックする。 5. "施設の選択をすべて外す" をクリックする。 6. facility4 のチェックボックスにチェックを入れる。 7. 日時のセレクトボックスで、 10:00 ~ 11:00 を選択する。 8. "予定に反映する" ボタンをクリックする。 [期待結果] 4. 利用可能な時間を確認するポップアップ が表示されること 先頭にチェックボックスが表示されるこ と facility1、facility2、facility3 のチェック ボックスがチェックされていること 8. 利用可能な時間を確認するポップアップ が閉じられること facility4 が施設のリストに追加されるこ と facility1、facility2、facility3 が施設のリ ストから削除されていること
7. [期待結果] 4. 利用可能な時間を確認するポップアップ が表示されること 先頭にチェックボックスが表示されるこ と facility1、facility2、facility3 のチェック ボックスがチェックされていること 8. 利用可能な時間を確認するポップアップ が閉じられること facility4 が施設のリストに追加されるこ と facility1、facility2、facility3 が施設のリ ストから削除されていること Steps (ja) [準備] 1. ユーザー（user1）を作成する。 2. 施設（facility1 ~ facility5）を作成する。 [手順] 1. user1 でログインする。 2. スケジュールアプリを開き、"予定を登録する" をクリックする。 ”通常予定” を選択し、以下のとおり項目を入力する。 + 参加者 : user1 + タイトル: appointmentA + 日時: 8:00 ~ 9:00 + 施設: facility1~ facility3 3. 施設の候補リストのドロップダウンリストに表示されている施設をすべて選択する。 4. "参加者と施設の空き時間を確認する" をクリックする。 5. "施設の選択をすべて外す" をクリックする。 6. facility4 のチェックボックスにチェックを入れる。 7. 日時のセレクトボックスで、 10:00 ~ 11:00 を選択する。 8. "予定に反映する" ボタンをクリックする。 なぜテストを自動化するのか？ 7 ▌Garoonのスケジュールのテストの一例を見てみましょう 毎回のテストで手動実行するのは時間がかかる + 人為的なミスが発生することがある
8. 自動テストによるメリット 8 参考: 『iOSアプリ開発自動テストの教科書』, 1-1 なぜ自動テストを実装するのか』 ▌早く実行できる ▌何度もくり返し実行できる ▌正確に実行できる ⚫ 人為的ミスや属人性の排除 ▌仕様書通りに動くという安心感を得られる ⚫ 基本機能をテスト自動化しておけば，最低限の保証ができる
9. 自動テストの種類 9 ▌ユニットテストフトウェアテストの講義で実施した手動テスの ▌結合テスト待結果になるかを判定 ▌UIテスト
10. 自動テストの種類 10 ▌ユニットテスト ⚫ ロジックに対するテストで，関数への入力に対する出力が正しいかを 判定する ⚫ 例）ログインに関するロジックをテストしたい 1. 正しいメールアドレスとパスワードを関数に与える 2. 関数が入力値の組を正しいと判定していることを確認する
11. 自動テストの種類 11 ▌結合テスト ⚫ サービス→ロジックを通るテストで，UIを使わずにリクエストに対す る出力が正しいかを判定する ⚫ 例）ログインに関するロジックをテストしたい 1. APIを使って，メールアドレスとパスワードをリクエストする 2. 入力値の組が正しいと関数が判定して，APIに正しい組ですよと返してくれるこ とを確認する
12. 自動テストの種類 12 ▌UIテスト ⚫ UI→サービス→ロジックを通るテストで，UIから実際に製品を触って 期待通りに動くかを判定する ⚫ 例）ログインに関するロジックをテストしたい 1. UI上で，ログイン画面に遷移する 2. UI上で，メールアドレスとパスワードを入力する 3. UI上で，ログインボタンをクリックする 4. APIが入力値を関数に与え，関数が正しいと判定してUIまで返す 5. UI上で，次の画面へ遷移することを確認する
13. 自動テストの種類 13 ▌UIテスト ⚫ UI→サービス→ロジックを通るテストで，UIから実際に製品を触って 期待通りに動くかを判定する ⚫ 例）ログインに関するロジックをテストしたい 1. UI上で，ログイン画面に遷移する 2. UI上で，メールアドレスとパスワードを入力する 3. UI上で，ログインボタンをクリックする 4. APIが入力値を関数に与え，関数が正しいと判定してUIまで返す 5. UI上で，次の画面へ遷移することを確認する 全ての層を触るUIテストさえ導入すれば システムを完璧に保証できるのでは？
14. 自動テストの理想 14 ▌自動化すれば、工数が少なくなる
15. 自動テストの理想 15 ▌自動化すれば、工数が少なくなる？
16. 自動テストの現実 16 ▌自動テストは仕様変更との戦い o 自動テストは仕様＝期待結果が変わればその変更に追随しない かぎり落ちてしまう ▌仕様変更の一例 o 製品機能の変更 ▪ 機能変更により、テストの手順自体の修正が必要 o 製品デザインの変更 ▪ ボタンや入力欄の名称や位置が変更になったことによる修正 o ブラウザや端末のOSなど周辺ソフトウェアの仕様変更
17. 自動テストが頻繁に動かなくなると... 17 ▌(2nd) 工数をかけてテストを自動化する ▌(3rd) 手動テストが減る ▌(4th) 自動テストを直しつつ，壊れている間は手動テストで対応する
18. 壊れた自動テストがなかなか直せなくなると... 18 ▌(2nd) 工数をかけてテストを自動化する ▌(3rd以降) 壊れた分だけ手動テストをして，メンテナンスを続ける ▌(Nth以降) 壊れた自動テストを直せなくて，手動テストが結局必要になる
19. 自動テストの現実 19 ▌自動化すれば一概に工数が減るとはいえない o 手動テストの工数は減るかもしれないが、運用という工数が 増える
20. 自動テストの現実 20 ▌自動化すれば一概に工数が減るとはいえない o 手動テストの工数は減るかもしれないが、運用という工数が 増える どうすれば自動テストを上手く使いこなせるのでしょうか？
21. （再掲）自動テストの種類 21 ▌ユニットテスト ⚫ ロジックに対するテストで，関数への入力に対する出力が正しい かを判定する ▌結合テスト ⚫ サービス→ロジックを通るテストで，UIを使わずにリクエストに 対する出力が正しいかを判定する ▌UIテスト ⚫ UI→サービス→ロジックを通るテストで，UIから実際に製品を 触って期待通りに動くかを判定する
22. （再掲）自動テストの種類 22 ▌ユニットテスト ⚫ 壊れにくく実行速度が早く，どこが壊れているかが分かりやすい ⚫ 複数層の繋がりは保証できない ▌結合テスト ⚫ UIテストよりも壊れにくく，複数層を確認できる ⚫ どこが壊れているか分かりにくい ▌UIテスト ⚫ ユーザーと同じ操作でテストするので，動作保証しやすい ⚫ 実行時間がかかり，壊れやすい
23. （再掲）自動テストの種類 23 ▌ユニットテスト ⚫ 壊れにくく実行速度が早く，どこが壊れているかが分かりやすい ⚫ ▌結合テスト ⚫ UIテストよりも壊れにくく，複数層を確認できる ⚫ ▌UIテスト ⚫ ユーザーと同じ操作でテストするので，動作保証しやすい ⚫
24. （再掲）自動テストの種類 24 ▌ユニットテスト ⚫ 壊れにくく実行速度が早く，どこが壊れているかが分かりやすい ⚫ 複数層の繋がりは保証できない ▌結合テスト ⚫ UIテストよりも壊れにくく，複数層を確認できる ⚫ どこが壊れているか分かりにくい ▌UIテスト ⚫ ユーザーと同じ操作でテストするので，動作保証しやすい ⚫ 実行時間がかかり，壊れやすい UIテストだけに頼らずに良いバランスで テストを自動化するとメリットを活かせるのでは？
25. 手動テスト どちらの配分で自動化するのがバランス良い？ 25 ▌ピラミッド型 UIテスト 結合テスト ユニットテスト UIテスト 結合テスト ユニット テスト ▌アイスクリームコーン型 手動テスト テストの数 高コスト 動作保証 テストの数
26. 手動テスト テスト自動化のアンチパターンです 26 UIテスト 結合テスト ユニット テスト テストの数 ⚫不安定で実行が遅い ⚫メンテナンスコストが高い ⚫開発生産性が低下する ▌アイスクリームコーン型 高コスト 動作保証
27. 手動テスト テスト自動化のアンチパターンです 27 UIテスト 結合テスト ユニット テスト テストの数 ⚫不安定で実行が遅い ⚫メンテナンスコストが高い ⚫開発生産性が低下する ▌アイスクリームコーン型 高コスト 動作保証 自動化の始めたてはこれから 始まってもよい！
28. ピラミッド型を目指しましょう！ 28 ▌ピラミッド型 UIテスト 結合テスト ユニットテスト 手動テスト テストの数 高コスト 動作保証 参考: 『初めての自動テスト ―Webシステムのための自動テスト基礎』, 1.4 テストのビラミッドに入り込む ⚫安定していて実行が早い ⚫維持しやすい ⚫費用対効果が高い 低レイヤーで見つけられる なら先に検出できる方が良い
29. ▌テストのピラミッドはMike Cohnの "Succeeding with Agile"[Coh09]で 最初に提唱されたモデル ▌UIテスト、結合テスト、ユニットテストの3つの異なる自動 テストがどのように互いに補完し合うかを示すもの テストピラミッドと呼ばれている 29 UIテスト 結合テスト ユニットテスト 手動テスト ※ピラミッドの上部に「手動テスト」を記載する書き方もみられるが、 説明の便宜上、本講義資料でもそのように書く。 参考: 『初めての自動テスト ―Webシステムのための自動テスト基礎』, 1.4 テストのビラミッドに入り込む
30. ▌テストのピラミッドはMike Cohnの "Succeeding with Agile"[Coh09]で 最初に提唱されたモデル ▌UIテスト、結合テスト、ユニットテストの3つの異なる自動 テストがどのように互いに補完し合うかを示すもの テストピラミッドと呼ばれている 30 UIテスト 結合テスト ユニットテスト 手動テスト ※ピラミッドの上部に「手動テスト」を記載する書き方もみられるが、 説明の便宜上、本講義資料でもそのように書く。 参考: 『初めての自動テスト ―Webシステムのための自動テスト基礎』, 1.4 テストのビラミッドに入り込む ピラミッド型を目指して テストケースをどんどん自動化していこう！
31. 形だけでなく大きさも重要です！ 31 ▌そのテスト、必要ですか？ 工数は限られているので無限にコストはかけられません そもそも100%の品質は存在しません
32. テストピラミッドの「大きさ」を小さくするアイデア 32 参考: 『初めての自動テスト ―Webシステムのための自動テスト基礎』, 10.3 コンテキストを明確にする ▌重複/似ているテストを見つけるため、テストのコンテキストを 切り直す(分類方法を見直す) UIテスト 結合テスト ユニットテスト 画面ごと、ユーザーの動作手順 サービス、APIエンドポイント クラス、インタフェース
33. Q. アプリケーションの機能は増える一方なの で，テストピラミッドは大きくなって，不安定な テストも増えてしまいませんか？ 33
34. “空いた瓶には大きな石から入れましょう” 34 イラストの出所: https://www.irasutoya.com/2019/04/blog-post_23.html
35. 限られた工数の中で何を優先するか？ 35 ▌メンテナンス頻度が少ないテスト ⚫ 「枯れた」テストであれば、修正が必要になる可能性が低い
36. 限られた工数の中で何を優先するか？ 36 ▌メンテナンス頻度が少ないテスト ⚫ 「枯れた」テストであれば、修正が必要になる可能性が低い ▌作成・メンテナンス難易度が低いテスト ⚫ 作成・メンテナンスに工数をかけない
37. 限られた工数の中で何を優先するか？ 37 ▌メンテナンス頻度が少ないテスト ⚫ 「枯れた」テストであれば、修正が必要になる可能性が低い ▌作成・メンテナンス難易度が低いテスト ⚫ 作成・メンテナンスに工数をかけない ▌頻繁に繰り返し実施されるテスト ⚫ 利用頻度が高いということは、手動による工数を削減してい る
38. 『LEADING QUALITY』 によると 38 参考: 『LEADING QUALITY』,第4章 手動テストと自動テスト "テストを手動で行うよりも自動化したほうが有効となる要素が主に3つあ ると結論づけられた。 1.自動化されたテストケースが変更の手を入れることなく長期にわたっ て利用できると期待できること。 2.テストケースが比較的自動化しやすいものであること。すなわち、細 部にわたる操作を必要としない手動テストから生成できるか。手順が複雑 になるほど、自動化は著しく困難になる。 3.手動で実施するよりも自動化して実施および維持するコストのほうが 安いこと。"
39. テストピラミッドの「大きさ」を小さくするアイデア 39 ▌「必要なテスト」を実施する
40. テスト自動化は独りでもできるけど… 40 ▌独りで作れるが、独りで維持は難しい o 独りで「熱」を維持するのは難しい o 自分の工数は無限ではない
41. テスト自動化はQAだけでもできるけど… 41 ▌E2Eテストの自動化は壊れやすい o 後半工程のテストは変化の影響を受けやすく、壊れやすい o E2Eテストを自動化するよりも、E2Eテストを他の工程でカ バーした方がより効率的 o 前半工程のテストをするには、開発者の協力が不可欠 ▌推進する人が異動や退職でいなくなる
42. チーム全体で取り組もう 42 ▌チームでなければできないことがある o チームを俯瞰した効率化 ▪ チームによって、効率化できるポイントは異なる ▪ チームの構成、スキルにより最適な方法は異なる o 協力体制を作る ▪ 各工程のテスト実施には、チームの協力が不可欠 ▪ 特定の工程だけでテストを効率化するのは限界がある o 人に依存しないための協力体制 ▪ チーム全体で自動化のメリットを理解し、協力を得られなければ誰かに依 存した体制になってしまう
43. チームにあった自動テストツールを選定しよう 43 ▌自動テストツールの選択基準 o テストピラミッドなどテスト戦略に基づいて ▪ 「自動化しない」「あえてE2Eテストを自動化」もあり o チームメンバーの構成人数や内訳 ▪ 例）自動テストツールの利用者目線 ▌ 自動テストツールでテストケースを作る人 ▌ 壊れたテストケースを直す人 ▪ 自動テストツールの実行結果がわかればいい人 o 製品の開発サイクル ▪ 例）アジャイル
44. 5. まとめ ▌自動テストにはたくさんのメリットがあります。 ▌ただし、自動テストはあくまでもテストを効率的に進める手段のひ とつにすぎません。 ▌プロダクトの成長を支えるためには、自動テストとうまく付き合っ ていかなければなりません。 ⚫ どこで、だれが、どうやってテストしますか？ ⚫ テストピラミッドをチーム一丸で作り上げていますか？ 44