ソフトウェアテストの全ノウハウ│IT初心者のための基本ガイド

はじめに

あなたは「ソフトウェアテスト」に対してどのようなイメージをお持ちだろうか。「難しい」といったイメージだろうか？それとも「よくわからない」といったイメージだろうか？

ソフトウェアには、“目に見えない” “触れることができない” “自由度が高い（法律がない）” といった特徴があり、それだけでも「難しい」「わかりにくい」と思わせてしまう原因を作っているのだが、多人数で開発するときには、そこに “個人への依存度が高い” といった要素も出てくるため、個人差まで考慮しなければならなくなる。そのようなソフトウェアを相手に、“どのようにテストをすればよいのだろうか？” また、“どのようなテストをすればよいのだろうか？”

さて、現実に目を移すと、私たちの生活は好き好まずソフトウェアに依存している。スマートフォンのアプリからオンライン銀行、さらには医療機器の制御システムに至るまで、ソフトウェアがあらゆる場面で使われているのは皆さんもご承知のことだろう。このような状況であるため、もしもソフトウェアが正しく機能しなかった場合には、企業はユーザーに深刻な影響を及ぼしてしまいかねない。たとえば、オンライン銀行で不具合が発生した場合、ユーザーはお金の振込や引き出しができなくなるとともに、振込先の企業や、ひいては世の中全体に大きな影響を与えることとなり、その企業の信頼は、そのまま一直線に失墜してしまうといったリスクに迫られる。

このような背景からわかるとおり、ソフトウェアテストはシステム開発における品質管理の重要な要素となる。ソフトウェアが意図した通りに動作し、不具合や脆弱性がないことを確認するテストプロセスは、ユーザー体験を向上させるのみならず、企業のブランド価値を守るためにも正しく実施すべきこととして、肝に銘じておきたい。

本記事では、ソフトウェアテストの基本概念から様々なテスト技法、ドキュメント、プロセス、タイプ、ツール、定量的品質管理、はたまた新しい手法や原則に至るまで、初心者でも理解できるようなるべく平易な言葉を用いて解説する。さらに、具体的な事例や手順も交えて、より実践的な知識が得られる内容になることも目指す。長い記事になってしまったが、ブックマークをするなどして最後まで目を通していただければ幸いである。

ソフトウェアテストの基本概念

• ソフトウェアテストとは

ソフトウェアテストは、開発されたソフトウェアが顧客の要求、あるいは仕様に基づいて、正しく実装されているかどうかを確認するプロセスである。このプロセスは、製品をリリースするまでになるべく早期に不具合を発見、修正し、リリース可否の判断材料を得ることを主な目的としている。以下は、ソフトウェアテストの実行プロセスの概念を図式化したものである。

▲図１：ソフトウェアテスト実行プロセスの概念図

• ソフトウェアテストの全体像

ソフトウェア開発におけるテスト体系を図式化すると以下のようになる。これらの関係性は是非覚えておこう。

さらに、ソフトウェア開発全体とソフトウェアテストとの関係についても図式化したので、テストの全体感も掴んでおこう。

▲図2：ソフトウェアテストの全体図

• ソフトウェアテストの目的

ソフトウェアテストの目的は、次の3点に集約できる。何事も目的を抑えることがもっとも重要なことであることから、ソフトウェアテストにおいても、まずは目的からしっかりと押さえよう。

• 動的テストと静的テストの比較

テスト体系図の中に動的テストと静的テストが出てきたが、これらは以下のように比較して覚えておくとよい。

	動的テスト	静的テスト
定義	・プログラムコードを実行して、その結果からソフトウェアのバグ検出や品質評価、動作確認を行うテスト方法のこと	・プログラムコードを実行せずに、ドキュメントやソースコードなどのチェックによって誤りや脆弱性を検出するテスト手法のこと
代表例	一般のテスト（動作させないと確認できないテスト）	レビュー、静的解析
メリット	・実際に動作させて、製品仕様を満たしているか確認できる。 ・実際に動作させることで、パフォーマンスやユーザビリティの観点からテストを行うことができる。(仕様の妥当性確認) ・動的に（実行中に）状態や論理が変化することによって引き起こされる問題を見つけることができる（タイミング依存の問題など）	・ソフトウェアの内部構造に関する欠陥（規格からの逸脱や要件の欠陥など）の検出に有効。 ・ソフトウェアを動作させる必要がないので、開発プロセスの早期に実施し、欠陥を検出・修正できる。 ・静的解析ツールを使い、機械的にコードのチェックができる。
デメリット	・動的テスト行うためには、モジュールを作成したり、ソフトウェアを動作できる状態にする必要がある。 ・不具合の検出は、テスターのテクニック等によって差が出やすい。	・パフォーマンスや仕様の欠陥の検出など、ソフトウェアを実際に動作させないと検出しにくい問題に関しては、静的テストでは不向き。 ・ツールによる静的解析は、機械的にチェックをするため、指摘事項が膨大になりやすい。

テストレベル

では、ここからソフトウェアテストの各論の説明に入っていく。まず初めに、「テストレベル」から解説する。

テストレベルとは、ソフトウェアテストを実行する各段階（フェーズ）を示したものである。テストレベルには、それぞれ異なる目的とアプローチがあり、ソフトウェアの品質を確保するためにはそれぞれのテストレベルのテストを段階的に実施することが重要となる。

一般的に、４つのテストレベルがあるので順に見ていこう。

• 単体テスト（UT＝Unit Testing）

項目	説明
レベル定義	ソフトウェアの最小単位であるモジュールや関数をテストするレベル
目的	各モジュールが正しく動作しているかを確認するために行う
実施者	テスター（実際にはプログラマーが実施することが多い）

• 結合テスト（IT＝Integration Testing）

項目	説明
レベル定義	複数のモジュールを統合し、連携して正しく動作するかを確認するテストレベル
目的	モジュール間のインターフェースやデータの流れが正常であるかを確認するために行う
実施者	テスター

• システムテスト（ST＝System Testing）

