「何となくテストする」を卒業するためにプロダクトが動く仕組みを理解しよう

2025.9.8 QA Test Talk Vol.5 登壇資料

Transcript

1. 「何となくテストする」を卒業するためにプロダ クトが動く仕組みを理解しよう 2025.9.8 QA Test Talk Vol.5 コミューン株式会社 QAチームリーダー 須賀 康行
2. 自己紹介・・・する時間がないので飛ばします！ • 経歴 ◦ Web系のQAエンジニア歴10年以上 ▪ 第三者検証（1年半） ▪ 医療系事業会社（7年半） ▪ コミューン株式会社。 1人目のQA（2022年1月〜） ◦ QAチームのマネージャー歴 5年以上 ▪ 最近テストスキルの言語化を頑張ってます • ブログ、X ◦ https://kawabeaver.hatenablog.com/ ◦ https://zenn.dev/kawabeaver ◦ https://x.com/kawabeaver
3. 今日のゴール テストがなぜ必要・不要かをプロダクトが動く仕組みから判断できるようになる ことで、以下のような悩みを少しでも解消できたら幸いです • 基本設計書（外部仕様書）の記載内容から何となくテスト内容を考えているけど、ど こまでテストをすれば良いか自信が持てない • 念の為たくさんテストしてしまっているけど、バグが見つからないテストも多い。で も、どこまでテストを減らして良いかわからない
4. 今日の話の前提 • Webアプリケーションのテスト • ソースコード、インフラの構成などを知ることができる • 稼働中のプロダクトに対する機能追加や既存機能の改修が多い • 基本設計、詳細設計、コードの品質は一定の水準以上である • 私個人の考え方なので、正解ではないかもしれません ※　原則６：テストはコンテキスト次第 　　今日の内容は皆さんの現場に合わない可能性があります。ご了承ください
5. 今日話す内容 1. ソフトウェアテストの理想と現実 2. ソフトウェアの基本的な仕組みに基づくテスト分析 3. Webサイトが動く仕組みに基づくテスト分析 4. 修正箇所と他の仕組みとの関係に基づくテスト分析 5. プロダクトの仕組みに基づくテスト分析の注意点
6. ソフトウェアテストの理想と現実 • 理想 ◦ プロダクトに発生しうる状況（入力、データの状態など）を全てテストすること • 現実 ◦ 原則２：全数テストは不可能 ▪ 全ての状況はパターンが多すぎてテストするのは現実的には不可能 • 例：10桁表示の電卓アプリで足し算のテストをする場合、正の整数２つの足し算の組み 合わせだけでも10,000,000,000 * 10,000,000,000通りある ◦ 私たちは限られたテスト量で プロダクトがちゃんと動くことを担保しなければならない
7. ソフトウェアテストの理想と現実 • 10桁表示の電卓アプリで足し算のテストをする場合、きっとこんなことを考えます ◦ 1 + 1, 100 + 100が正しいなら、きっと他の足し算の組み合わせもうまく動くだろう ◦ いや、足し算の結果が 10桁を超えた場合のテストもした方が良いな ◦ 負の整数の足し算もやっておこう ◦ 整数だけでなく小数と整数の足し算のテストもやっておいた方が良いかな ◦ あ、足し算を計算した結果の数値をそのまま使って連続で足し算をしてみよう ▪ 1 + 1を計算したあと、1 + 1の計算結果（2）を使って 2 + 3の計算を行う
8. なぜこれらのテストが必要だと考えたのでしょうか？ • 私の場合、これらの足し算は異なる仕組みで処理されると考えた • 「異なる仕組みで処理される」を別の視点で説明すると、１つ目の条件でテストして 問題がなくても、２つ目の条件でテストしたらバグが起こる可能性があると考えた • ということで、プロダクトが動く仕組み のことを理解すると、テスト分析がうまくできる かもしれない
9. 今日話す内容 1. ソフトウェアテストの理想と現実 2. ソフトウェアの基本的な仕組みに基づくテスト分析 3. Webサイトが動く仕組みに基づくテスト分析 4. 修正箇所と他の仕組みとの関係に基づくテスト分析 5. プロダクトの仕組みに基づくテスト分析の注意点
10. ソフトウェアの基本的な仕組み（モデルの例） 画像引用元：https://speakerdeck.com/goyoki/test-analysis-tutorial
11. 前述のテスト条件を先ほどの分類に当てはめると • 1 + 1, 100 + 100が正しいなら、きっと他の足し算の組み合わせもうまく動く ◦ 足し算の「処理」 • 足し算の結果が10桁を超えた場合のテストもした方が良いな ◦ 最大桁数を超えた場合の 「処理」または「出力」 • 負の整数の足し算もやっておこう ◦ マイナス記号の「入力」 、負の整数の計算「処理」 、マイナス記号の「出力」 • 整数だけでなく小数と整数の足し算のテストもやっておいた方が良いかな ◦ 小数の「入力」 、整数と小数の計算 「処理」 、小数の「出力」 • 足し算を計算した結果の数値をそのまま使って連続で足し算をしてみよう ◦ 「間接入力」 を使った足し算 ※「入力」に分類する考え方もあると思います
12. それぞれの仕組みに応じたナレッジをためよう • 入力 ◦ ダブルクリックのテスト：処理を二重で行うことがないか ◦ 様々な文字種を入力するテスト：正常に扱えない文字がないか • 間接入力 ◦ ユーザーの属性 • 間接出力 ◦ データ更新先：DB、サーバーキャッシュ、クラウドストレージ、ローカルストレージ ◦ データ削除：削除したデータに紐づくデータも削除されるか • 出力 ◦ 出力内容に予約語を含む：予約語が適切にエンコードなどされるか ▪ 例：CSVの「,」、URLの「&」や「?」、JSONの「”」
13. 先ほどモデルのみでは思いつきにくいテストもある • ブラウザにURLを入力して直接特定の画面にアクセスすることができる ◦ UI上のリンクを非表示にしても、 URLを知っていればページにアクセスされてしまう • ブラウザでWebページを表示した時と、表示画面の操作をする時でデータの状態 が変わっている場合がある ◦ ECサイトで注文しようと思ったら、他の人が先に同じ商品を注文していて商品が在庫切れに • ブラウザで同じページを複数開いたり、ブラウザの戻る機能を使ったりして1度しか できない操作を複数回試せる可能性がある ◦ アンケートの回答画面を複数開き、 2回回答できてしまう １つのモデルを使えば安心というわけではない点に注意
14. プロダクトを構成する仕組みをどこまでテストするか • 正常に動作することが担保されている仕組みは、細かくテストしない • 例）他の人が作成した品質が信頼できる仕組み ◦ サードパーティ製のメール配信システム、決済システム ▪ サードパーティ製ツールにデータを正しくセットするまでの処理をテストする ▪ サードパーティ製ツールに設定した内容が正しいことを確認するテストをする ◦ フレームワークや信頼できるライブラリが提供する、古くから利用されている関数 ▪ 関数を正しく利用しているかまでをテストする • 例：四捨五入のテストでは、代表的な境界値だけテストする ◦ 信頼できるUIのコンポーネントのライブラリ ▪ Date Picker：閏年などの細かいテストはせず、代表的な日付のみ動作確認する ◦ HTMLの基本機能によるバリデーション ▪ inputタグのtype属性がemailの入力欄：細かくテストしない ※　メールアドレスの特殊なルールがある場合を除く
15. 今日話す内容 1. ソフトウェアテストの理想と現実 2. ソフトウェアの基本的な仕組みに基づくテスト分析 3. Webサイトが動く仕組みに基づくテスト分析 4. 修正箇所と他の仕組みとの関係に基づくテスト分析 5. プロダクトの仕組みに基づくテスト分析の注意点
16. Webサイトが動く仕組み（説明に関係する範囲のみ） ブラウザ サーバーアプリケーション レンダリングエンジン JavaScriptエンジン リクエスト レスポンス レンダリングエンジン、 JavaScriptエンジンは ブラウザによって異なる（別の仕組みである） これらの仕組みを利用する場合は複数ブラウザのテストが必要
17. 商品の一覧を取得する際に非表示の商品を除く処理 ブラウザ サーバーアプリケーション （商品一覧から非表示の商品を 除く処理を実行する） レンダリングエンジン JavaScriptエンジン リクエスト レスポンス 商品の一覧を ください 非表示の商品を除 いた商品の一覧を 返します 処理がサーバー側で完結しているな らば、APIテストだけで十分
18. 指定した条件の商品の一覧を取得する処理 ブラウザ サーバーアプリケーション （指定した条件の商品の一覧を取得 する処理を実行） レンダリングエンジン JavaScriptエンジン リクエスト レスポンス 指定した条件 の 商品の一覧を ください 非表示の商品を除 いた商品の一覧を 返します リクエストの赤文字部分は ブラウザから指示を出す ブラウザでの手動テストも必要 複数ブラウザのテストは仕組み次第
19. 実際のプロダクトの仕組みはもっと複雑 画像引用元：https://zenn.dev/maman/articles/a797a98ac548e9 テスト対象が図の中の どの部分の処理なのか を意識してみよう
20. 複数ブラウザでのテストの必要性について • 昔と異なり、最近ではブラウザ依存の不具合はかなり減っている印象です。現在は 昔ほど複数ブラウザのテストは行わなくても良いかもしれません • 皆さんも自分が担当するプロダクトの過去の不具合を分析してみて、複数ブラウザ でのテストの必要性を確認してみてください
21. 今日話す内容 1. ソフトウェアテストの理想と現実 2. ソフトウェアの基本的な仕組みに基づくテスト分析 3. Webサイトが動く仕組みに基づくテスト分析 4. 修正箇所と他の仕組みとの関係に基づくテスト分析 5. プロダクトの仕組みに基づくテスト分析の注意点
22. リグレッションテストをどこまでやるか • 私の経験則上、修正箇所に対して以下のような関係がある仕組み（機能）でリグ レッションが発生しやすいです ◦ 修正した箇所より後に実行される関数内の処理 ◦ コードを修正した関数を利用している機能 ◦ 修正した機能が出力したデータを参照する他の機能 ◦ 修正した画面と同じ画面にある別の機能
23. 修正した箇所より後に実行される関数内の処理 特別会員？ 送料無料 合計金額が 5000円以 上？ 送料が有料 No No Yes Yes 合計金額の判定を追加した場 合、この処理より前に実行され る「特別会員かどうかを判定す る処理」は修正の影響を受けな い
24. コードを修正した関数を利用している機能 画像引用元：https://atmarkit.itmedia.co.jp/ait/articles/1504/08/news002.html 修正した関数と繋がりが ある機能をテストする 開発者に聞いてみよう
25. 修正した機能が出力したデータを参照する他の機能 保存する商品データの形式を修正する場合、商品データ列が「 -」では ない画面のテストをする
26. 修正した画面と同じ画面にある別の機能 商品を表示する列を１列増やし たら他のコンテンツのレイアウト が崩れてしまう 他の機能が動かなくなる といったことを確認する
27. 実際のリグレッションテストの必要性について • 私が現職で過去1年分の主要なリグレッションによる不具合を分析したところ、全て の不具合は修正箇所から推測できる機能（先ほどの４条件に該当する機能）でリグ レッションが発生していました ◦ そのため、現職では毎回全ての機能をテストする必要性はないと考えています ◦ もちろん、利用するフレームワークのメジャーバージョンアップなどでは広範囲のリグレッションテス トは必要 • もし、皆さんがリリース前に毎回全ての機能に対するリグレッションテストを実施し ている場合、本当に必要なリグレッションテストかどうかを調べてみると良いかもし れません
28. プロダクトの仕組みに基づくテスト分析の注意点 • ソフトウェアは複雑なため、プロダクトの動く仕組みを完全に正しく理解することは 難しいです • プロダクトの動く仕組みを把握するのに時間がかかり過ぎる場合は、仕組みを把握 するのを諦めて広めにテストしてしまうのもアリです • 以下のような工夫を活用し、仕組みを誤解した場合のリスクに備えよう ◦ 過去の不具合の知識を活用し、類似した不具合がないかを確認するテストを行う ◦ 探索的テストでテストケース外の様々なテストを行う ◦ 重要な機能は念の為手厚くテストする
29. 本日のまとめ • 全数テストは不可能なので、プロダクトが動く仕組みに基づいてテストする内容を決 めてみよう • プロダクトが動く仕組みを理解して、不要なテストを減らしてみよう ◦ ソフトウェアエンジニアの皆さんが長い年月をかけて不具合が起きにくい工夫を積み重ねてきてい ます ◦ これらの工夫を活用し、プロダクトの動く仕組みを理解してテストも効率化したいですね • プロダクトの仕組みをうまく理解できない可能性も考慮してテストしよう
30. 参考文献 • スライドの内容・構成を考える上で参考にした資料 ◦ 大西 建児、湯本 剛、町田 欣史、福田 里奈、角田 俊、藤原 考功、大段 智広(著). 『ソフトウェアテスト教科書 JSTQB Foundation 第5版 シラバス2023対応』. 翔泳社. 2024 ▪ https://www.shoeisha.co.jp/book/detail/9784798188508 ◦ Glenford J. Myers, Tom Badgett, Todd M. Thomas, Corey Sandler(著), 長尾真(監訳), 松尾正信 (訳) .『ソフトウェア・テストの技法　第 2版』 . 近代科学社. 2019 ▪ https://www.kindaikagaku.co.jp/book_list/detail/9784764903296/
31. 参考文献 • 機能抽象モデルの例 ◦ 井芹洋輝. 『テスト分析入門』 ▪ https://speakerdeck.com/goyoki/test-analysis-tutorial ◦ 山﨑祟. 『テスト開発について改めて考えてみよう！ ～ テスト分析やテスト設計を業務で上手くでき るようになるための四方山話』　 ▪ https://speakerdeck.com/yamasaki696/tesutokai-fa-nituitegai-metekao-etemiyou-tesut ofen-xi-yatesutoshe-ji-woye-wu-deshang-shou-kudekiruyouninarutamenosi-fang-shan-hu a
32. 参考文献 • Webの技術に関して参考にした資料 ◦ 小森裕介(著).『［改訂新版］プロになるための Web技術入門』. 技術評論社. 2024 ▪ https://gihyo.jp/book/2024/978-4-297-14571-2 • この発表に関連する私の過去の記事 ◦ 『社内向けテスト設計プロセスを作ってみた』 ▪ https://tech.commune.co.jp/entry/2022/12/20/112000 ◦ 『テスト設計時に最低限のテストケースを選ぶための工夫（テストケース削減の工夫）』 ▪ https://kawabeaver.hatenablog.com/entry/2021/09/01/003000 ◦ 『修正内容に応じたリグレッションテストの実施範囲』 ▪ https://kawabeaver.hatenablog.com/entry/2021/12/18/000000
33. 参考文献 • 時間の都合上割愛した内容に関する資料 ◦ Tsuyoshi Yumoto. 『テストで「ちゃんと網羅して！」と頼まれたときの返答方法あれこれ』 ▪ https://note.com/yumotsuyo/n/n1276127a938e