Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Sponsored · SiteGround - Reliable hosting with speed, security, and support you can count on.

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

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

Avatar for Atsushi Okui

Atsushi Okui

April 05, 2026

More Decks by Atsushi Okui

Other Decks in Programming

Transcript

  1. 自己紹介 Atsushi Okui (@blue32a_jp) ソフトウェアエンジニア / Webアプリケーション エンジニア / PHPer

    関心:設計、コード品質、リファクタリング、テス ト、モデリング
  2. 目次 • テストの基礎 • なぜテストが必要か? • テストの原則 • テスト活動 •

    テストの分類 • テスト技法 • テスト戦略 • テストと開発プラクティス
  3. テストとは? ”ソフトウェアテストは、欠陥を発見し、ソフトウェアアーティファクトの品質を評価するための一連の活動 で ある。(略)。テストに関するよくある誤解の 1 つは、テストはテスト実行(すなわち、ソフトウェアを実行しテ スト結果を確認する)だけだというものである。しかし、ソフトウェアテストには 他の活動も含まれる。そし て、ソフトウェア開発ライフサイクルと整合させなければばらない 。

    テストに関するもう 1 つのよくある誤解は、テストはテスト対象の検証だけに重点を置くというものである。 テストでは検証、つまり指定されている要件をシステムが満たすかどうかを確認することに加えて、 妥当性 確認も行う。妥当性確認では、ユーザーやその他のステークホルダーのニーズを運用環境でシステムが 満たしていることを確認する。 (略) テストは、技術的な活動だけではない 。適切に計画、マネジメント、見積り、モニタリング、コントロールする こともまた必要となる。” ISTQBテスト技術者資格制度 Foundation Level シラバス https://jstqb.jp/syllabus.html
  4. テストの目的 典型的なテストの目的(コンテキストによって異なることがある) • 要件、ユーザーストーリー、設計、およびコードなどの作業成果物を 評価する。 • 故障を引き起こし、欠陥を発見する。 • 求められるテスト対象のカバレッジを確保する。 •

    ソフトウェア品質が不十分な場合の リスクレベルを下げる。 • 仕様化した要件が満たされているかどうかを 検証する。 • テスト対象が契約、法律、規制の要件に適合していることを 検証する。 • ステークホルダーに根拠ある判断をしてもらうための 情報を提供する。 • テスト対象の品質に対する信頼を積み上げる。 • テスト対象が完成し、ステークホルダーの期待通りに動作するかどうかの 妥当性確認をする。 ISTQBテスト技術者資格制度 Foundation Level シラバス https://jstqb.jp/syllabus.html
  5. ソフトウェアテストが抱える制約 ”テストは様々な目的に対応できる一方でいくつかの制約を抱えており、品質マネジメン トの手法として限界を持っています。” • プロダクトのごく一部しか確認できない ◦ ソフトウェアの実行条件は膨大であり、テストで確認できる条件はごく一部 • テストで確認すべき妥当性が不透明 ◦

    「顧客満足の達成」「プロダクトの成功」が実現したか分かるのは、通常はリリースしてからしばらく 経ってから • 受け身では必要な情報を十分に確保できない • 成果が出るのが遅い • 最小化されたコストやリソースしか使えない 『ソフトウェアテスト徹底指南書』 https://gihyo.jp/book/2025/978-4-297-14909-3
  6. テストと品質マネジメント ”「テスト」と「品質保証」(QA)という用語を同じように使う人が多くいる。しかし、テストと 品質保証は同じではない。テストは品質コントロール(QC)の形式の 1 つである。 (略) テスト結果は、QA と QC で使用する。QC

    では欠陥の修正に使い、QA では開発とテス トプロセスがどの程度うまくいっているかについてのフィードバックに使う。” ISTQBテスト技術者資格制度 Foundation Level シラバス https://jstqb.jp/syllabus.html
  7. テスト計画 • テストの目的を定義する ◦ 開発ゴールと直結していることが重要 • 使命、目的に合致するようテスト活動を構築する ◦ 最も効果的に達成するアプローチを選択する •

    テスト計画書は、モニタリングとコントロールのフィードバックに応じて更新する ◦ 一度決めたら良しとするのではなく、状況に変化があったら柔軟に変更する ASTERセミナー標準テキスト[Ver4.0.0] https://www.aster.or.jp/business/seminar_text.html
  8. テスト設計 • テスト設計では「それをどのようにテストするか」を決定する ◦ 「それをどうテストするか」の答え • テスト条件をテストケースやその他のテストウェア(テストチャーターなど)へ落とし込 む ◦ 様々なテスト技法を使用する

    例)「三角形の形状」というテスト条件に対して、「正三角形、二等辺三角形等」をどうテ ストするか決める ASTERセミナー標準テキスト[Ver4.0.0] https://www.aster.or.jp/business/seminar_text.html
  9. テスト実行 • テスト実行スケジュールに従ってテストスイートを実行する • 手動・自動で以下の活動を行う ◦ テストアイテムまたはテスト対象、テストツール、テストウェアの IDとバージョンを記録 ◦ 手動・自動で使用して

    テストを実行 ◦ 実行結果と期待結果を 比較 ◦ 不正( anomaly )を分析して、可能性のある原因を特定する ◦ 故障( failure )を観察し、観察に基づいて不正を報告する ◦ テスト実行の結果(合格、不合格、ブロックなど)を記録 する ◦ 不正への対応の結果、または計画したテストの一環として、テスト活動を繰り返す ◦ テストベース、テスト条件、テストケース、テストプロシジャー、テスト結果の間で双方向の トレーサビ リティを検証し更新する ASTERセミナー標準テキスト[Ver4.0.0] https://www.aster.or.jp/business/seminar_text.html
  10. コンテキストに応じたテストプロセス テストを行う方法は、以下のコンテキストに応じた要因に依存する。 ※ テストの原則6. テストは状況(コンテキスト)次第 • ステークホルダー • チームメンバー •

    ビジネスドメイン • 技術的要因 • プロジェクトの制約 • 組織的要因 • ソフトウェア開発ライフサイクル • ツール ASTERセミナー標準テキスト[Ver4.0.0] https://www.aster.or.jp/business/seminar_text.html
  11. テストサイズ 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
  12. シフトライトテストの戦略 本番環境にリリースした後に実施するテスト。 • 本番環境でないと実現できないテスト条件への対応 • ユーザの運用に関係するプロダクトリスクの確認 アプローチ • 本番の運用環境にて遊休時間にテストを実施する •

    実運用中に追加で負荷や障害注入を行って反応を評価する • 実運用中の監視データを評価する 『ソフトウェアテスト徹底指南書』 https://gihyo.jp/book/2025/978-4-297-14909-3
  13. リグレッションテストの戦略 リグレッションが発生していないか確認するテスト。 手動テスト以外の手段 • 開発者による変更レビュー • 自動化されたリグレッションテスト • 保護して変更する(Cover &

    Modify) ◦ リグレッションが発生しそうな箇所に先に自動テストを書くアプローチ • リグレッションリスクを局所化する設計の工夫 ◦ コンポーネント間の結合度を下げる • 高頻度なリリース 『ソフトウェアテスト徹底指南書』 https://gihyo.jp/book/2025/978-4-297-14909-3
  14. テストと開発プラクティス テストに関わるその他の開発プラクティス • 継続的インテグレーション/継続的デリバリー(CI/CD) ◦ 自動化による恩恵:迅速なフィードバック、テスト実行の信頼性向上、継続的運用、他のツール・ サービスとの連携 • テストに関する品質特性:テスト容易性(Testability) ◦

    製品の”テストし易さ”との相互関係 • テスト駆動開発、開発者テスト、テストファースト ◦ テスト容易性(Testability)の向上に作用 • バージョン管理、ブランチ管理、機能フラグ(Feature Flag) ◦ CI/CDとテスト方針の連動 • モデリング ◦ 図示による分析やコミュニケーション
  15. 参考文献 • 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