はじめて学ぶソフトウェアのテスト技法

リー・コープランド / 宗雅彦

最少のテストケースで最大の効果をあげるためのツールを満載した、小さいけれどすごい本。同値クラステスト、境界値テスト、デシジョンテーブルテスト、直交表と全ペア技法、状態遷移テスト、ドメイン分析テスト、ユースケーステスト、制御フローテスト、データフローテストなど、テスト技法の必須項目を全て1冊に集約しています。平易で実践的な例題を使い、手順を1つ1つ追って説明しているので、新人プログラマや初級のテスト担当者のレベルアップに最適。もちろん、「いまさら人に聞けない」ベテラン技術者にもぜひお勧めです。

• カテゴリ: ビジネス・実用
• ジャンル: IT・コンピュータ / 言語・プログラミング
• 出版社: 日経BP
• タイトル: はじめて学ぶソフトウェアのテスト技法
• タイトルID: 240427
• ページ数: 256ページ
• 電子版発売日: 2013年12月27日
• コンテンツ形式: EPUB
• サイズ(目安): 12MB

[ブクログ · ★★★★★]

タイトルどおりテスト技法のカタログ的な内容だが、それぞれの特徴やアプローチを具体的に解説してくれていて、なかなか面白く読めた。これから専門に入門しようとしてる人や、プログラマやPMで詳しい知識を得たい人に。
ところで各章の初めにある引用がブラックで謎すぎる。

[ブクログ · ★★★★★]

長いことソフトウエア開発の仕事に携わってきたが、ふと「テスト」というものについてちゃんと勉強したことがないことに気付き、業務上の必要もあって、敢えて初心者向けの本書を選んだのだが、結果大変勉強になった。
ソフトウエア開発従事者なら、一度は読んでおくべき良書だと思う。

[ブクログ · ★★★★★]

単体テストの項目抽出に興味がある人には有益。
演習があるのにその答えが見当たらないのが謎。

SectionIIまで読み終わったところで中断（ユースケーステストはスキップ）。SectionIII以降はまた後日。
ペア構成テストとドメイン分析テストは疑問が残るので、再度読み返す必要がある。

「ソフトウェアテスト実践ワークブック」が気になるので要チェック。

[ブクログ · ★★★★★]

ソフトウェアテストってどうやるんだろう？
どんなものがあるんだろう？
っていうのを解決してくれる本。

技法の説明がとても丁寧でわかりやすい。
でもどこで使うかとかは書いていない。
それは実践で学んでいくらしい。

[ブクログ · ★★★★★]

本当に始めて学ぶのに最適ですね。いろんな情報が載っていて、これからテストについてDeepに学ぼうとしている私には最適な入門書です。

[ブクログ · ★★★★☆]

今までなんとなくやってきた現場でのテストについて、体系的に整理することができた。

同値分割や境界値などは、本書でも記載されている通り既に意識されていることが多いが、デシジョンテーブルやペア構成、ドメイン分析等は、テストの目的を意識して活用することは難しいかもしれないと思った。

ただそれができるようになると、このソフトウェア仕様であればこのテスト手法がやりやすい、と迅速でより安全なテストを推進することができると信じて、本書の内容を活用していきたいです。

[ブクログ · ★★★★☆]

テスト対象の業務ロジックに応じて適切な図表を使い、テストケースを作成する

【感想】
　業務の外部結合テストがスケジュール上かなりしんどくて、少しでも知識武装して気持ちを楽にしたいとの思いで手に取った本（テスト自体は1か月前ぐらいに終わってしまっているが）。読んで正解、今まで何となくやってきたテストの方法、経験がきちんとしたコンセプトで整理された。テストケースを作成するための図表がそれぞれの技法ごとに載っていて、実務への転用イメージも沸きやすい。自分の業務上で学んだテスト技法を利用したいときは、その図表を使ってテストケースの作成を進めればよい。　SEとしてプロジェクト推進をする最初に、こういったテスト法の本はさらって読んでおくべきだな。

【本書を読みながら気になったコト】
デシジョンテーブルはテスト設計の基本中の基本と言われるが、これは本来要件定義、基本設計のツールであったはず
→テスト技法に詳しくなり、パターンの洗い出しの技術が上がれば、設計の記述も上がる


《ブラックテスト技法》
〇同値クラステスト
独立した変数に対するテスト
図表：引数と期待する結果の組み合わせ

〇境界値テスト
独立した変数に対するテスト
同値クラステストケースに、境界値も加える
図表：引数と期待する結果の組み合わせ

〇デンジョンテーブルテスト
複数の条件に基づく行動、結果をテスト
図表：複数条件と行動、期待する結果の組み合わせ
　　　→デンジョンテーブルと呼ぶ

