ソフトウェアテスト2026

26年度 開運研修 ソフトウェアテスト kintone QA 森内 1

目次 01 ソフトウェアテスト 02 ソフトウェアテストの7原則 03 テストプロセス 04 テスト設計とテスト技法 2

ソフトウェアテスト 3

ソフトウェアテスト ソフトウェアテストとは？ JSTQB (Japan Software Testing Qualifications Board) • ソフトウェアテストに関する考え方・用語・資格の基準をまとめている団体 • 日本で広く使われている業界標準の考え方 この講義は、JSTQBの考え方をベースにしています （参考： https://jstqb.jp/committee.html） 4

ソフトウェアテスト ソフトウェアテストとは？ > ソフトウェアテストは、欠陥を発見し、ソフトウェアアーティファクトの品質を評 価するための一連の活動である。これらアーティファクトは、テストをする際のテス ト対象である。(JSTQB FL) つまり、ソフトウェアテストとはバグを見つけるだけでなく、正しく・安心して使えるかを確認するための 活動である 「動作するか？」だけでなく 「要件を満たしているか？」「ユーザーにとって使いやすいか？」も観点に含まれる 5

ソフトウェアテスト ソフトウェアテストの種類 単体テスト（ユニットテスト、コンポーネントテスト） • 個々のコンポーネントやモジュールが正しく動作するかを確認 結合テスト（インテグレーションテスト） • 複数のコンポーネントが連携して正しく動作するかを確認 システムテスト（総合テスト） • システム全体が要件を満たしているかを確認 受け入れテスト（ユーザーアクセプタンステスト） • システム全体が要件を満たしているかを確認 6

ソフトウェアテスト ソフトウェアテストの種類を説明するモデル : V字モデル 要求分析 受け入れテスト 要件定義 システムテスト 基本設計 結合テスト 開発工程 テスト工程 詳細設計 コーディング 単体テスト コードレビュー 7

ソフトウェアテスト ソフトウェアテストを行うタイミング Q. ソフトウェアテストは、 ソフトウェアが出来上がるまで テストできないのでしょうか？ 8

ソフトウェアテスト ソフトウェアテストを行うタイミング Q. ソフトウェアテストは、 ソフトウェアが出来上がるまで テストできないのでしょうか？ A.ソフトウェアが出来上がる前に、 ドキュメントから欠陥を見つけるテ スト（レビュー）があります! 9

ソフトウェアテスト ソフトウェアテストを行うタイミング 静的テスト 動的テスト ソフトウェアを実行せずに行うテスト ソフトウェアを実際に実行して行うテスト 要件定義書や仕様書、設計書などのドキュ 例 メントから欠陥を見つけるテスト • 単体テスト 例 • 結合テスト • コードレビュー • システムテスト • 静的解析（ツールによるコードチェック） • 受け入れテスト 10

ソフトウェアテスト ソフトウェアテストを行うタイミング 欠陥は、早く見つけるほど修正コストが安い なぜ早期発見が大事？ 後の工程で欠陥が見つかると… • 影響する範囲が広がる • 仕様書・設計書の修正が必要 • 修正後の再テストが増える 時間・手間・コストが大きくなる 静的テストの効果（とても重要） • 要件定義書・仕様書・設計書を確認する • 早い段階で欠陥を見つけられる欠陥箇所だけ直せば済むことが多い 早く・安く・安全に修正できる 11

ソフトウェアテスト ソフトウェアテストを行うタイミング 早い段階のテストはすべて大事 動かす前のテストも大事 • 要件定義書・仕様書・設計書を確認する→ 静的テスト 動かし始めたら、できるだけ早く • 開発の早い段階での 単体テスト • コンポーネントがつながったら 結合テスト 「後でまとめて」ではなく「早めに・こまめに」 12

ソフトウェアテスト ソフトウェアテストを行うタイミング: W字モデル システムテスト 設計 要件定義 基本設計 詳細設計 運用テスト設計 システムテスト 結合テスト 単体テスト設計 単体テスト コーディング コードレビュー デバッグ・修正 デバッグ・修正 デバッグ・修正 開発工程 テスト工程 品質を作りこむ工程 品質を検証する工程 13

ソフトウェアテスト なぜテストが必要なのか？ テストは欠陥を見つけて品質を高めるための手段 テストの役割 • 見つかった不具合を修正することで、ソフトウェアの品質向上につながる • テストは、ソフトウェア開発の各段階で品質を確認する方法 テストが提供している価値 • 各工程で品質を確認することで、関係者（ステークホルダー）の判断材料になる • 「この機能はリリースして大丈夫か？」といった意思決定を助ける ユーザー視点でのテスト • テストは、ユーザーが使ったときの状況を間接的に再現する • テスト担当者は、自分なりに理解したユーザーのニーズが十分に考慮されているかを確認する その他の重要な役割 • 契約上・法律上の要件業界の基準やルールを確認する 守れているかを確認するのも、テストの役割 14