項目	説明
レベル定義	システム全体が要件で決めた通りに振る舞うかを確認するテストレベル
目的	すべての機能を統合した振る舞いが、要件で定義した内容を満たしていることを確認するために行う（ユーザー視点で確認する）
実施者	テスター

• 受け入れテスト（UAT＝User Acceptance Testing）

項目	説明
レベル定義	顧客やエンドユーザーがソフトウェアを受け入れるかどうかの判断を行うテストレベル
目的	顧客に検収をあげてもらうため、最終的な製品が顧客の要求を満たしているか、また実際の運用に耐えられるかを確認するために行う（顧客との間で合意された基準に基づいて評価する）
実施者	顧客（顧客の代わりにテスターが代行する場合もある）

ちなみに、結合テストは厳密には内部結合テストと外部結合テストに区分できるので、ここで触れておきたい。以下、そのイメージを図解で示す。

▲図3：内部結合テストと外部結合テストのイメージ図

このセクションの最後に、テストレベルの振り返りとして４つのテストレベルを一覧にしておく。

テストレベル	説明	テスト実施者
単体テスト	個々の機能やモジュールをテストする。	開発側
結合テスト	複数のモジュールを組み合わせてテストを行う。
システムテスト	システム全体をテストし、全機能が正しく動作するか、ユーザーの要求通りにシステムが振る舞うかを確認する。
受け入れテスト	ユーザーが要求した機能が実装されているかを確認する。実際のユーザーやクライアントが参加することが一般的。	ユーザー側

テストドキュメント

品質は一般的に、プロダクト品質とプロセス品質の両方の結果が揃ってはじめて、より正確な品質判断が可能になると言われている。これはソフトウェアテストでも同様で、テストドキュメント（プロダクト）はソフトウェアテストの良し悪しの一翼を担っている。よって、ソフトウェアテストをよりよくしていくためには、テストドキュメントの品質を向上させる必要があるのだが、そのポイントは「標準化」で、今から紹介する「IEEE829」という規格がそれに該当する。

• IEEE829とは

IEEE829は、ソフトウェアテストにおけるドキュメント標準を定めた規格である。この規格は、テストプロセスの各ステップにおいて作成される文書の種類や内容を明確にし、テスト活動の計画、実行、結果の記録を効率化することを目的としている。

IEEE829をベースに作成したテストドキュメントは、テストのフレームワークとしてテストの透明性と一貫性が確保できるため、プロジェクト内や異なるプロジェクト間での情報共有が容易になる。また、将来的なメンテナンスや監査を容易にすることも可能になる。

• テストドキュメントの概要

では、まずテストドキュメントのイメージを掴かむところから始める。
IEEE829には、ソフトウェアテストの標準化されたテストドキュメントについて記載されており、そのドキュメント群から抜粋したドキュメント（成果物）を、テストプロセスに沿って並べたものが下図である。

▲図4：テストドキュメント（成果物）の流れ

• テストドキュメントの種類

以下に、IEEE829の中で定義されている実際のドキュメント名を示すので、まずはそこから確認してほしい。英語なのでイメージしにくいだろうか？それぞれの右手に、本記事の中で紹介するドキュメントを並べておいたので、記事全体を通して理解を進めていってもらえればと思う。

ちなみにIEEE829は、ソフトウェア開発における各テスト工程で作成が必要とされるドキュメントの信頼できる指針の一つとして、世界中の開発現場で利用、参照されていることを付け加えておく。

IEEE829	本記事で紹介しているドキュメント
マスターテスト計画（Master Test Plan）	全体テスト計画書
レベルテスト計画（Level Test Plan）	各レベルのテスト計画書（例：結合テスト計画書）
レベルテスト設計（Level Test Design）	各レベルのテスト設計書（例：結合テスト設計書）
レベルテストケース（Level Test Case）	各レベルのテスト仕様書（例：結合テスト仕様書）
レベルテスト手順（Level Test Procedure）
レベルテストログ（Level Test Log）	テストエビデンス
異常報告（Anomaly Report） レベルテスト中間状況報告（Level Interim Test Status Report）	不具合管理表 テスト実施報告書
レベルテスト報告（Level Test Report）	テストサマリレポート
マスターテスト報告（Master Test Report）	ー

• テストドキュメントの体系

テストドキュメント全体の関連性については、以下のような体系となる。なお、単体テストでもテスト設計をする場合はあるが、一般的に行わないことの方が多いため、ここでは省略しているのであしからず。

▲図5：ソフトウェアテストのドキュメント体系

ではさいごに、テストドキュメントのポイントとなるテスト計画の概要を見て、このセクションを締めくくる。

• テスト計画の概要

テスト計画とは、ソフトウェアの品質目標を効率的に達成するために作成するもので、以下のようなテストの指針や概要をまとめたものである。

なお、テスト計画書にはプロジェクトに対する全体テスト計画書と、各テストレベルに対する個別テスト計画書がある。「図5：ソフトウェアテストのドキュメント体系」に示してあるので、再度確認しておいてほしい。

テストプロセス

テストドキュメント（プロダクト）とともに、ソフトウェアテストの良し悪しのもう一翼を担うのがテストプロセスである。ソフトウェアテストの品質（良し悪し）はこの両輪がバランスよく回ってこそ良くなるわけだが、「よいプロダクト（成果物）はよいプロセスがあってこそ成り立つ」ことから、まずはテストプロセスの確立から取り組んだ方が効率がよい。

このテストプロセスについては、「JSTQB」というソフトウェアテスト資格のシラバスに「テスト活動とタスク」という見出しで触れられている。よかったらそちらも確認してみてほしい。

参考：テスト技術者資格制度 JSTQB　Foundation Level シラバス Version 2023V4.0.J02 P.19
https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J02.pdf

テストプロセスもテストドキュメントと同様でポイントは「標準化」となるが、テストは体系立てて順序よく進めていくことが鉄則というふうに覚えておいてほしい。以下にテストプロセスを示したので、順に見ていこう。

