WACATE2025冬_手動テストを自動化した時に起こりうる問題と対処法_当日投影した内容+α版

WACATE 2025 冬のセッション資料です。
https://wacate.jp/workshops/2025winter/

Transcript

1. 手動テストを
 自動化した時に起こりうる問題と対処法
 WACATE 2025 冬
 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖 当日投影した内容+α版

2. 自己紹介
 • CazunariMuraho
 • @cazu_PR
 • WACATE の参加歴
 ◦ WACATE 2022 冬 オンライン初参加
 ◦ WACATE 2023 夏 オフライン参加 Most Accelerating Paper賞
 ◦ WACATE 2023 冬 から WACATE 実行委員
 • 猫
 • 経歴
 ◦ 受託開発会社でアジャイル開発を5年ほど経験。主にQAを担当
 ◦ 今年の5月に事業会社に転職し、お客さんのテスト自動化支援を行なっている

3. はじめに
 • このスライドで「自動テスト」と呼んでいるものは、UIを必要とする自動テストを指し ます
 • 「手動テスト」と呼んでいるものは、手動でやっている（やっていた）テストを指します
 • 経験ベースの内容が多いです
 • AI を使った自動化の手法や事例は扱っていません

4. セッションの目的
 手動テストを自動化したら運用が大変になった人へ
 ▶状況を改善するためのヒントを伝える 
 
 これから手動テストを自動化しようと思っている人へ
 ▶期待通りの成果を得るために必要な考え方を伝える 
 
 自動化の予定がない方へ
 ▶手動テストを自動化しようとしている人に対して「あぶないよ！」と言えるようになっ ていただく 

5. アジェンダ
 1. 手動テストを自動化した際によくある困りごと
 2. 困りごとの原因
 3. 導入前が大事

6. 1.手動テストを自動化した際によくある困りごと 
 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖
7. テストの目的 手動テスト テストの目的を達成するためのテストケース 自動化前

8. テストの目的 手動テスト 自動テスト 手動テストをそのまま自動化
 自動化！！ 内容も操作手順も そっくりそのまま自動化！
9. テストの目的 手動テスト 自動テスト 自動化できたから ここの工数削減できたね！ 手動テストをそのまま自動化

10. テストの目的 手動テスト 自動テスト めっちゃ失敗する！ 修正に時間がかかる！ 工数、削減できたのか！？ 手動テストをそのまま自動化
 👷 👷 👷 👷
11. 2.困りごとの原因 
 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖
12. • 仕様が変わりやすい機能のテストを自動化
 • UIを必要とする自動テストをやみくもに量産
 • 繰り返し実行できない実装になっている
 • 保守性が考慮されていない
 
 
 
 困りごとの原因

13. • 仕様が変わりやすい機能のテストを自動化
 • UIを必要とする自動テストをやみくもに量産
 • 繰り返し実行できない実装になっている
 • 保守性が考慮されていない
 
 
 
 困りごとの原因

14. 仕様が変わりやすい機能
 • リリースされたばかりの機能とか
 ◦ 価値を生んでいる実績がまだ無く、仕様が見直される可能性がある
 ◦ 十分に使われていないため不具合が残っている可能性がある（改修される可 能性がある）

15. 仕様が変わりやすい機能
 • リリースされたばかりの機能とか
 ◦ 価値を生んでいる実績がまだ無く、仕様が見直される可能性がある
 ◦ 十分に使われていないため不具合が残っている可能性がある（改修される可 能性がある）
 テストを自動化しても 
 すぐに修正が必要になる 

16. • 仕様が変わりやすい機能のテストを自動化
 • UIを必要とする自動テストをやみくもに量産
 • 繰り返し実行できない実装になっている
 • 保守性が考慮されていない
 
 
 
 困りごとの原因

17. • UIは色々なものに影響を受けやすい
 ◦ 通信速度
 ◦ OSの種類やバージョン
 ◦ ブラウザの種類やバージョン
 ◦ など
 UIを操作するテストは結果がフレーキーになりやすい

18. • UIテストは、主要なユーザフローや重要度が高いものに限定して自動化するなど
 フレーキーな自動テストを量産しないために

19. Jonathan Rasmusson　著、玉川 紘子　訳. 初めての自動テスト Webシステムのための自動テスト基礎 (p. 10). 他のテストレベルも活用する