ソフトウェアテストの7原則 15

ソフトウェアテストの7原則 ソフトウェアテストの7原則 1. テストは欠陥があることは示せるが、欠陥がないことは示せない 2. 全数テストは不可能 3. 早期テストで時間とコストを節約 4. 欠陥の偏在 5. テストの弱化 6. テストはコンテキスト次第 7. 「欠陥ゼロ」の落とし穴 16

ソフトウェアテストの7原則 ソフトウェアテストの7原則 1. テストは欠陥があることは示せるが、欠陥がないことは示せない • 欠陥が見つからないとしても、テスト対象の正しさを証明できない 2. 全数テストは不可能 • すべての事前条件、入力を網羅するのは難しい • テストすべき箇所絞り込む必要がある 3. 早期テストで時間とコストを節約 • 早期に検出することで手戻りが少なくなる 4. 欠陥の偏在 • 欠陥は特定の箇所に集中する • リスクに応じてテストの優先度や細かさを変えていくとよい 17

ソフトウェアテストの7原則 ソフトウェアテストの7原則 5. テストの弱化 • 同じテストを繰り返すと新たな欠陥を検出しづらくなる場合がある ※ 自動化されたリグレッションテストなど、繰り返すことで意味があるものもある • テストとテストデータを入れ替える • 新規でテストを作成する 6. テストはコンテキスト次第 • 必ず適用できるテストは存在しない 7. 「欠陥ゼロ」の落とし穴 • バグが0でも、ユーザーのニーズや期待を満たさないシステムになることもある。 18

ソフトウェアテストの7原則 ソフトウェアテストの7原則 テストの考え方で「よくある誤解」を防ぐための原則 テストは欠陥があるこ とは示せるが、欠陥が 早期テストで時間とコ 全数テストは不可能 ストを節約 ないことは示せない テストの弱化 欠陥の偏在 テストはコンテキスト 「欠陥ゼロ」の落とし 次第 穴 19

テストプロセス 20

テストプロセス テストに関するよくある誤解 > テストに関するよくある誤解の 1 つは、テストはテスト実行（すなわち、 ソフトウェアを実行しテスト結果を確認する）だけだというものである。 しか し、ソフトウェアテストには他の活動も含まれる。 そして、ソフトウェア開発 ライフサイクルと整合させなければならない。(JSTQB FL) テスト実行以外にも様々な活動が... • どんなテストをするか計画を立てる • テストに必要なデータや環境を準備する • テストの結果を分析する テストはソフトウェア開発のプロセス全体と連携して進める 21

テストプロセス ソフトウェアテストのプロセス テストプロセスの6つの段階 22

テストプロセス テスト計画 テストを始める前にやる「準備」と「段取り」 テストを始める前に決めること • 何をテストするか → テストする機能／しない機能を決める • いつまでに終わらせるか → 開始日・終了日、修正や再テストの時間 • どうやってテストするか → 誰が？ 手動 or 自動？ どんな環境で？ • 困りそうなことは何か → 仕様未確定・時間不足などを事前に考える • 進み具合をどう確認するか → 進捗・不具合件数などで状況を見える化 23

テストプロセス テストのモニタリングとコントロール モニタリング：状況を見ること コントロール：必要に応じて調整すること • モニタリングの目的 • テストは予定通り進んでいるかを見る • 問題が起きていないかを早めに気づく • 人や時間が足りているかを確認する • コントロールの目的 • 遅れていたら計画を見直す • リスクがあれば対策を考える • テストのやり方を改善する 例： ・毎日テスト件数を確認 → モニタリング ・人を増やす／優先度を変える → コントロール 24

テストプロセス テスト分析 テスト分析 ＝ テストすべきところを選ぶ作業 • 仕様書や設計書を読む • 機能の内容やルールを確認する • 大事そうなところを見つける • よく使われる機能 • ミスや不具合が起きそうな部分 • テストの優先順位を決める • 先にやるところ • 後でもよいところ 25

テストプロセス テスト設計 テスト設計 ＝ どんなテストをするかを具体的に決める工程 • テスト分析の結果をもとに考える • テストすべきところを、どうテストするか決める • テストケースを作る • まだ細かい手順までは書かない「こういうテスト が必要」というレベルで整理する これを ハイレベルテストケース という • テストの全体像を整理する • このテストは何を確認するためのものかなぜ必要 なのかを明確にする 例：テスト設計の成果物（アウトプット） ハイレベルテストケース / 使用するテスト技法 / 手動・自動テストの方針 26