ステップ	テストプロセス	説明	成果物
1	テスト計画	テストの目的やテスト対象となる範囲を明確にし、テストの方針や体制、スケジュールなどを策定する。あわせてテストの判定基準やテスト作業の終了基準もこの段階で策定する。	テスト計画書
2	テスト分析	テストベース（テストのインプットとなる成果物）を整理し、テストすべき条件や要件、さらにはそれを実現するテストケースの作成方針（どのテストタイプ、テスト技法を使うかなど）を決定する。	テスト設計書
3	テスト設計	テスト分析で洗い出した条件や要件を満たすような具体的なテストケースを検討する。このときテスト技法を用いて、抜けもれや重複のないようにするとともに、異常系や境界値等も考慮する。
4	テスト実装	テスト設計で検討したテストケースを元に、実際にテスト実行するための具体的な手順等を付け加える。また手順と合わせて、想定した振る舞いを確認するためのテストデータや、実行を自動化する場合はテストスクリプトも、この段階で作成する。	テスト仕様書 テストデータ テストスクリプト（自動化する場合）
5	テスト実行	テスト実装で作成した手順に従ってシステムを操作し、期待結果どおりになるかを確認する。期待通りでない場合は、不具合管理表に記載する。（必要に応じてキャプチャなどのテストエビデンスを残す） また、テストの進捗状況も把握しながらテストを消化していく。	テスト実施報告書 不具合管理表
6	テスト評価	実行したテスト結果は都度評価し、不具合を発見した際は都度その状況を確認する。その後、それぞれの重大度や影響度に応じて分類し、修正の有無や優先順位を決定する。
7	不具合修正	決定した優先順位に従って不具合を修正していく。	修正後のコード
8	修正確認テスト	修正箇所と、修正により影響のあった箇所を対象に再テストを行う。影響のあった箇所については、正常に動作することがテスト観点となる。もし、影響範囲が特定できない場合は回帰テストを実施する場合もある。	テスト実施報告書 不具合管理表 （再テスト分を追記）
9	終了判定	修正確認テストの結果を分析し、作業を終了して次に進んでよいかどうかを判定する。	テストサマリレポート
10	終了作業	作業の最終確認や今後の活動へのフィードバックを実施する。計画通りに成果物が作成されているか、未対応の不具合はないか、あるとしたら今後の対応方針は決まっているか、などを確認する。	テスト計画書（修正版）

これらのテストプロセスはどれも欠かせないが、もっとも重要なプロセスは、やはり効率的なテストを行うためのテスト計画の立案である。なぜなら、「テスト計画を立てること」は「テスト戦略を立案すること」とイコールであるため、テスト計画が不十分であったり、計画自体がなかったりすると、次に示すような、なかなか判断し難い（コントロール不能な）事態に対応しきれなくなるからである。

結論として、逆説的な言い方で恐縮だが、このような事態の対応方法までが書かれているテスト計画書が、本来求められているテスト計画ということになる。

ではさいごに、テストプロセスのポイントを示してこのセクションを締めくくる。

• テスト分析・設計をしないことによるデメリット

テスト分析とテスト設計を行う理由は、テストの目的や確認ポイントをより明らかにしたいからである。テスト分析・設計を行わなかった場合、以下のような不都合が出てくるので注意しよう。

結論、テストケースを作成するまでに至った意図や過程がわからないと、後々問題になる可能性がある。覚えておこう。

テストとV&V（検証と妥当性確認）の関係

ソフトウェアテストとはつまり、「ソフトウェア品質を確認すること」である。そして、そのソフトウェア品質を確認するための観点に、「検証（Verification）」と「妥当性確認（Validation）」の2つのプロセスが存在する。この２つのプロセスは、それぞれが補完し合いながら品質が確保される仕組みとなっており、この２つのプロセスを併せて「V＆V」と呼ぶ。このV＆Vの概念もソフトウェアテストにとって非常に重要なことであるため、しっかりと押さえておきたい。

まず、V＆VのそれぞれのVの説明から行う。

V＆V	説明
検証（Verification）	ソフトウェアがインプット（設計書）どおりに正しく実装されているか、つまり“正しく製品を作っているか”といった開発者の視点から機能を確認することである。
妥当性確認（Validation）	ソフトウェアがユーザーの要求を満たしているか、つまり“正しい製品を作っているか”を確認することで、ユーザー視点からユーザーが期待している機能や性能が本当にユーザーの期待通りになっているかを確認することである。

この説明で理解できただろうか。では、以下のような不具合が検出された場合は、V＆Vのどちらで確認すべきだったか？少し考えてみてほしい。

どうだろう？簡単すぎただろうか？では、答えを見ていこう。

１と２の不具合は、どちらも機能が実現できていないことから、検証（Verification）で確認すべき不具合である。

１．入力データが反映されない不具合 ２．計算結果が間違っている不具合

→　検証で発見すべき不具合

一方、３と４の不具合は、要求が満たせていない内容であることから、妥当性確認（Validation）で確認すべき不具合ということになる。

３．画面UIがわかりづらいといった不具合 ４．画面遷移の待ち時間が長いといった不具合

→　妥当性確認で発見すべき不具合

これらの不具合はどちらもあってはいけないのだが、テストの順番としては、機能をテストして検証レベルの不具合を潰してから、システム全体の振る舞いについての妥当性を確認するといった順番になることを覚えておこう。もしこの順番通りにテストを進めなかった場合、いつまでたっても不具合が収まらなくなるといったことになりかねないので、十分に注意してほしい。

▲図６：V字モデルとV＆Vの関係

▲こんな記事も読まれています

テストファースト

唐突だが、あなたはW字モデルのことをご存じだろうか？簡単に説明すると、V字モデルの進化形で、開発とテストを同時並行的に進める形を概念化したもので、「開発フェーズもテスト視点を持って進めよう」といったことを強調したモデルである。（いわゆるテストファーストと考え方は同じ）

要するに、W字モデルでは、開発中は終始テストをしているような恰好になるため、このモデルを採用すると、もちろん高品質な製品が出来上がる確率が高くなる。