20. • 仕様が変わりやすい機能のテストを自動化
 • UIを必要とする自動テストをやみくもに量産
 • 繰り返し実行できない実装になっている
 • 保守性が考慮されていない
 
 
 
 困りごとの原因

21. 繰り返し実行できない自動テストの例①
 サインアップ画面にアクセス メールアドレス「XXX@test.jp」を入力 ユーザ名「テスト太郎」を入力 登録ボタンを押下 サインアップできること トップ画面に遷移していることを確認
22. サインアップ画面にアクセス メールアドレス「XXX@test.jp」を入力 ユーザ名「テスト太郎」を入力 登録ボタンを押下 サインアップできること トップ画面に遷移していることを確認 固定のメールアドレスを
 使っている
 繰り返し実行できない自動テストの例①

23. サインアップ画面にアクセス メールアドレス「XXX@test.jp」を入力 ユーザ名「テスト太郎」を入力 登録ボタンを押下 サインアップできること トップ画面に遷移していることを確認 1回目は成功する
 🟢 🟢 🟢 🟢 🟢 繰り返し実行できない自動テストの例①

24. サインアップ画面にアクセス メールアドレス「XXX@test.jp」を入力 ユーザ名「テスト太郎」を入力 登録ボタンを押下 サインアップできること トップ画面に遷移していることを確認 2回目は失敗する
 
 すでに使用されている
 メールアドレスのため
 🟢 🟢 🟢 ❌ 繰り返し実行できない自動テストの例①

25. 月が表示されているこ とを確認したい
 “December 2025”と表示
 されているか確認する
 🟢 繰り返し実行できない自動テストの例②

26. 月日が流れ...
 繰り返し実行できない自動テストの例②

27. 月日が流れ...
 “December 2025”と表示
 されているか確認する
 ❌ 繰り返し実行できない自動テストの例②

28. • テストが終わった後、生成したデータを削除する処理を含める
 • アサーションで使う値を動的にする
 など
 繰り返し実行可能な実装をする

29. • 仕様が変わりやすい機能のテストを自動化
 • UIを必要とする自動テストをやみくもに量産
 • 繰り返し実行できない実装になっている
 • 保守性が考慮されていない
 
 
 
 困りごとの原因

30. • 処理が共通化されず、修正に時間がかかる
 • 処理の可読性が低くなり、修正に時間がかかる
 • 依存関係を作ってしまい、修正や実行に時間がかかる
 保守性が考慮されていないと...

31. 処理の共通化が行われなかった例
 プロフィールを変更できること 記事を投稿できること ログイン 記事作成ボタンを押下 本文に文字を入力 投稿ボタンを押下 記事追加を確認 ログイン 設定ボタンを押下 ユーザ名を上書き 保存ボタンを押下 ユーザ名の上書きを確認
32. プロフィールを変更できること 記事を投稿できること ログイン 記事作成ボタンを押下 本文に文字を入力 投稿ボタンを押下 記事追加を確認 ログイン 設定ボタンを押下 ユーザ名を上書き 保存ボタンを押下 ユーザ名の上書きを確認 ログインの処理はどのテストでも発生する処理
 処理の共通化が行われなかった例

33. プロフィールを変更できること 記事を投稿できること ログイン 記事作成ボタンを押下 本文に文字を入力 投稿ボタンを押下 記事追加を確認 ログイン 設定ボタンを押下 ユーザ名を上書き 保存ボタンを押下 ユーザ名の上書きを確認 共通化されていない場合...
 ログインの仕様が変わった時、テストの数だけ修正することになる
 修正
 修正
 処理の共通化が行われなかった例

34. プロフィールを変更できること 記事を投稿できること 記事作成ボタンを押下 本文に文字を入力 投稿ボタンを押下 記事追加を確認 設定ボタンを押下 ユーザ名を上書き 保存ボタンを押下 ユーザ名の上書きを確認 共通化されている場合...
 ログインの仕様が変わった時、共通化された処理を1つ修正すれば良い
 ログイン 修正
 処理の共通化を行った場合

35. プロフィールを変更できること 記事を投稿できること ログイン 記事作成ボタンを押下 本文に文字を入力 投稿ボタンを押下 記事追加を確認 設定ボタンを押下 ユーザ名を上書き 保存ボタンを押下 ユーザ名の上書きを確認 共通化されている場合...
 ログインの仕様が変わった時、共通化された処理を1つ修正すれば良い
 修正
 修正にかかる時間を 
 短縮できる 
 処理の共通化を行った場合

