作成日 2017/3/30
最終更新日 2017/3/30
ソフトウェアのテストとは
ソフトウェアのテストって何だ？について説明します。
このページを書こうと思った理由：学生、本業はIT業界ではないが、仕事や趣味でプログラミングしている人はテストについての知識が、恐らくほとんど無いと思います。
でも、それだと、良いものは作れないし、自分が困ることになるかもしれません。という理由で、理解して欲しいと思ったからです。
すみませんが、IT業界で働いている人にとっては、このページは当たり前のことしか書いてないです。
まずは、テストの定義を調べました。
Wikipediaでの説明から。
ソフトウェアテスト（software test）は、コンピュータのプログラムから仕様にない振舞または欠陥（バグ）を見つけ出す作業のことである。ソフトウェアテストで見つかったプログラム中の欠陥を修正する作業をデバッグという。ソフトウェアテストに成功するとは、テストで欠陥が発見されるか、規定した試験項目にすべて合格するか、規定した品質目標に到達することである。目標とした品質には、規定した試験項目にすべて合格することもある。例えば、OS, プログラミング言語では、仕様を満たしているかどうかの適合試験を規定している。ソフトウェアテストでは、欠陥が存在することを示すことはできるが、欠陥が存在しないことは証明できない。ソフトウェアに仕様にない振舞がないことを保証する作業を証明といい、証明用のシステム、証明しやすい言語も多数存在している。本項では動的なソフトウェアテストを中心に扱う。
注：最初の概要文だけ抜き出しています。
次に、IT用語辞典での説明。
テストとは、試験(する)、検査(する)、検定(する)などの意味を持つ英単語。システムやソフトウェアの開発において、出来上がったもの動かしてみて、仕様どおりに動作するか、不具合や誤りが無いかなどを調べること。調べたい対象や内容により、「単体テスト」「結合テスト」「ブラックボックステスト」「ホワイトボックステスト」など様々な手法が考案されている。
注：すみません。こちらは全部抜き出してます。
書籍「基礎から学ぶソフトウェアテスト 〜テストの「プロ」を目指す人のために〜」（ISBN4-8222-8113-2）ではどうだろうか？
どうも2つの意味がある感じです。
(a)1つはコーディング（プログラミング）した後の不具合摘出作業です（Wikipediaでの説明と同じ）。
(b)もう1つは、とにかく「検査する」あるいは「検定する」という意味での使用です。例えば、計画段階でのレビュー、設計時のレビュー、マニュアルの確認についても「テスト」という言葉を使っています。
使い方や言葉の意味としては全部あっている（間違っているものは１つもない）のですが、混乱しそうです。
なので、図を描いてみました。
図１ テストの意味
IT業界での現場や情報処理技術者試験では、「テスト」はIT用語辞典での説明にある使われ方をしています。
Wikipediaでは「静的テスト」、「動的テスト」という言葉が出てきますが、IT業界の現場、情報処理技術者試験では単に「テスト」といった場合は、「動的テスト」のことを意味してます（Wikipediaの「動的テスト」がIT用語辞典での「テスト」の意味と同じ）。だるまは、「静的テスト」のことを単に「テスト」だけで言っている人を聞いた記憶があまり無いです。「静的テスト」は「静的テスト」とか「静的チェック」と言ってます。
ということで、ここでは「テスト」とは、IT用語辞典に記載されている意味で使用することとします（図１で青くしたところ）。
テスト（動的テスト）で行うことは、プログラムを動かして、動作確認して、問題があれば修正することなのですが、それだけではないです。
これも、学生、本業はIT業界ではないが、仕事や趣味でプログラミングしている人は分からないと思うので説明します。
テストを行う上で最低限、考慮が必要なことをざっとあげてみます。
■テストを行う上で考慮が必要なこと
- プログラムの規模が大きくなるとテストを行う人がどうしても複数人になる。万が一、作業者によってテストの方法や実行環境などが、理由無くばらばらだとまずいから、あわせたい。
- 理由無く2回以上同じテストを行うのは、面倒だし、管理者（会社）としても余計な経費が増えるだけなので、やりたくない（やらせたくない）。
- とはいえ、テスト漏れはまずい。
- どういうテストを行うのか（あるいは行ったのか？）を、他の人（管理者やお客さん）がチェックできるようにする必要がある。え？なぜって、本当にテストしたのって？言われたときの証拠（エビデンス）が何もないとまずいじゃん。
- プログラムの規模が大きくなるとテストを行う人と、発見された不具合を修正する人は別の人になる。どうやって伝えるか？
このため、以下の作成が必要になります。
- => テスト計画書：テストの目的、範囲、開始基準、終了基準、スケジュールなどを書いたもの。
テスト仕様書 - Qiitaが参考になると思います。
- => テスト計画書 ＆ テスト仕様書
テスト仕様書というのは、例えば、
入力（関数の引数や操作手順など）：XXX
に対して、
予想結果（関数のout引数、戻り値、画面の表示内容など）：YYY
を書いたもの。
テストの実施はテスト仕様書を元に行います。テスト仕様書を作るのは時間がかかりますが、これがないと、同じことを2回実施ということになりかねないです。
- => テスト計画書 ＆ テスト仕様書
- => テスト計画書 ＆ テスト仕様書、テスト成績書
テスト成績書というのは、テスト仕様書を元に実施したテストの結果（OK、NG）を書いたものです。
- => 不具合票（バグ票）
バグを見つけたときの入力や実施環境などバグの再現に必要な情報と、どういうように問題が起こったのかをなどを書いたもの。
※注意：「テスト計画書」、「テスト仕様書」、「テスト成績書」、「不具合票（バグ票）」という言葉は、だるまが業務で使った（あるいは聞いたことがある）言葉であるため、ここで使っていますが、IEEE 829やISO/IEC/IEEE 29119といった規格での用語に沿っているものではありません。
ともかく、こういったものも必要なんだ、ということだけ理解して頂けたら良いと思ってます。
考慮が必要なことは、考えれば、もう少し出てきそうです。
でも、テストを意識したことが無かった人にとってはここまでの内容でも十分だと思うので、ここまでとしたいです。
このページを作成するのに参考にしたページです。
|
番号 |
著者名 |
書籍名 |
ISBN |
説明 |
| 1 |
Cem Kaner (著), Hung Quoc Nguyen (著), Jack Falk (著), テスト技術者交流会 (翻訳) |
基本から学ぶソフトウェアテスト テストの「プロ」を目指す人のために |
978-4822281137 |
p32に「計画段階のテスト」が、p38に「設計段階でのテスト」が、p183に「ユーザマニュアルのテスト」が出てきます。 |
このページの利用によって発生した、いかなる損害について、このホームページの作成者は責任を負いません。
このページの間違いや嘘を見つけた方、このページに書いて欲しい情報がある方は
メールをお願いします。
Microsoft 、Windows 、Visual Basic および Excel は米国Microsoft
Corporationの米国およびその他の国における登録商標または商標です。
ここではExcel® をエクセル、Visual Basic® for Applications をVBAと表記する場合があります。
Mac 、Mac OS 、Mac OS X は米国Apple
Computer,Inc.の登録商標または商標です。
その他、社名および商品名、システム名称などは、一般に各社の商標または登録商標です。
このホームページの作成者はこれらの会社とはいっさい関係がありません。