しかしながら、W字モデルも万能というわけではなく、プロジェクトの特性によっては向き不向きがある。以下にその事例を挙げておく。

▲こんな記事も読まれています

テストタイプ

テストタイプは、特定の目的や方法に基づいて分類されるテストの種類のことを指す。平たく言えば、「テストの狙いで区分した各テストの集合体」ということである。

テストタイプは更に、異なるテストタイプを組み合わせることでより効果的なテストができるようになるため、どのようなテストが有効か？といったテストの狙いをよく考慮して選択するようにしたい。

では、次に代表的なテストタイプを選んで説明する。

• 機能テスト

テストレベル	結合テスト
目的	ソフトウェアが要求された機能を正しく実行できるかを確認するため
例	入力データに対して期待結果通りに出力されるかを確認するテスト

• 画面テスト

テストレベル	結合テスト
目的	対象に画面がある場合（Webサービスやスマホアプリなど）が設計通りに正しく動作（表示）するかを確認するため
例	画面の各要素（ボタン、テキスト、画像など）が設計通りになっているかを確認するテスト

• 回帰テスト（リグレッションテスト）

テストレベル	結合テスト、システムテスト
目的	コードの変更が既存の機能に影響を与えていないかを確認するため
例	新機能の実装後に、前回テストした機能が正常に動作するかを確認するテスト

• シナリオテスト

テストレベル	システムテスト、受け入れテスト
目的	ステークホルダー別で想定される一般的な使い方やイレギュラーな使い方が問題なくできるかを確認するため
例	業務フローの通りに問題なく操作ができることを確認するテスト

• ユーザビリティテスト

テストレベル	システムテスト
目的	ユーザー視点で、使いづらい、見づらい、分かりづらいところがないか確認するため
例	新しく設計した画面のUIがユーザーにとってわかりやすいかを確認するテスト

• 負荷テスト

テストレベル	システムテスト
目的	システムがどの程度の負荷に耐えられるか確認をするため
例	システムが同時に100人のユーザーからのアクセスに耐えられるかを確認するテスト

• パフォーマンステスト

テストレベル	システムテスト
目的	システムのパフォーマンスを測定し、要求を満たしているかを評価するため
例	Webアプリケーションが特定の負荷条件下でどれだけの速度で動作するかを確認するテスト

• 探索的テスト

テストレベル	システムテスト
目的	テストケースを全て消化したあとに、テストケース以外で不具合がないかを確認するため（経験ベース）
例	テーマを決めてテスターの経験値ベースで、不具合が潜在していそうな箇所に対して行うテスト

• マニュアルテスト

テストレベル	受け入れテスト
目的	マニュアルに記載の操作手順に誤りがないことを確認するため
例	作成したマニュアルの記載内容に沿って、間違いなく操作できるか確認するテスト

テスト技法

テスト技法とは、テスト分析やテスト設計を行う際に効率のよいテストを実施するための手法やテクニックのことである。ソフトウェアテストは一般的に、すべての条件の組み合わせをテストしようとすると、その数が膨大になりすぎて現実的ではなくなる。そのため、効率的かつ効果的なテストを実施するためにテスト技法を用いる。

では、テスト技法について解説していく。

• テスト技法の分類

テスト技法は、大きくブラックボックステストとホワイトボックステストに分類される。（その間に位置するグレーボックステストも存在はする）以下、それぞれの概要を説明する。

▲図７：ブラックボックステスト、ホワイトボックステスト、グレーボックステストのイメージ図

• ブラックボックステストの代表例

次に、ブラックボックステストの中でよく用いられるテスト技法を説明する。

以上、ブラックボックステストの代表的な技法を紹介したが、もちろんブラックボックステストには、それ以外のテスト技法もある。以下に、それ以外のテスト技法も含めて一覧にしたので、必要なときに見直してほしい。ソフトウェアテストは、限られた時間の中でいかに有効なテストができるか？ということが求められるため、テスト技法は効果的に活用できるようにしよう。

技法名	方法
同値分割	連続する値の入力条件をグループにまとめ、それぞれのグループで代表値を１つずつテストケースとして作成する。
境界値分析	連続する値の境界を識別し、境界付近の値を計４つテストケースとして作成する。
デシジョンテーブル	条件の組み合わせの相互作用をデシジョンテーブルで整理し、それを網羅するテストケースを作成する。
状態遷移テスト	状態遷移を状態遷移図や表で整理し、それを網羅するテストケースを作成する。
組み合わせテスト	パラメータの組み合わせを網羅するテストケースを作成する。この技法には直行表とオールペア法がある。
ユースケーステスト	仕様をユースケースで整理して、それを網羅するテストケースを作成する。
探索的テスト	テストの実行結果を見て経験値から不具合が潜んでいそうなところを重点的にテストする。（テストケースは作成しない場合が多い）

テスト仕様書（テストケース）の作成（ポイントのみ）

テスト仕様書（テストケース）は、設計したテストケースをテスト実施者が間違いなく実行できるよう、手順や期待結果などをまとめたものである。組織によっては、「テストケース」や「チェックリスト」など様々な呼び名が付いているようだが、全て同じものである。ここでは、テスト仕様書作成時に押さえておきたいポイントをまとめておく。

ポイント	注意点
期待結果	1つのテストケースに対して期待結果は1つにすること
入力値	入力値は指定した方がよい（指定しなかった場合、何を入力してテストしたかわからないため、正確なテストが実施されたかが判断できない）
手順	手順はなるべく省かないようにする（手順ごとに番号を振るとよい）

▲図１１：テスト仕様書（テストケース）のイメージ

ちなみに厳密には、「テストケース」はひとつひとつのケースのこと、「テスト仕様書」は作成したテストケースの集まり（全てのテストケース）のことを指す。これも覚えておこう。

不具合管理

ここからは、テストで検出した不具合の管理について一通りのことを解説する。

• 不具合の定義

不具合とは、ソフトウェアが「期待通りに動作しない状態」や、「ユーザーの要求とは異なった振る舞いをする状態」のことを指す。

• 不具合管理のプロセス