テストプロセス テスト実装 テスト実装 ＝ テストを「実行できる形」にする工程 • テストケースを具体的にする • テスト設計で作った内容を、もっと分かりやす く、誰がやっても同じ結果になるように手順を 書く 例：操作手順 / 入力する値 / 期待される結果 これを ローレベルテストケース という • テスト環境を準備する • テスト用の環境・データを準備する 「すぐテストできる状態」にするのが目的 • 自動テストを作る（必要な場合） • 繰り返し行うテストは、自動化を検討するテス トコードやスクリプトを作成する 毎回手でやらなくてよくなる 27

テストプロセス テスト実行 テスト実行 ＝ テストを行い、結果を記録して共有する工程 • テストを実行する • テスト実装で作成したテストケースに従って操作する • 手動テスト／自動テストを実行する 決められた手順どおりに、正確に行う • 結果を記録する • テスト結果（成功／失敗）を記録する • 気づいたことは細かいことでもログに残す 後から原因調査や再テストに役立つ • 不具合を報告し、再テストする • 不具合があれば、再現に必要な情報を報告する • どのような条件で • どのような問題が発生したか • 不具合が修正されたら、再度テストする（再テスト） 28

テストプロセス テスト完了 テストを振り返り、次に活かす工程 ① テスト結果をまとめる • テストで何を確認したか • どんな不具合が見つかったか • どこまでテストが終わったか テストの成果を見える形にする ② 振り返りを行う • うまくいったこと大変だったこと • うまくいかなかったこと • 改善できそうな点 次回のテストをもっと良くするため ③ 次に向けた整理をする • 不要になったテスト環境の整理 • テストデータや資料の保管 • 次回テストへの申し送り事項を残す 29

テストプロセス ソフトウェアテストのプロセス テストは「計画 → 準備 → 実行 → 振り返り」を繰り返す活動 テスト計画：何をどうテストするか決める テスト分析：テストすべき点を洗い出す テスト設計：テスト内容を考える テスト実装：テストを準備する テスト実行：テストをやってみる テスト完了：振り返って次に活かす 30

テスト設計とテスト技法 31

テスト設計とテスト技法 テスト技法 JSTQBでは、ソフトウェアをテストする方法をいくつかに分類しています • ブラックボックステスト → 中身を見ずに、動きと結果で確認する • ホワイトボックステスト → プログラムの中身を見て確認する • 経験ベースのテスト → 過去の経験や勘を活かして確認する 32

テスト設計とテスト技法 テスト技法 : ブラックボックステスト ブラックボックステスト ＝ 中身を見ずに、動きと結果で確認するテスト 特徴 • プログラムの中身（ソースコード）は見ない • 画面操作や入力結果を確認する仕様書どおりに動くかをチェックする • 利用者（ユーザー）の目線で行うテスト どんなときに使う？ • 画面が正しく表示されるか • 正しい入力・間違った入力で想定どおりの結果になるか • ボタンを押すと、正しい画面に遷移するか 「使ってみて正しいか？」を確認するときに使う 33

テスト設計とテスト技法 テスト技法 : ブラックボックステスト ブラックボックステストの代表的な技法 • 同値分割法 • 境界値分析 • デシジョンテーブルテスト • 状態遷移テスト 34

テスト設計とテスト技法 テスト技法 : ホワイトボックステスト ホワイトボックステスト = プログラムの中身を見て確認するテスト 特徴 • ソースコードや内部の処理を見て行う • プログラムの以下の点に着目して確認を行う ・想定どおりの流れで動いているか ・処理の分岐が正しく動いているか • 作る側（開発者・テスト担当者）の目線で行うテスト どんなときに使う？ • 条件分岐（if / else）が正しく動いているか • 処理の流れに抜けやムダがないか • 特定の条件でしか通らない処理が動くか 「中のロジックが正しいか？」を確認するときに使う 35

テスト設計とテスト技法 テスト技法 : ホワイトボックステスト ホワイトボックステストの代表的な例 • ステートメントテスト プログラムの文が一通り実行されているか確認 • ブランチテスト 条件分岐（YES / NO など）が両方通っているか確認 36

テスト設計とテスト技法 テスト技法 : 経験ベースのテスト 過去の経験や知識を活かして不具合を見つけるテスト 特徴 • テスト設計書どおりだけでなく、気づきや勘も使う • 過去に起きた不具合やトラブルをヒントにする • マニュアルに書きづらい問題を見つけやすい • 人の経験・知識に依存するテスト どんなときに使う？ • 仕様書だけでは不安なとき時間が少なく、重点的に確認したいとき • 「ここ、なんだか怪しい」と感じる部分 • 過去によく不具合が出た機能の確認 「怪しそうなところを重点的に見る」ときに使う 37

テスト設計とテスト技法 テスト技法 : 経験ベースのテスト 経験ベースのテストの代表的な例 • エラー推測 → 過去の不具合から「この操作をしたら壊れそう」と予想して試す • 探索的テスト → テストケースに縛られず、操作しながら考えて試す • チェックリストベースドテスト → 経験から作った確認リストをもとにチェックする 38