36. 可読性が低い例
 1. アカウントAでログイン 2. 設定画面で3つ目のトグルをONにする 3. アカウントBでログイン 4. 「組織管理」ボタンを押下 5. 組織名を上書き後「保存」ボタンを押下 7. 上書きされた組織名を確認 ・・・ テスト名 「組織管理_管理ユーザ_基本操作」 6. 3秒待機
37. 1. アカウントAでログイン 2. 設定画面で3つ目のトグルをONにする 3. アカウントBでログイン 4. 「組織管理」ボタンを押下 5. 組織名を上書き後「保存」ボタンを押下 7. 上書きされた組織名を確認 ・・・ テスト名 「組織管理_管理ユーザ_基本操作」 6. 3秒待機 テストの名前や処理を見ても 
 意図や行われている操作がわからないため 
 手を出すのに時間がかかる 
 可読性が低い例

38. テスト名 「管理権限を持つユーザは組織名を変更 できること」 担保したいことが具体的に表現されていると自 動テストの目的を把握できる 
 1. アカウントAでログイン 2. 設定画面で3つ目のトグルをONにする 3. アカウントBでログイン 4. 「組織管理」ボタンを押下 5. 組織名を上書き後「保存」ボタンを押下 7. 上書きされた組織名を確認 ・・・ 6. 3秒待機 可読性を上げた場合

39. 1. アカウントBに管理権限を付与 1.1 アカウントAでログイン 1.2 設定画面で3つ目のトグルをONにする 2. アカウントBでログイン 3. 「組織管理」ボタンを押下 4. 組織名を上書き後「保存」ボタンを押下 6. 上書きされた組織名を確認 ・・・ テストではない処理は事前処理としてテストの 処理と分離させたり、処理の意図を明文化して おくと内容がわかりやすくなる 
 5. 3秒待機 #反映に時間がかかるためこの処理が必要 テスト名 「管理権限を持つユーザは組織名を変更 できること」 可読性を上げた場合

40. 1. 管理権限を持つアカウント Bでログイン 2. 「組織管理」ボタンを押下 3. 組織名を上書き後「保存」ボタンを押下 5. 上書きされた組織名を確認 ・・・ あらかじめ事前条件を満たした環境やデータが 用意できれば処理がよりシンプルになる 
 （UI操作が減るのでフレーキーさも 
 軽減できる） 
 4. 3秒待機 #反映に時間がかかるためこの処理が必要 テスト名 「管理権限を持つユーザは組織名を変更 できること」 可読性を上げた場合

41. 依存関係を作ってしまった例
 記事を削除できること 記事を投稿できること ログイン 記事作成ボタンを押下 本文に文字を入力 投稿ボタンを押下 記事追加を確認 ログイン 記事一覧から記事を選択 削除ボタンを押下 削除を確認 右のテストは左のテストで作られた記事デー タを使って実行される
42. 依存関係を作ってしまった例
 記事を削除できること 記事を投稿できること ログイン 記事作成ボタンを押下 本文に文字を入力 投稿ボタンを押下 記事追加を確認 ログイン 記事一覧から記事を選択 削除ボタンを押下 削除を確認 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 右のテストが成功するには
 左のテストが成功する必要がある

43. ログイン 記事作成ボタンを押下 本文に文字を入力 投稿ボタンを押下 記事追加を確認 ログイン 記事一覧から記事を選択 削除ボタンを押下 削除を確認 ❌ 🟢 🟢 ❌ 依存関係を作ってしまった例
 記事を削除できること 記事を投稿できること 🟢 左のテストが失敗すると右のテストも失敗する
 （記事データが存在しないため）

44. ログイン 記事作成ボタンを押下 本文に文字を入力 投稿ボタンを押下 記事追加を確認 ログイン 記事一覧から記事を選択 削除ボタンを押下 削除を確認 独立性を高め依存関係は作らない
 記事を削除できること 記事を投稿できること 記事作成ボタンを押下 本文に文字を入力 投稿ボタンを押下 テストで使用するデータは
 そのテストの中で生成されるようにする