不具合は、基本的に以下の流れで管理する。以下、ステップごとに説明する。

ステップ	作業	説明
１	不具合の報告	不具合を発見したら、不具合管理表に詳細を記載する。記載内容には、再現手順や環境情報を含める。
２	不具合の優先順位付け	不具合管理表に並んだ不具合の深刻さや影響度に応じて優先順位を設定する。また、修正しない不具合がある場合は修正しない理由を明確にする。
３	不具合の修正作業	優先度の高い不具合から修正に取り掛かる。優先度の低い不具合まで、修正すると決めたすべての不具合に対して修正作業を行う。
４	不具合修正後の再テスト	修正が完了したら再度テストを実施し、修正ができていること、また修正により既存の機能に影響していないかを確認する。もし、修正が未完了だった場合は、再度不具合修正作業に戻る。
５	不具合のクローズ	再テストが完了したらその不具合をクローズする。ここまでの流れを修正する全ての不具合に対して実施する。

▲図１２：不具合対応フロー（イメージ）

• 不具合管理表への記載内容

不具合報告（不具合管理表への記載内容）は具体的かつ明確でないと、修正作業を行う開発者に「何をどのように修正すればよいか」が正確に伝わらないことがある。そのようなことが起こらないよう、不具合報告には最低限、以下の情報を含めること。

報告内容	説明・備考
不具合の説明	説明は5W2Hに沿いつつ簡潔に記載する。（これによって具体的な説明になる）
再現手順	不具合が発生するまでに行う操作すべてを手順として記載する。（手順は省略してはいけない）
エビデンスの添付	エビデンスとして、スクリーンショットやログファイルを添付する。 （これらの取得には時間がかかるため、テストに使える時間との兼ね合いをみて可能な限り取得するようにしたい）

▲図１３：不具合管理表のイメージ

• 不具合管理ツール

不具合管理は、エクセルなどのテンプレートで管理する場合やツールを利用する場合など、その組織によってさまざまだが、ツールを利用した方が作業を効率化できる要素は多い。無料で使えるもの（例えば“Redmine無料版”など）もあるので、まだ試したことがない方は一度試してみてほしい。

５分でわかるRedmineの概要
https://redmine.jp/gofun/overview

• 不具合のパターン

ソフトウェア開発とは、顧客の要求から要件を定義して、それをプログラムで実現しようとする一連の活動である。この活動途中で何らかのヒューマンエラーが起きたときに不具合が混入してしまうわけだが、その原因は一つとは限らない。一度じっくりと下図をみながらその原因を考えてみてほしい。きっと新しい発見があると思う。

▲図１４：不具合のパターン

No.	結果	状況	不具合の原因
１	仕様通りに動作する	要件定義とプログラムが一致している	なし
２	仕様と異なった動作をする	要件定義通りにプログラムされていない	誤り
３		要件定義がプログラムされていない	漏れ
４		要件定義にないことがプログラムされている	冗長
５	仕様自体が間違えている	要件定義のミス	要求の抽出漏れ

▲こんな記事も読まれています

テストの定量的品質管理

ソフトウェアには“目に見えない”という特徴がある。そのため、管理するためにはソフトウェアの状況を目に見えるようにする必要がある。ここで登場するのが定量的品質管理である。ソフトウェア品質を取り扱う上で一番重要なことは品質を見える化することであり、中でも数値化がポイントとなる。

数値への置き換えが可能になると、グラフ形式にして上がり下がりの推移がわかり、比較もできる。そして、比較により分析も可能になり、客観的な評価も可能になる。それを体系的にしたものが定量的品質管理である。

定量的品質管理の第一歩目は、適切なメトリクスを定義することから始まる。メトリクスはあまり聞き慣れない用語だと思うので、まずはメトリクスの意味から確認しよう。

では、次からメトリクスの具体例をみていこう。テストで定量的品質管理を行う上では、以下のメトリクスが代表的で、実際のプロジェクトでも用いられる場合が多い。それぞれがどのような指標なのかを解説する。

メトリクス	説明	見方
バグ密度	ソースコード1,000行あたりの不具合数の割合	バグ密度が高い場合は、品質がよくないか、普段より有効なテストができたかの何れかが想定できる
テスト密度	テストケース数をテスト対象の機能やソースコードの行数で割った割合	テスト密度が高いほどテストが網羅的であることを示すが、テストの有効性はどうであったかを考慮する必要がある

あと、あまり知られていないが、不具合を修正するまでの時間をメトリクスとして収集するのも、テストプロセスを見直したい組織にとっては意味があったりする。

メトリクス	説明	見方
不具合修正時間	不具合を発見してから修正完了までにかかった時間（日数）	修正時間が長い場合は、その原因を追究し、プロセスの見直しが必要かどうかを判断する

実際の分析方法には、管理図分析やゾーン分析等があるが、ここではイメージだけをお伝えする。特にIPAの資料にとても詳しく書かれているので、そちらを参考にしてほしい。

▲図１５：モデルを用いた分析方法（続 定量的品質予測のススメ　P.14から抜粋）

【IPA】定量的品質予測のススメ
https://www.ipa.go.jp/archive/publish/qv6pgp0000000yw8-att/000005133.pdf

【IPA】続 定量的品質予測のススメ
https://www.ipa.go.jp/archive/publish/qv6pgp0000000zi2-att/000005143.pdf

テストチームの構築と管理

ソフトウェアテストは一人でやることよりも、チームを組んで進めるシチュエーションの方が圧倒的に多くなる。そのため、テストチームについても触れておく。

• タスクと役割分担

テストを進めるうえで発生する主なタスクとその役割分担は、だいたい以下のようになる。

タスク	役割分担
全体テスト計画の策定	プロジェクトマネージャー
レベルテスト計画の策定	テストマネージャー
テストのコントロール、モニタリング	テストマネージャー
テスト分析→設計→実施	テストチーム
テスト実行	テストチーム
不具合起票	テストチーム
不具合修正有無の決定及び修正作業	開発者
修正確認テスト実行	テストチーム
振り返り	関係者全員

