「マインドマップから始めるソフトウェアテストAdvent Calendar 2015」 の６日目です。
[blogcard url=”http://qiita.com/advent-calendar/2015/mmtest”]
いつになったら本の内容について書くんだという事を言われそうなので，各章についてポイントや補足をしていきたいと思います。今回は第Ｉ部Chapetr１「ソフトウェアテストって何？」を取り上げます。
※ご注意：本Advent Calendar はあくまで池田の個人企画です。
■ソフトウェアテストって何？
筆者は所属企業の社内研修やコミュニティの勉強会にて，初級レベルの内容を話す際にまず最初に「皆さんの考えるソフトウェアテストを説明して下さい」と問いかけます。そうすると，ほぼほぼ十人十色の答えが返ってくるか，「バグを見つけることです」という単一の答えが返ってきます。前者はその組織でソフトウェアテスト技術や作業の概念が統一されていないことを示しますし，後者は概念としてあまりに狭い単純作業として認識していることを示していると考えています。
ソフトウェアテストは大学でほとんど教えられません。おそらくＯＪＴでもテストについてはほとんど教えられないでしょう。ですから初級者がこのような答えを返してしまうことはしょうがないのだと思います。
ですが実際にはソフトウェアテストという業務はとても創造的だし高度な技術を要求されます。また，バグを見つけるだけという狭い目的のために行われるものでもありません。ですから，先ほどの答えが返ってくる状況というのはそれだけで問題を抱えているということになります。
Chapter１ではこの問題について，語りかける内容となっています。
■ソフトウェアテストとは何のためにやるの？
Chapter１では「ソフトウェアテスト」の定義を紹介するのではなく，なぜやるのか，どういった意義があるのかという，作業面での動機やモチベーションに重きをおいて解説しています。読み進めていくうえでくれぐれも気をつけて欲しいのは，本書はテスト技術を学問的に解説するのではなく「テストという仕事や作業を理解してもらう」ことを重視していますので，〇〇技法を学ぶという必殺技主義にならなず，泥臭い作業イメージを持ちながら読み進めていただくのが良いと思います。
さて，Chapter１では著者らのオリジナルの「意義」として次を定義しました。（定義を定義した訳ではないのでご注意下さい。）
ソフトウェアテストを行う意義
『ソフトウェアテストを行うと，ソフトウェアが作られていく過程で入り込んでしまう“バグ”を発見することができ，そのバグを開発者が修正することによって，ソフトウェアを利用者が安心して利用することができるようになる。また，出荷後にバグが出ないことで，ソフトウェアの回収と修正に必要なコストを削減し，企業のイメージ低下，ひいては倒産を防ぐことができる。』
（引用：マインドマップから始めるソフトウェアテスト p.20より）
定義を紹介することは簡単なのですが，それだけでは不十分と考えています。こういった意義を考えてもらうこととそれを共有し方向付けすることこそがテストに取り組む前に必要なことです。個別のテスト技術はそれによって選択していけばよいと思います。
■ソフトウェアテストの作業とは？
Chapter１ではＶモデルを例に取り，開発工程とテスト工程を解説しています。
ここで大切なのはコンポーネントテスト，統合テスト，システムテストといった大きいレベルでのテストプロセス（正確にはテストレベル）にさらに細かいプロセスがあるということです。先に挙げた3つの〇〇テストはテストレベルと呼びますが，そのテストレベルごとにサブプロセスとでもいうプロセスがあります。
『テスト工程に対応する開発工程の開発成果物である仕様書と，開発プロジェクト全体に関する関連文書を入力情報とします。その入力情報に基づいて「仕様分析」→「テスト計画」→「テスト設計」→「テスト実装」→「テスト実行」→「テスト報告」という順番で作業を行います。』
（引用：マインドマップから始めるソフトウェアテスト p.30より）
ここで基礎知識がある方は「おや？」と思うかもしれません。おそらく引っかかるのは仕様分析という言葉とテスト計画でしょう。少し補足してきます。
ISTQB等の体系では仕様分析ではなくテスト分析と表現されることが多いですが，本書では意図的に仕様分析という言葉を使っています。執筆当時はテスト分析という言葉自体があまり普及していなかったため，テスト全体やテスト結果に対しての分析をテスト分析とイメージされる懸念があったからです。明確に仕様書の類いに意識を向けてもらうために，敢えて仕様分析という言葉を使っています。注意を払ってもらえればと思います。
また，テスト計画については「テストにも計画がある」ということを強く認識してもらいたかったため取り上げています。実際，現場の作業ではざっと仕様を確認しその後の作業計画を立てるということがよくあると思います。ただし，単なるスケジュールを引くくらいのことしかされていない現場も多いので，そうじゃなく，テストはしっかり計画的にやるべき仕事であるということを明確に示しています。こういった意図があることを理解していただくと，本文を理解しやすくなるのではと思います。（今じゃ計画立てるのは当たり前と思う方も多いですが，当時はテストに計画があるなんてほとんど認識されていなかったのです。当然テスト計画書なんてのもほとんど作られていませんでした）
■おわりに
今回はChapter１についてポイント紹介と補足をしました。出版してから8年も経つと，記述内容と現在に齟齬が生まれますね。出版されてから長い本を読むとき，その内容は当時の常識や事情に合わせて書かれたものであると理解しながら読むとよいのではないかと思います。
<