〇ペア構成
環境やインプット値をペア毎ケースを作成しテスト
図表：存在するパターンを縦、横に並べた表　
　　　→直交表と呼ぶ

〇状態遷移テスト
あるオブジェクトの状態が複数存在、変化しうる際のテスト
図表：状態遷移図をまず作って、状態遷移図表を作る
　　　状態遷移図表には、
　　　・現在の状態
　　　・イベント
　　　・アクション
　　　・次の状態
　　　を含める。
全ての遷移パスを実行するテストケース作成、実施が望ましい

〇ドメイン分析テスト
同値クラステスト、境界値テストと違い、複数の変数を同時にテストする
・y = ax のような二次元表を利用する
・on off in out の概念を使ってテストケースを作る
図表：ドメインテストマトリックス
　　　・複数変数を縦に並べ、変数ごとに　on off in out で分割
　　　・変数のon off in outごとに代表値を設定し、あり得る組み合わせごとに横の列を増やす
　　　・列ごとに期待される結果を記載

〇ユースケーステスト
業務に沿ったシナリオを作成しテストする
図表：ユースケースシート
　　　・操作内容、操作ステップ、期待する結果などを含める

《ホワイトボックステスト技法》
〇制御フローテスト
意図した通りに分岐して進むか、コードをテストする
図表：フローダイアグラム
　　　→フローダイアグラムをテストケースの洗い出しとして利用
　　　　実際にコードが引数ごとに、フローダイアグラム通りに動くかは各プログラミング言語のツールでテストする
→存在するパスを全て通るようにテストができるのが理想

〇データーフローテスト
変数が定義、生成、使用、消滅される順序を記述し、ケース作成、テストする
図表：フローダイアグラム
　　　→フローダイアグラムをテストケースの洗い出しとして利用
　　　　実際にコードが引数ごとに、フローダイアグラム通りに動くかは各プログラミング言語のツールでテストする

《テストパラダイム》
〇スクリプトテスト
事前に計画、テストケースを綿密に作成し、テストを行う

〇探索的テスト
テストを進め、その結果に応じて必要なテストを考案、ケース作成してテストする

→両方併用してテストを進められるのが理想

[ブクログ · ★★★★☆]

ソフトウェアのテストをする上で何を検証し、どんなロジックでテストを組むのか、というテスト手法に関して学ぶことができます。情報学の用語や概念も一部あるので、入門書より難易度は少し高めに感じました。

[ブクログ · ★★★★☆]

一つのトピックの分量は少なくコンパクトにまとめてあり、開発者の私がテスト、とりわけ Verification について勉強するのには、先日読んだ高橋さんの本とあわせて、ちょうど良かった。

特にデシジョンテーブル、直交表、全ペア生成などに関しては、その立脚点がうまく解説されていたように思う。

また、各種の手法の pros/cons をしっかりと取り上げているところは好感のポイント。

探索型のテスト、という概念は私にとって新鮮だった。

[ブクログ · ★★★★☆]

　どうすれば少ないテストケースで有効なテストが実施できるかについて具体的な例とともに解説している。同値クラステストや境界値テストといったおなじみの技法から、デシジョンテーブルテスト、ペア構成テスト、状態遷移テストなどあまり知られていないものも紹介している。またブラックボックステストとホワイトボックステストの違いであるとか、テストの進め方についても言及している。
　テストの進め方についてはスクリプトテストと呼ばれるテスト計画を立て、テストケースを設定しテストを行う従来型のテストの他に、テストケースを事前に決定できなかったり、前に実行した結果が大きく影響する、あるいは要件が曖昧であったりする場合に使用する探索的テストを紹介している。このどちらかが優れているというわけではなく必要に応じて使い分けたり融合させるべきだとしており、実用を重視した内容となっている。
　実用重視と言えばテストの支援として欠陥の分類と終了判定を取り上げている。欠陥を分類することはテストの方向性やどこに重点を置くかを決めるのに有効というだけでなく開発プロセスにおいても有効であり手元においておくべき内容であると感じた。
一方テストの終了判定は皮肉交じりの内容となっていた。これは決してふざけているのではなく、テストの終了判定がいかに難しいかを如実に表しており、テスト経験者なら共感するであろうことが書かれている。
　新人にテストを任せるというある種の企業文化が存在しているが、本書を読むと果たしてそれは正しいのかと疑問に思う。仕事を理解する上でテストという作業が有効であることは間違いないが、やはりテストの重要性を鑑みればリスクが高いと言わざるを得ない。また、ソフトウェアテストの重要性が高まっているものの、テストを専門にするエンジニアが少ないように感じる。そろそろテスト専門エンジニアの育成を考えてみるべき時なのかもしれない。