• テストチームのスキルセット

上表のとおり、テストチームはテストの実務全般に携わるため、一般的なテストの技術以外にも求められるスキルがある。テストチームの一員になったら、テスト技術以外の以下のスキルも身に付ける必要がある。

スキルセット	説明
ドキュメント読解力	インプットとなる仕様書や設計書からテストケースを抽出する際に必要となる
テスト技術力	手動のテストのみならず、自動化テストの知識と技術も必要となる
コミュニケーション力	プロジェクトの他のチームメンバーとの連携が必要で、特に開発者とのコミュニケーションが多くなる
作業の正確性	間違ったテストをしても全く意味がないため、テスターには作業スピードとともに作業の正確性が重要視される。

• テストチームの管理

テストチームを効果的に管理するため、テストマネージャーになったら以下のポイントに留意しよう。

ポイント	説明
定期的にミーティングを実施する	進捗や課題については、なるべくデイリーでミーティングを行うようにし、何か問題が起きた場合にはすぐに手を打てるようにしておくことが重要。 また、テスターの相談にも対応できるように1on1なども考慮する。
エスカレーションを徹底させる	致命的な不具合が発見された場合などは特にマネージャーにすぐに報告があがるように体制を整えておく。なお、不具合の状況によっては、テストの優先順位を変更するなどの判断が必要となる場合があるため、指示が徹底できる仕組みについても考慮すること。
トレーニングの機会を設ける	テストの進捗はテスターのスキルに左右されることが多いため、必要に応じてテスターに対するトレーニングの機会を設ける。特に新しい技術や手法を取り入れる際は、トレーニング期間を設けることは必須と心得ておくこと。

 手動テスト vs 自動化テスト

ここからは、テスト関連で知っておいたほうがよいことを解説していく。まずは自動テストから見ていこう。

これまで説明してきたような、テストケースを一つ一つ人の手で行うテストを手動テスト、一方、スクリプトやツールを利用して人の手を介さずに行うテストを自動化テストと呼ぶ。いま世の中的には、「テストが早く大量にこなせる」「コストが安くなる」といった呼び声でテスト自動化の風潮に流れつつあるようだが、本当にその流れに従うことはよいことなのだろうか。以下に、自動化テストと手動テストを項目ごとに並べ、それぞれを比較しながら考察してみたいと思う。

項目	手動テスト	自動化テスト
テスト準備について	自動化テストよりも早くできる（ただし毎回準備する必要がある）	スクリプトの用意など、手動テストよりも時間がかかる（ただし今後も同じテストをする場合は次からは準備は不要）
テスト実行について	手動で行う	自動でできる
テスト実行時の応用について	不具合が発見されたとき、本当に不具合なのか、テストケースが間違えているのか、などとテストケース以外のことについて探索的にテストをしている	テストケース以外のテストはしない（できない）
テストの進捗（テンポ）について	すべてのテストケースを同じテンポで進めることはできない（テストケースが読み解けなかったり、不具合かどうかを確かめるのに時間がかかったりする）	同じスピードでテンポよく進めることができる
テストの実行スピードについて	テスト実行スピードは遅い（自動化テストと比べものにならない）	テスト実行スピードは速い（反復的なテストに有効）
テストの実行時間帯について	テスト実行はテスターがいる時間のみしかできない	テスト実行は一日中可能
テストの正確性について	ヒューマンエラーは避けられない	エラーは起こらない（決めたとおりに実行する）
ユーザビリティについて	使いやすさや見やすさなど、ユーザーになりきって確認でき、テストケース以外の不具合にも気を配ることができる（例えば画面遷移テストで画面のレイアウト崩れに気づくなど）	できない（というか向いていない） また、テストをした時に手動だったら気づくようなテストケース以外の不具合（レイアウト崩れなど）は発見できない（事前に設定されたテストコードに従ったテストしか行わない）
イレギュラーなテストについて	できる（テスターの判断により広範に行うことが可能）	できない（テストできるのは記述した範囲のみ）
回帰テスト（テストケースが固定）について	自動化テストに勝る特徴はない	自動化テストが得意とするテスト
テスト結果判断について	主観的になることがある	期待結果と同じであればOK、異なればNG（それ以外の判断はない）
新たな不具合の発見について	人がアナログ的に判断するため、新たな不具合が発見されやすい	人が決めたテストしかしないため、新たな不具合が見つかることはない
不具合分析について	不具合を発見する毎に再現性も含めて確認しているので、分析時には手間や時間がかからない	発見された不具合は、あとから人の手で一つ一つ再現しなければならないため、分析には多くの手間と時間を要する
テストメンテナンスについて	ざっと見直す程度	スクリプトのメンテナンスが必要
毎回新しいテストケースを作成する場合	テスト分析、設計をしてからテストケースを作成（今まで通り）	テスト準備でコストがかかるため、同じテストケースを繰り返しできないようなテストに有効性はない
ツール選定について	ツールは使わない	機能とコストのバランスが難しい（一番安価なものをまず使ってみて、使い勝手の悪い部分や、実装されてなくて困った機能等をリストアップして、それら問題が解決できるツールを選択するのがベター）
コストについて	①初期投資＝不要 ➁実行＝必要（テスト工数（人件費）がかかる） ③不具合分析＝必要（工数（人件費）がかかる ④メンテナンス＝ほぼ不要	①初期投資＝必要（自動化ツール導入費、スクリプト作成） ➁実行＝不要 ③不具合分析＝必要（工数（人件費）がかかる（※但し不具合があったことしかわからないため、人の手で再現手順の確認などイチから不具合分析を行わなければならない） ④メンテナンス＝必要（スクリプトの書き換え作業が発生する）

このように、自動化テストは万能ではなく、手動テスト、自動化テスト、それぞれに利点もあれば欠点もある。自動化テストが効果的な繰り返しできるテストにおいてはとても有効な手段となるが、ツールの導入やスクリプトの準備、メンテナンス等に結構な額のコストがかかることもあり、自動化の導入を進める際は、十分に検討したうえで手を打つようにしたいところだ。