テスト設計とテスト技法 テスト技法 ブラックボックステスト ホワイトボックステスト 経験ベースのテスト 何を見る？ 画面の動き・入力結果 プログラムの処理・ロジック 怪しそうなところ 中身は見る？ 見ない 見る 利用者 作る側 （ユーザー） （開発者・テスト担当者） 誰の目線？ 主な確認内容 よく使う場面 正しく動くか 使いやすいか 場合による 経験者の目線 分岐・処理の流れが正しいか 過去に起きやすかった不具合 画面テスト 単体テスト 時間が少ないとき 機能テスト コード確認 最終確認 39

テスト設計とテスト技法 テスト技法の選択 ⚫ テスト対象の種類、複雑さ、規制や標準、顧客または契約上の要件、リスク、テスト目的、入手可能な ドキュメント、テスト担当者の知識とスキル、利用できるツール、納期と予算、開発ライフサイクルモ デル、ユースケース、テスト技法の使用経験、想定される欠陥の種類など多くの要素に依存する。 ⚫ テスト担当者はテストケースを作成する際に、テスト技法を組み合わせて使用する。 → 銀の弾丸があるわけではない。 ⚫ テスト分析、テスト設計、テスト実装の活動では、形式に従わない（ドキュメントがほとんどない）活 動から形式に従った活動まで、テスト技法を使用できる。 https://aster.or.jp/business/seminar_text.html 40

• https://aster.or.jp/business/seminar_text.html

テスト設計とテスト技法 テスト設計 テスト対象 • .com ログイン画面 のパスワード入力フィールド 各アプリにアクセス 41

テスト設計とテスト技法 テスト設計 テスト対象 • .com ログイン画面 のパスワード入力フィールド テスト目的 • .com ログイン画面で、パスワードフィールドに文字列を入力し、 入力内容に応じてログインができることを確認する 42

テスト設計とテスト技法 テスト設計 テスト対象 • .com ログイン画面 のパスワード入力フィールド テスト目的 • .com ログイン画面で、パスワードフィールドに文字列を入力し、 入力内容に応じてログインができることを確認する 仕様（設定例） • パスワードの最小文字数 : 8文字 • パスワードの最大文字数 : 100文字 43

テスト設計とテスト技法 同値分割法 同等に処理されることが想定されるデータをひとまとまりとして扱う • パスワードの最小文字数 : 8文字 • パスワードの最大文字数 : 100文字 44

テスト設計とテスト技法 境界値分析 同値パーティションの 境界 (最小値、最大値) を確認する • パスワードの最小文字数 : 8文字 • パスワードの最大文字数 : 100文字 45

テスト設計とテスト技法 テスト設計 テスト対象 • .com ログイン画面 のパスワード入力フィールド テスト目的 • .com ログイン画面で、パスワードフィールドに文字列を入力し、 入力内容に応じてログインができることを確認する 仕様（設定例） • パスワードの最小文字数 : 8文字 • パスワードの最大文字数 : 100文字 46

テスト設計とテスト技法 テスト設計 テスト観点 • 以下のパターンの場合、ログインが成功すること • パスワードが8文字以上、100文字以下の場合 • 以下のパターンの場合、ログインが失敗すること • パスワードが7文字以下の場合 • パスワードが101文字以上の場合 47

テスト設計とテスト技法 観点 : 条件を満たすときログインが成功すること • 以下のパターンの場合、ログインが成功すること • パスワードが8文字以上、100文字以下の場合 (8文字・50文字・100文字) 手順 1.「.com ログイン画面」を開き、(ログイン名フィールドにログイン名を入力する) 2.パスワードフィールドに以下のデータパターンの文字数で入力を行う 1. 8文字 2. 50文字 3. 100文字 3. ログインボタンを押下する 期待結果 3. ログインが成功し、cybozu.comにアクセスできること 48

テスト設計とテスト技法 観点 : 条件を満たさないときログインが失敗すること • 以下のパターンの場合、ログインが失敗すること • パスワードが7文字以下の場合 (7文字) • パスワードが101文字以上の場合 (101文字) 手順 1..com ログイン画面を開き、(ログイン名フィールドにログイン名を入力する) 2.パスワードフィールドに以下のデータパターンの文字数で入力を行う 1. 7文字 2. 101文字 3. ログインボタンを押下する 期待結果 3. ログインが失敗し、エラーが表示されること 49

最後に 50

本講義で扱った内容は、 ソフトウェアテストのほんの一部 一朝一夕で身につく内容ではない 業務で必要になったときに、 今日学んだ内容を足がかりに！ ©️ Cybozu , Inc. 51

©️ Cybozu, Inc. 52