45. ログイン 記事作成ボタンを押下 本文に文字を入力 投稿ボタンを押下 記事追加を確認 ログイン 記事一覧から記事を選択 削除ボタンを押下 削除を確認 独立性を高め依存関係は作らない
 記事を削除できること 記事を投稿できること 記事作成ボタンを押下 本文に文字を入力 投稿ボタンを押下 「内容が重複してるから右側のテストだけ あればよくない？🤔」

46. ログイン 記事一覧から記事を選択 削除ボタンを押下 削除を確認 独立性を高め依存関係は作らない
 記事の投稿・削除ができること 記事作成ボタンを押下 本文に文字を入力 投稿ボタンを押下 記事追加を確認 まとめた場合

47. ログイン 記事一覧から記事を選択 削除ボタンを押下 削除を確認 独立性を高め依存関係は作らない
 記事の投稿・削除ができること 記事作成ボタンを押下 本文に文字を入力 投稿ボタンを押下 記事追加を確認 記事の投稿を確認
 記事の削除を確認

48. ログイン 記事一覧から記事を選択 削除ボタンを押下 削除を確認 独立性を高め依存関係は作らない
 記事の投稿・削除ができること 記事作成ボタンを押下 本文に文字を入力 投稿ボタンを押下 記事追加を確認 運用しづらくなるので個人的には 
 テストの目的ごとに自動テストは 作っておくのがおすすめ 
 投稿のテストだけしたくても削除 処理まで実行される
 
 • 実行時間が必要以上に伸びる 
 • 投稿に成功しても削除が失敗するとテ ストが失敗する

49. ログイン 記事作成ボタンを押下 本文に文字を入力 投稿ボタンを押下 記事追加を確認 ログイン 記事一覧から記事を選択 削除ボタンを押下 削除を確認 独立性を高め依存関係は作らない
 記事を削除できること 記事を投稿できること （スクリプトを実行しデータを 生成） 削除のテストなので、記事データの生 成はUI操作で行う必要はない

50. 自動テストが壊れづらくなってきましたね 

51. 手動テストと全然違う形になりましたね 

52. 手動テストと自動テストの開発ライフサイクルは別
 https://jstqb.jp/dl/JSTQB-Syllabus.Advanced_TAE_Version2016.J01.pdf
53. 3.導入前が大事という話 
 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖 🤖
54. 起こるかもしれないこと
 • 自動化したかったテストが自動化できない

55. • 自動化したかったテストが自動化できない
 導入後にギャップが生まれないように事前に調べる 
 起こるかもしれないこと

56. こんなことにならないか事前に確認する
 次のような事は行うべきではない。 • インターフェースの影響を受けやすいスクリプト（グラフィカルインターフェースや APIの重要でない部 分 の変更による影響を受けるスクリプト）を作成しない。 • データの変更による影響を受けやすい、または特定のデータ値に大きく依存するテスト自動化（他のテ ス ト出力に依存するテスト入力など）を行わない。 • コンテキスト（オペレーティングシステムの日付や時刻、オペレーティングシステムの多言語化のパラ メー ター、別のアプリケーションのコンテンツなど）の影響を受けやすい自動化環境を作成しない。この 場合、 環境を制御できるように、必要に応じてテスト用のスタブを使うのが望ましい。 https://jstqb.jp/dl/JSTQB-Syllabus.Advanced_TAE_Version2016.J01.pdf
57. まとめ
 • 手動テストを自動化すると失敗しやすく保守性の低い自動テストができる(かも)
 • 手動テストと自動テストの開発ライフサイクルは別
 ◦ 「手動テストを自動化しよう」ではなく「自動テストをつくろう」という
 発想が必要（どこかで聞いたことがある）
 • 「思ってたよりも自動化できなかった！」とならないように導入前に調べる（やってみな がら調べてもいいかも）

58. • 初めての自動テスト Webシステムのための自動テスト基礎 
 ◦ https://amzn.asia/d/6ZGxwjT 
 • テストを自動化するのをやめ、自動テストを作ろう 
 ◦ https://speakerdeck.com/tsuemura/tesutowozi-dong-hua-surufalsewoyame-zi-dong-tesut owozuo-rou 
 • テスト技術者資格制度 Advanced Level シラバス テスト自動化エンジニア 
 ◦ https://jstqb.jp/dl/JSTQB-Syllabus.Advanced_TAE_Version2016.J01.pdf 
 参考資料

59. ありがとうございました