テスト自動化の８原則

「テスト自動化の８原則」についてはご存じだろうか。テスト自動化の８原則は、テスト自動化研究会により導き出された、さまざまなテスト自動化に共通する原則のことで、テスト自動化に取り組む際の注意点が網羅的に書かれている。

テスト自動化については、この８原則も紹介しておきたいと思う。なお、詳細については下記URLから確認してもらえればと思う。

• テスト自動化の８原則

原則１	手動テストはなくならない
原則２	手動でおこなって効果のないテストを自動化しても無駄である
原則３	自動テストは書いたことしかテストしない
原則４	テスト自動化の効用はコスト削減だけではない
原則５	自動テストシステムの開発は継続的におこなうものである
原則６	自動化検討はプロジェクト初期から
原則７	自動テストで新種のバグが見つかることは稀である
原則８	テスト結果分析という新たなタスクが生まれる

引用：テスト自動化の８原則https://sites.google.com/site/testautomationresearch/test_automation_principle

アジャイル開発とテスト

さて、ここからはアジャイル開発とテストについて見ていこう。

アジャイル開発と言えば、俊敏さ、柔軟性、頻繁なリリースといったイメージだと思うが、ソフトウェア品質を「品質＝顧客満足」と単純化して考えた場合、アジャイル開発ほど高品質な開発手法はないと考えている。なぜなら、アジャイルの特徴である「俊敏さ」「柔軟性」「頻繁なリリース」はすべて顧客が喜ぶ要素だからである。

例えば、頻繁なリリースについては、顧客がその都度動くものに対してOKサインを出していることになる。つまり、アジャイル開発とは、常に顧客を満足させながら開発を進める高品質な開発手法だと言える。

また、アジャイル開発に合わせたテスト方法に、いくつかのベストプラクティスも存在するので、以下に紹介しておく。

テスト方法	説明
テスト駆動開発（TDD）	先にテストケースを書いてからコードを書くアプローチのこと。この手法により、コードが期待される動作を満たすことが確実になる。
ペアプログラミング	2人のプログラマーが1台のコンピュータを使って共同でコードを書くプロセスのこと。2人が協力することで各自の知識やスキルが相互に補完され、新しい技術やライブラリについての理解が深まるといった利点がある。
継続的インテグレーション（CI）	コードが変更されるたびに自動的にビルドとテストを行うプロセスのこと。変更の影響を早期に確認できるのが利点となる。

▲図１６：テスト駆動開発（TDD）のイメージ図

新しいテスト手法とツールの登場

これからのテクノロジーの進化と共に、ソフトウェアテストもより変化が求められるようになるはずだ。実際にAIを活用したテストも登場しており、今後AIにより、ソフトウェアテストがもっと楽に、もっと効率的になる日はそう遠くないのかもしれない。では、いま注目されているテストをざっと確認しておこう。

注目されているテスト	新機能	できること
AIを活用したテスト	自動テスト生成	過去のテスト結果をもとに、新しいテストケースの自動生成が可能になる
	異常検知	パターン学習により、予期しないバグの早期発見が可能になる
クラウドベースのテスト環境	スケーラビリティ	必要に応じてリソースが追加できるようになることで、負荷テストや大規模なテストの実施が容易になる
DevOpsとの統合	テストの自動化と統合	開発プロセスのテストが自動化されていくとともに、コードの変更ごとに即座にテストの環境構築が可能になる（※DevOpsの流れにより、開発と運用の一体化が進む中で、テストもこの流れに組み込まれることが予測される）

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

５章テストプロセスで採り上げたJSTQBには、「テストの原則」についても書かれている。

参考：テスト技術者資格制度 JSTQB　Foundation Level シラバス Version 2023V4.0.J02 P.18
https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J02.pdf

実際には７つの原則が示されているが、ソフトウェアテストに携わる者としてはどれもこれも最低限知っておくべきことなので、最後に紹介しておく。それぞれその意味するところをしっかりと吟味しながら読み進めてほしい。

原則１	テストは欠陥があることは示せるが、欠陥がないことは示せない
	JSTQBによる説明	テストにより、テスト対象に欠陥があることは示せるが、欠陥がないことは証明できない。テストにより、テスト対象に残る未検出欠陥の数を減らせるが、欠陥が見つからないとしても、テスト対象の正しさを証明できない。
	私見	いかに有効なテストができるかがポイントとなる。
	ポイント	「網羅性が高いこと」、そして「正確なテストを実施すること」の２点がテストの有効さを示す。
原則２	全数テストは不可能
	JSTQBによる説明	すべてをテストすることは、ごく単純なソフトウェア以外では非現実的である。全数テストの代わりに、テスト技法、テストケースの優先順位付け、リスクベースドテストを用いて、テストにかける労力を集中すべきである。
	私見	テスト戦略とテスト技法はやはり重要である。
	ポイント	テスト戦略（テスト計画）とテスト技法はソフトウェアテストには欠かせない。
原則３	早期テストで時間とコストを節約
	JSTQBによる説明	プロセスの早い段階で欠陥を取り除くと、その後の作業成果物では取り除かれた欠陥に起因する欠陥を引き起こすことはない。SDLCの後半に発生する故障が少なくなるため、品質コストは削減される。早い段階で欠陥を見つけるために、静的テストと動的テストの両方をなるべく早い時期に開始すべきである。
	私見	手戻りは悪以外何物でもない。手戻りを少なくするには、テストファーストの考え方（W字モデルの概念）が重要。また、レビューとテストの質の向上に取り組むことも重要。
	ポイント	１：１０：１００の法則を理解しておくこと。（図１７参照）
原則４	欠陥の偏在
	JSTQBによる説明	通常、見つかる欠陥や運用時の故障の大部分は、少数のシステムコンポーネントに集中する。この現象は、パレートの法則を示している。予測した欠陥の偏在、および実際にテスト中または運用中に観察した欠陥の偏在は、リスクベースドテストの重要なインプットとなる
	私見	不具合が偏在する理由はある程度想定できる。（例えば、開発者の知識とスキルのレベル、プログラムの難易度、新しい技術の導入など）
	ポイント	80/20の法則（全体の80%の問題は20%の機能から発生する）を応用して20の方に想定する機能から優先的にテストを行う。
