ソフトウェアテストの概観を学ぶ 2026

ソフトウェアテストについて様々なことを学んでる中で、「枝葉の知識は増えているが、全体感も把握したい」と思うことがありました。
そこで、これまで得てきた知見や手元にある参考文献をもとに、ソフトウェアテストの概観として１つの資料としてまとめたいと思います。

Transcript

1. ソフトウェアテストの概観を学ぶ 2026 ソフトウェアテストを学ぼう
2. 自己紹介 Atsushi Okui (@blue32a_jp) ソフトウェアエンジニア / Webアプリケーション エンジニア / PHPer 関心：設計、コード品質、リファクタリング、テス ト、モデリング
3. はじめに ソフトウェアテストについて様々なことを学んでる中で、「枝葉の知識は増えているが、全 体感も把握したい」と思うことがありました。 そこで、これまで得てきた知見や手元にある参考文献をもとに、ソフトウェアテストの概 観として１つの資料としてまとめたいと思います。
4. 目次 • テストの基礎 • なぜテストが必要か？ • テストの原則 • テスト活動 • テストの分類 • テスト技法 • テスト戦略 • テストと開発プラクティス
5. テストの基礎
6. テストとは？ ”ソフトウェアテストは、欠陥を発見し、ソフトウェアアーティファクトの品質を評価するための一連の活動 で ある。（略）。テストに関するよくある誤解の 1 つは、テストはテスト実行（すなわち、ソフトウェアを実行しテ スト結果を確認する）だけだというものである。しかし、ソフトウェアテストには 他の活動も含まれる。そし て、ソフトウェア開発ライフサイクルと整合させなければばらない 。 テストに関するもう 1 つのよくある誤解は、テストはテスト対象の検証だけに重点を置くというものである。 テストでは検証、つまり指定されている要件をシステムが満たすかどうかを確認することに加えて、 妥当性 確認も行う。妥当性確認では、ユーザーやその他のステークホルダーのニーズを運用環境でシステムが 満たしていることを確認する。 （略） テストは、技術的な活動だけではない 。適切に計画、マネジメント、見積り、モニタリング、コントロールする こともまた必要となる。” ISTQBテスト技術者資格制度 Foundation Level シラバス https://jstqb.jp/syllabus.html
7. テストの目的 典型的なテストの目的（コンテキストによって異なることがある） • 要件、ユーザーストーリー、設計、およびコードなどの作業成果物を 評価する。 • 故障を引き起こし、欠陥を発見する。 • 求められるテスト対象のカバレッジを確保する。 • ソフトウェア品質が不十分な場合の リスクレベルを下げる。 • 仕様化した要件が満たされているかどうかを 検証する。 • テスト対象が契約、法律、規制の要件に適合していることを 検証する。 • ステークホルダーに根拠ある判断をしてもらうための 情報を提供する。 • テスト対象の品質に対する信頼を積み上げる。 • テスト対象が完成し、ステークホルダーの期待通りに動作するかどうかの 妥当性確認をする。 ISTQBテスト技術者資格制度 Foundation Level シラバス https://jstqb.jp/syllabus.html
8. テストの目的＋α ”一方、モダンなソフトウェア開発では、開発の生産性を高め、高品質と高スピードを両 立する、攻めの活動 としてテストを活用する場面が増えています。例えば次のような目 的です。” • 自動化されたテストで品質確認を担保することで、デプロイメントパイプラインを高 速化し、継続的デリバリーを実現して、ユーザからの要求へ迅速に対応できるよう にする • 難易度の高いプロダクトリスクの確認やバグの検出を行えるようにして、より複雑で 高度なプロダクト価値を実現する 『ソフトウェアテスト徹底指南書』 https://gihyo.jp/book/2025/978-4-297-14909-3
9. ASTERセミナー標準テキスト[Ver4.0.0] https://www.aster.or.jp/business/seminar_text.html テストの目的の拡大
10. テストとデバッグは別の活動 ASTERセミナー標準テキスト[Ver4.0.0] https://www.aster.or.jp/business/seminar_text.html
11. ソフトウェアテストが抱える制約 ”テストは様々な目的に対応できる一方でいくつかの制約を抱えており、品質マネジメン トの手法として限界を持っています。” • プロダクトのごく一部しか確認できない ◦ ソフトウェアの実行条件は膨大であり、テストで確認できる条件はごく一部 • テストで確認すべき妥当性が不透明 ◦ 「顧客満足の達成」「プロダクトの成功」が実現したか分かるのは、通常はリリースしてからしばらく 経ってから • 受け身では必要な情報を十分に確保できない • 成果が出るのが遅い • 最小化されたコストやリソースしか使えない 『ソフトウェアテスト徹底指南書』 https://gihyo.jp/book/2025/978-4-297-14909-3
12. なぜテストが必要か？
13. なぜテストが必要か？ ”テストをすることは品質コントロールの形式の 1 つであり、設定された範囲、時間、品 質、予算の制約の中で、合意されたゴールを達成するために役立つ。成功に向けたテス トによる貢献は、テストチームの活動に限定されるべきではない。” ISTQBテスト技術者資格制度 Foundation Level シラバス https://jstqb.jp/syllabus.html
14. 成功に対するテストの貢献 ASTERセミナー標準テキスト[Ver4.0.0] https://www.aster.or.jp/business/seminar_text.html
15. 品質マネジメント • 品質方針および品質目標の設定 • 品質計画 • 品質保証 • 品質管理 • 品質改善 ISO 9000 / JIS Q 9000 https://kikakurui.com/q/Q9000-2015-01.html
16. テストと品質マネジメント ”「テスト」と「品質保証」（QA）という用語を同じように使う人が多くいる。しかし、テストと 品質保証は同じではない。テストは品質コントロール（QC）の形式の 1 つである。 （略） テスト結果は、QA と QC で使用する。QC では欠陥の修正に使い、QA では開発とテス トプロセスがどの程度うまくいっているかについてのフィードバックに使う。” ISTQBテスト技術者資格制度 Foundation Level シラバス https://jstqb.jp/syllabus.html
17. テストと品質マネジメント • 品質方針および品質目標の設定 • 品質計画 • 品質保証　👈 ◦ テスト結果は”開発とテストプロセスがどの程度うまくいっているかについてのフィードバック ”に使わ れる • 品質管理　👈 ◦ テストは品質コントロールの形式の１つであり、テスト結果は ”欠陥の修正”に使われる • 品質改善
18. エラー、欠陥、故障、および根本原因 ASTERセミナー標準テキスト[Ver4.0.0] https://www.aster.or.jp/business/seminar_text.html
19. ASTERセミナー標準テキスト[Ver4.0.0] https://www.aster.or.jp/business/seminar_text.html
20. 組織全体のパフォーマンスとテスト ”「テストの自動化」は継続的デリバリの支柱の１つであり、その関連プラクティスのうち、 我々の分析でITパフォーマンスの予測尺度となりうることが判明したのは次の２つであ る。” • 信頼性の高い自動化テストの実施 • 開発者が主体となった承認テストの作成・管理、および承認テストの容易な複製・ 修正 『LeanとDevOpsの科学』 https://book.impress.co.jp/books/1118101029
21. テストの原則
22. テストの７原則 1.テストは欠陥があることは示せるが、欠陥がないことは示せない 2.全数テストは不可能 3.早期テストで時間とコストを節約 4.欠陥の偏在 5.殺虫剤のパラドックスにご用心 6.テストは状況次第 7.「バグゼロ」の落とし穴 ISTQBテスト技術者資格制度 Foundation Level シラバス https://jstqb.jp/syllabus.html
23. ＋α：テストで品質は上がらない 実録レガシーコード改善 https://speakerdeck.com/twada/working-with-legacy-code-the-true-record
24. 　体重計に乗れば体重は測れるが、それで痩せることはない （テストをすれば品質は測れるが、それで品質が上がることはない）
25. テスト活動
26. テストプロセス テストプロセスは多くの場合、以下に説明する主な活動のグループから構成される。 • テスト計画 • テストのモニタリングとコントロール • テスト分析 • テスト設計 • テスト実装 • テスト実行 • テスト完了 ISTQBテスト技術者資格制度 Foundation Level シラバス https://jstqb.jp/syllabus.html
27. テスト計画 • テストの目的を定義する ◦ 開発ゴールと直結していることが重要 • 使命、目的に合致するようテスト活動を構築する ◦ 最も効果的に達成するアプローチを選択する • テスト計画書は、モニタリングとコントロールのフィードバックに応じて更新する ◦ 一度決めたら良しとするのではなく、状況に変化があったら柔軟に変更する ASTERセミナー標準テキスト[Ver4.0.0] https://www.aster.or.jp/business/seminar_text.html
28. テストのモニタリングとコントロール • テスト計画書で定義したモニタリング用のメトリクスを使用して、テスト計画書の内 容と実際の状況を継続的に比較する活動 • テスト中にテスト情報を要約して、レポートする • テストの情報をステークホルダーに伝達する ASTERセミナー標準テキスト[Ver4.0.0] https://www.aster.or.jp/business/seminar_text.html
29. テスト分析 • 「何をテストするか」を決定する • テストベースを分析し、テスト可能なフィーチャーを識別し、関連するテスト条件を定 義、優先付け、リスク分析を行う 例）マイヤーズの三角形問題なら、「三角形の形状」というテスト条件をテストすると決め る ASTERセミナー標準テキスト[Ver4.0.0] https://www.aster.or.jp/business/seminar_text.html
30. テスト設計 • テスト設計では「それをどのようにテストするか」を決定する ◦ 「それをどうテストするか」の答え • テスト条件をテストケースやその他のテストウェア(テストチャーターなど)へ落とし込 む ◦ 様々なテスト技法を使用する 例）「三角形の形状」というテスト条件に対して、「正三角形、二等辺三角形等」をどうテ ストするか決める ASTERセミナー標準テキスト[Ver4.0.0] https://www.aster.or.jp/business/seminar_text.html
31. テスト実装 • テスト実行に必要なテストウェアを作成、完成させること ◦ 「テストの実行に必要なものすべてを準備したか」の答え 例）「正三角形、二等辺三角形等」になる「三辺の数値セット」を用意し、テスト環境を整 える ASTERセミナー標準テキスト[Ver4.0.0] https://www.aster.or.jp/business/seminar_text.html
32. テスト完了 プロジェクトのマイルストーンで、未解決の欠陥、変更要求、または作成したプロダクト バックログアイテムに対して以下を行う。 • 将来役立つ可能性のあるテストウェアをすべて識別し、保管するか、適切なチーム へ引き渡す • テスト環境は合意した状態でシャットダウンする • 将来のイテレーション、リリース、またはプロジェクトに向けて、教訓と改善点を識別 するために、テスト活動を分析する • テスト完了レポートを作成して、ステークホルダーへ伝える ASTERセミナー標準テキスト[Ver4.0.0] https://www.aster.or.jp/business/seminar_text.html
33. テスト実行 • テスト実行スケジュールに従ってテストスイートを実行する • 手動・自動で以下の活動を行う ◦ テストアイテムまたはテスト対象、テストツール、テストウェアの IDとバージョンを記録 ◦ 手動・自動で使用して テストを実行 ◦ 実行結果と期待結果を 比較 ◦ 不正（ anomaly ）を分析して、可能性のある原因を特定する ◦ 故障（ failure ）を観察し、観察に基づいて不正を報告する ◦ テスト実行の結果（合格、不合格、ブロックなど）を記録 する ◦ 不正への対応の結果、または計画したテストの一環として、テスト活動を繰り返す ◦ テストベース、テスト条件、テストケース、テストプロシジャー、テスト結果の間で双方向の トレーサビ リティを検証し更新する ASTERセミナー標準テキスト[Ver4.0.0] https://www.aster.or.jp/business/seminar_text.html
34. コンテキストに応じたテストプロセス テストを行う方法は、以下のコンテキストに応じた要因に依存する。 ※ テストの原則６. テストは状況（コンテキスト）次第 • ステークホルダー • チームメンバー • ビジネスドメイン • 技術的要因 • プロジェクトの制約 • 組織的要因 • ソフトウェア開発ライフサイクル • ツール ASTERセミナー標準テキスト[Ver4.0.0] https://www.aster.or.jp/business/seminar_text.html
35. テストの分類
36. テストレベル 系統的にまとめ、マネジメントしていくテスト活動のグループ。 • コンポーネントテスト（ユニットテスト） • コンポーネント統合テスト（コンポーネント統合テスト） • システムテスト • システム統合テスト • 受け入れテスト ISTQBテスト技術者資格制度 Foundation Level シラバス https://jstqb.jp/syllabus.html
37. テストサイズ Googleでは各テストを全て規模で分類している。 • Small • Medium • Large Smallテストは単体テストに、Largeテストはエンドツーエンドテストまたはシステムテスト に、Mediumテストは統合テストと呼ばれることが多いテストにそれぞれ相当する。 「単体」「統合」など曖昧な範囲や粒度による分類に現場は混乱しがちになる。その解決 策として注目されている分類。 Google Testing Blog: Test Sizes https://testing.googleblog.com/2010/12/test-sizes.html テストサイズ ～自動テストとCIにフィットする明確なテスト分類基準～ https://gihyo.jp/dev/serial/01/savanna-letter/0003
38. テストタイプ 特定の品質特性に関連するテスト活動のグループ。 ASTERセミナー標準テキスト[Ver4.0.0] https://www.aster.or.jp/business/seminar_text.html
39. 動的テスト/静的テスト 動的テスト：テスト対象を実際に動かしてテストする活動 静的テスト：テスト対象の実行を伴わないテスト活動 ※ 静的テストがソフトウェアテストに含まれていない場合もある（ISTB/JSTQBでは含ま れる） 『ソフトウェアテスト徹底指南書』 https://gihyo.jp/book/2025/978-4-297-14909-3
40. テスト技法
41. 「テスト設計技法」は削る技法 「テスト設計技法」と聞くと 設計≒0から作ること と印象を受けます。 しかし「全数テストは不可能」の 全数テストをする時間はないから実施するテストを絞り込め の「絞り込み」を行うことが本質です。 この「絞り込み＝テスト設計技法」とは「効率よく不具合を検出できる方法」 です。 テスト作成に悩む人へ送るテストの心得【テストは彫刻】 #QiitaQualityForward【LT】 https://speakerdeck.com/syahu_writer/tesutozuo-cheng-ninao-muren-hesong-rutesutonoxin-de-tesutohadiao-ke-number-qiitaqualityforward-lt
42. ブラックボックステスト技法 テスト対象の内部構造を参照することなく、仕様上の振る舞いの分析に基づくものであ る。 代表的な技法： • 同値分割法 • 境界値分析 • デシジョンテーブル • 状態遷移テスト ISTQBテスト技術者資格制度 Foundation Level シラバス https://jstqb.jp/syllabus.html
43. ホワイトボックステスト技法 テスト対象の内部構造や処理の分析に基づくものである。 代表的な技法： • ステートメントテスト • ブランチテスト ISTQBテスト技術者資格制度 Foundation Level シラバス https://jstqb.jp/syllabus.html
44. 経験ベースのテスト技法 テストケースの設計と実装にテスト担当者の知識と経験を効果的に利用するものであ る。 代表的な技法： • エラー推測 • 探索的テスト • チェックリストベースドテスト ISTQBテスト技術者資格制度 Foundation Level シラバス https://jstqb.jp/syllabus.html
45. テスト戦略
46. テスト戦略 概ね以下の３つのどれかの意味づけ。 1. よいテスト設計を行うための、テスト設計の段取り、技法のアプローチ 2. プロジェクトを横断する組織のテストの方法 3. テストの目的を達成させるためのアプローチや方針 『ソフトウェアテスト徹底指南書』 https://gihyo.jp/book/2025/978-4-297-14909-3
47. テスト戦略の具体例 • シフトレフトテスト • シフトライトテスト • リグレッションテスト • Wモデル 『ソフトウェアテスト徹底指南書』 https://gihyo.jp/book/2025/978-4-297-14909-3
48. シフトレフトテストの戦略 動的なテストを遅らせることによる様々な弊害を回避するため、動的なテストのフィード バックをなるべく早く確保するための戦略。 ４種類のアプローチ • ユニットテストや統合テストを充実させて、実装工程の初期からフィードバックを得ら れるようにする • インクリメンタルな開発プロセス • 反復的な開発プロセス • モデルベースのテスト 『ソフトウェアテスト徹底指南書』 https://gihyo.jp/book/2025/978-4-297-14909-3
49. シフトライトテストの戦略 本番環境にリリースした後に実施するテスト。 • 本番環境でないと実現できないテスト条件への対応 • ユーザの運用に関係するプロダクトリスクの確認 アプローチ • 本番の運用環境にて遊休時間にテストを実施する • 実運用中に追加で負荷や障害注入を行って反応を評価する • 実運用中の監視データを評価する 『ソフトウェアテスト徹底指南書』 https://gihyo.jp/book/2025/978-4-297-14909-3
50. リグレッションテストの戦略 リグレッションが発生していないか確認するテスト。 手動テスト以外の手段 • 開発者による変更レビュー • 自動化されたリグレッションテスト • 保護して変更する（Cover & Modify） ◦ リグレッションが発生しそうな箇所に先に自動テストを書くアプローチ • リグレッションリスクを局所化する設計の工夫 ◦ コンポーネント間の結合度を下げる • 高頻度なリリース 『ソフトウェアテスト徹底指南書』 https://gihyo.jp/book/2025/978-4-297-14909-3
51. Wモデルの戦略 Vモデルの各活動に、テスト活動を並行して実施して、そこからのフィードバックで開発工 程の品質確保を目指す。（シフトレフトの一種） 『ソフトウェアテスト徹底指南書』 https://gihyo.jp/book/2025/978-4-297-14909-3 図）V字モデルとは？特徴やメリット・デメリットを解説 https://www.veriserve.co.jp/helloqualityworld/media/20240828001/
52. アジャイル開発とテスト戦略 『Agile Testing Condensed Japanese Edition』 https://leanpub.com/agiletesting-condensed-japanese-edition
53. 継続的デリバリーとテスト戦略 継続的デリバリー（CD）とは、ソフトウェアのインテグレーション、テスト、デリバリーまで の作業を自動で行い、デリバリーを継続的に頻繁に行えるようにするソフトウェアエンジ ニアリングのアプローチ。 • テスト自動化を推進する • 手動テストと自動テストの責任分担の一貫性を確保する • チーム全体アプローチでテストを進める • テストの保守性と信頼性を作りこむ • 自動テストのテストプロセスを整備する • デプロイメントパイプラインをテストプロセスのモデルにする 『ソフトウェアテスト徹底指南書』 https://gihyo.jp/book/2025/978-4-297-14909-3
54. DevOpsとテスト戦略 DevOpsは開発（Development）と運用（Operations）を組み合わせて命名されたソフト ウェア開発手法。技術的な側面だけでなく、運用部門、品質保証部門も重要な構成要素 とする考え方。 継続的テスト /ホリスティックテスト プロダクト開発サイクルの全ての段階、 でプロダクトを間断なくテストする。 『ソフトウェアテスト徹底指南書』 https://gihyo.jp/book/2025/978-4-297-14909-3 継続的テスト（continuous testing）とシフトレフトな活動をアジャイルにどう取り入れるか？ https://agilejourney.uzabase.com/entry/2024/06/25/103000
55. テストと開発プラクティス
56. テストと開発プラクティス テストに関わるその他の開発プラクティス • 継続的インテグレーション/継続的デリバリー（CI/CD） ◦ 自動化による恩恵：迅速なフィードバック、テスト実行の信頼性向上、継続的運用、他のツール・ サービスとの連携 • テストに関する品質特性：テスト容易性（Testability） ◦ 製品の”テストし易さ”との相互関係 • テスト駆動開発、開発者テスト、テストファースト ◦ テスト容易性（Testability）の向上に作用 • バージョン管理、ブランチ管理、機能フラグ（Feature Flag） ◦ CI/CDとテスト方針の連動 • モデリング ◦ 図示による分析やコミュニケーション
57. まとめ
58. まとめ このように、なるべく抽象度の高い要素を挙げても非常に多くの要素があり、またソフト ウェア開発の様々な要素と連動していることが伺え、非常に奥深いものであることがわ かります。 今回のバージョンではざっくばらんに列挙したような形になりましたが、全体と枝葉を行 き来する形で、ソフトウェアテストへの理解を深めていければと思います。
59. 参考文献 • ISTQBテスト技術者資格制度 Foundation Level シラバス ◦ https://jstqb.jp/syllabus.html • ASTERセミナー標準テキスト[Ver4.0.0] ◦ https://www.aster.or.jp/business/seminar_text.html • ソフトウェアテスト徹底指南書 ◦ https://gihyo.jp/book/2025/978-4-297-14909-3 • ISO 9000 / JIS Q 9000 ◦ https://kikakurui.com/q/Q9000-2015-01.html • LeanとDevOpsの科学 ◦ https://book.impress.co.jp/books/1118101029 • 実録レガシーコード改善 ◦ https://speakerdeck.com/twada/working-with-legacy-code-the-true-record • Google Testing Blog: Test Sizes ◦ https://testing.googleblog.com/2010/12/test-sizes.html • テストサイズ ～自動テストとCIにフィットする明確なテスト分類基準～ ◦ https://gihyo.jp/dev/serial/01/savanna-letter/0003 • テスト作成に悩む人へ送るテストの心得【テストは彫刻】#QiitaQualityForward【LT】 ◦ https://speakerdeck.com/syahu_writer/tesutozuo-cheng-ninao-muren-hesong-rutesutonoxin-de-tesutohadiao-ke-number-qiitaqualityforward-lt • V字モデルとは？特徴やメリット・デメリットを解説 ◦ https://www.veriserve.co.jp/helloqualityworld/media/20240828001/ • Agile Testing Condensed Japanese Edition ◦ https://leanpub.com/agiletesting-condensed-japanese-edition • 継続的テスト（continuous testing）とシフトレフトな活動をアジャイルにどう取り入れるか？ ◦ https://agilejourney.uzabase.com/entry/2024/06/25/103000
60. How do you like Testing?
61. 完