原則５	テストの弱化（殺虫剤のパラドックスにご用心）
	JSTQBによる説明	同じテストを何回も繰り返すと、新たな欠陥の検出に対する効果は薄れてくる。この影響を克服するため、テストとテストデータを変更したり新規にテストを作成したりすることが必要になる場合がある。しかし、例えば、自動化されたリグレッションテストのように、同じテストを繰り返すことが有益な結果を示すことができる場合がある。
	私見	テストケースは定期的に見直し、更新する必要がある。 既存のテストケースを使い回している組織は要注意。
	ポイント	見直すべきポイントはテストタイプである。 但し、リグレッションテストの変更は逆効果になる可能性があるので注意。
原則６	テストはコンテキスト次第（テストは状況次第）
	JSTQBによる説明	テストに唯一普遍的に適用できるアプローチは存在しない。テストは、コンテキストによって異なる方法で行われる。
	私見	テストのアプローチや内容は、プロジェクトの状況や環境によって異なるため、開発スタイルや製品の性質に応じてテスト戦略や方法を柔軟に変更する必要がある。
	ポイント	テストの状況にはいくつかの捉え方がある。 ① 利用するシチュエーション ② システム特性（人命に関わるシステムと社内業務システムでは求められる品質が違う）
原則７	「欠陥ゼロ」の落とし穴
	JSTQBによる説明	ソフトウェアを検証するだけでシステムを正しく構築できると期待することは誤り（つまり、思い込み）である。例えば、指定された要件すべてを徹底的にテストし、検出した欠陥すべてを修正しても、ユーザーのニーズや期待を満たさないシステム、顧客のビジネスゴールの達成に役立たない、およびその他の競合システムに比べて劣るシステムが構築されることがある。検証に加えて、妥当性確認も実施すべきである。
	私見	Ｖ＆Ｖ（Verification＆Validation）はどちらかに偏ってもいけない。ただ、Validation視点が抜け落ちるのは問題外。
	ポイント	Ｖ＆Ｖのプロセスは順序よく進めること。（Verification→Validationの順）

▲図１７　１：１０：１００の法則

引用：「ソフトウェア品質保証の方法論、技法、その変遷」P.31を参考に作図
https://www.jaspic.org/event/2009/SPIJapan/keynote/SJ9keynote.pdf

ソフトウェアテストに関するその他（Q＆A形式）

この記事で書ききれなかったことをQ&A形式でまとめたので、よかったらここもチェックしておいてほしい。

質問	回答
重大な不具合から見つけることはできますか？	不可能。（不具合の重大さはその不具合を発見してはじめてわかる）
テストケースが不足していると感じるとき、どうすれば良いか？	テストの目的とテストレベルからテストタイプを見直すとよい。もしテストタイプが抜けていたら追加してテストケースにまで落とし込む。
テストの優先順位を決めるのが難しい場合、どうするか？	リスクベースアプローチを用いて、機能の重要度やユーザー影響度に基づいて優先順位を設定する。また顧客と協議するのもよい。
テストの進捗状況を報告する際、どの指標を使うべきか？	不具合検出率（成果進捗）とテストケースの消化率（工程進捗）は最低限用意した方がよい。
チーム内でのテストの認識にばらつきがある場合、どうすれば良いか？	根本解決するにはテスト基準を明文化するのが一番よい方法であるが、デイリーミーティングを継続的に実施することも有効。（テストプロセスや目的の共通理解を促進するのに役立つ）
テスト結果とテストケースの期待結果に違和感があった場合、どのようにするべきか？	まずテストケースの正確性を確認する。（テストケースの設計、環境設定、データの正確性、手順等に間違いがないかを確認） テストケースに間違いが認められなければ、次に設計書に間違いがないかを確認する。 設計書にも間違いがなければ、顧客と相談する。
スケジュールが圧迫されている中で品質を保つには？	機能の重要度やユーザー影響度が高い機能に絞ってテストをする。つまり、テストの優先順位を決めるのと同じ考え方になる。

編集後記

ソフトウェアテストのテストレベル、テストタイプ、テストプロセス、テストドキュメント、テスト技法などを理解することは、効果的なテストを実践するための知識であるとともに、スキルでもあることをお伝えしてきた。また、単体テストから受け入れテストまで、各テストレベルには特有の目的とアプローチがあること、アジャイル開発は高品質な開発手法であること、テスト（自動化テストも含め）には原則があることも、お伝えしてきたとおりである。私にできるのはここまでで、今後この情報をどう活かすかはあなた次第である。

さあ、いますぐ行動しよう！

お問い合わせ

QualityCybeの提供するテスト支援サービスでは、専門的な知見をもとに、貴社のテスト戦略や実務の最適化をサポートいたします。

下流工程支援には、テスト計画作成支援、テスト設計・仕様書作成支援、テスト実施支援、品質強化テスト支援など、さまざまなパターンをご用意しています。もちろんサービスの組み合わせも自由自在です！

また、ソフトウェアテストに関する知識を深めるためのeラーニングやセミナーサービスもご用意しております。このサービスにより、チーム全体のテストスキルを向上させ、品質向上を実現することが可能です。

テスト講座とは、ソフトウェア開発の品質保証において必要な知識とスキルを習得する研修です。IEEE8829をベースとしたテスト3表（テスト計画・テスト設計・テスト仕様書）についてポイントを解説していきます！

ぜひ、この機会にQualityCybeのサービスをご利用いただき、ソフトウェア品質を向上させましょう。あなたからのお問合せをお待ちしています。

ご相談は無料で承っております！

なお、ブログの最新リリース情報につきましては、当社メルマガでリアルタイムにご確認いただけますので、本記事がよかった、ためになった、という方はぜひ、メルマガ登録もお願いします。

最新IT情報やお役立ち情報をコンサルタントが配信中！