あらすじ
最少のテストケースで最大の効果をあげるためのツールを満載した、小さいけれどすごい本。同値クラステスト、境界値テスト、デシジョンテーブルテスト、直交表と全ペア技法、状態遷移テスト、ドメイン分析テスト、ユースケーステスト、制御フローテスト、データフローテストなど、テスト技法の必須項目を全て1冊に集約しています。平易で実践的な例題を使い、手順を1つ1つ追って説明しているので、新人プログラマや初級のテスト担当者のレベルアップに最適。もちろん、「いまさら人に聞けない」ベテラン技術者にもぜひお勧めです。
...続きを読む感情タグBEST3
Posted by ブクログ
タイトルどおりテスト技法のカタログ的な内容だが、それぞれの特徴やアプローチを具体的に解説してくれていて、なかなか面白く読めた。これから専門に入門しようとしてる人や、プログラマやPMで詳しい知識を得たい人に。
ところで各章の初めにある引用がブラックで謎すぎる。
Posted by ブクログ
最少のテストケースで最大の効果をあげるためのツールを満載
第1章 テストのプロセス
第2章 ケーススタディの説明
Section 1 ブラックボックステスト技法
Section 2 ホワイトボックステスト技法
Section 3 テストのパラダイム
Section 4 支援技法
Section 5 最後の考察事項
■第1章 テストのプロセス
ソフトウェアテストの定義
「テストとは、テストされるソフトウェアの品質を測定して改善するために、テストウェアをエンジニアリングし、利用し、保守しながら、同時並行的に進めるライフサイクルプロセスである。」（P.12）
•テストとは 「実際どうなっているか」と「本来はどうあるべきか」の比較
•この本の役割 ◦テスト設計を有効かつ効率よく行うための技法
•テストケースの構成
・入力
・出力 ■期待値（オラクル）
・実行の順番 ■ランダム or シーケンシャル
•すべてをテストすることは不可能
■Section 1 ブラックボックステスト技法
ブラックボックステストは、要件と仕様書だけをよりどころにしたテスト戦略です。ホワイトボックステストとの違いは、ブラックボックステストではテスト対象ソフトウェアの内部パス、構造や実装に関する知識を必要としないことです。
(pp.26)
★組み合わせの数が非常に大きいときは、すべての変数のすべての値のすべての組み合わせをテストするのではなく、全てのペアのテストをします。テストケースが大幅に減ります。
このペア構成テストの効果を理論的に保障してくれる「ソフトウェア欠陥物理学」は存在しません。
ただ多くのプロジェクトでそれが成功しているという事実です。（P.88）
→ 直行表★★★
状態遷移図はテストすべき状態、イベント、アクション、遷移を明確にしてくれるので、テスト作業の指針として役に立ちます。
抜け漏れのない体系的な分析を行いたいときは、状態遷移表のほうが使いやすい手法です。
（P.104）
＜ブラックボックステストの技法＞
・同値クラステスト
・境界値テスト
・デシジョンテーブルテスト
・ペア構成テスト
・状態遷移テスト
・ドメイン分析テスト
・ユースケーステスト
■Section 2 ホワイトボックステスト技法
ホワイトボックステストは、テスト対象ソフトウェアの内部パス、構造、実装に関する知識をよりどころにしたテスト戦略です。ブラックボックステストとの違いは、ホワイトボックステストを実施するには通常、詳細なプログラミングのスキルが必要になることです。
(pp.126)
＜ホワイトボックステストの技法＞
・制御フローテスト
・データフローテスト
■Section 3 テストのパラダイム
・スクリプトテスト（事前計画テスト）
・探索的テスト（例：20の扉。頭の中に思い描いているものを20個の質問（Yes-Noで答えられる質問）を通じて当てるゲーム。仮に全ての質問を事前に計画しておいたとしたら、当てることはできないだろう。質問の結果を次の質問のインプットとする方法。）
計画が現在進行形のプロセスである以上、計画は現時点でわかっている情報と知識に基づいた暫定的な産物であり、新しい情報や理解が得られた際は常に見直しの対象となる、と認識すべきです。
P192
■Section 4 支援技法
テストをいつ終了するかを判定するための基本的な条件を5つ挙げると、以下のようになるでしょう。
・事前に決めたカバレッジの目標値を達成した
・欠陥検出率が事前に決めたしきい値以下に下がった
・「次」の欠陥を見つけるのに要する限界コストが、
その欠陥で生じると予想される損害額よりも大きくなった
・プロジェクトチームが、製品をリリースしてもよいという合意に達した
・上司による「いいから出荷しろ」の一言
■Section 5 最後の考察事項
・腕の良い職人には、道具が入ったバケツが必要
・そして、どの状況でどの道具を使うべきかがわかっていること
・能力レベルの３つのカテゴリ
１．知識
２．理解
３．応用 → よって実践が大事
■引用著作
・基本から学ぶソフトウェアテスト
・ソフトウェアテスト293の鉄則
・体系的ソフトウェアテスト入門
・ソフトウェアテスト１２の必勝プロセス
・基礎から学ぶテストプロセス管理
・ソフトウェアテスト技法
■目次
第1章 テストのプロセス
第2章 ケーススタディの説明
Section 1 ブラックボックステスト技法
第3章 同値クラステスト
第4章 境界値テスト
第5章 デシジョンテーブルテスト
第6章 ペア構成テスト
第7章 状態遷移テスト
第8章 ドメイン分析テスト
第9章 ユースケーステスト
Section 2 ホワイトボックステスト技法
第10章 制御フローテスト
第11章 データフローテスト
Section 3 テストのパラダイム
第12章 スクリプトテスト
第13章 探索的テスト
第14章 テストの計画
Section 4 支援技法
第15章 欠陥の分類
第16章 テストの終了判定
Section 5 最後の考察事項
付録A ブラウン＆ドナルドソンのケーススタディ
付録B ステートレス大学の登録システムのケーススタディ
システムの規模がどのようなものであっても、すべての異なる論理パスの組み合わせと、すべての異なる入力データの組み合わせに対してテストを行うことは不可能です。
リソースの制約があるので、それぞれテストするなんらかの意味を持つ無限の選択肢の中から、テスト担当者がほんの小さな部分（サブセット）を選んでテストする以外に、方法はありません。
この書籍の目的は、このようなサブセットを分析、設計、選択して、欠陥をより多く検出できるテストケースを作成できるように読者を支援することです。
(pp.1)
Posted by ブクログ
長いことソフトウエア開発の仕事に携わってきたが、ふと「テスト」というものについてちゃんと勉強したことがないことに気付き、業務上の必要もあって、敢えて初心者向けの本書を選んだのだが、結果大変勉強になった。
ソフトウエア開発従事者なら、一度は読んでおくべき良書だと思う。
Posted by ブクログ
単体テストの項目抽出に興味がある人には有益。
演習があるのにその答えが見当たらないのが謎。
SectionIIまで読み終わったところで中断（ユースケーステストはスキップ）。SectionIII以降はまた後日。
ペア構成テストとドメイン分析テストは疑問が残るので、再度読み返す必要がある。
「ソフトウェアテスト実践ワークブック」が気になるので要チェック。
Posted by ブクログ
ソフトウェアテストってどうやるんだろう？
どんなものがあるんだろう？
っていうのを解決してくれる本。
技法の説明がとても丁寧でわかりやすい。
でもどこで使うかとかは書いていない。
それは実践で学んでいくらしい。
Posted by ブクログ
今までなんとなくやってきた現場でのテストについて、体系的に整理することができた。
同値分割や境界値などは、本書でも記載されている通り既に意識されていることが多いが、デシジョンテーブルやペア構成、ドメイン分析等は、テストの目的を意識して活用することは難しいかもしれないと思った。
ただそれができるようになると、このソフトウェア仕様であればこのテスト手法がやりやすい、と迅速でより安全なテストを推進することができると信じて、本書の内容を活用していきたいです。
Posted by ブクログ
テスト対象の業務ロジックに応じて適切な図表を使い、テストケースを作成する
【感想】
業務の外部結合テストがスケジュール上かなりしんどくて、少しでも知識武装して気持ちを楽にしたいとの思いで手に取った本（テスト自体は1か月前ぐらいに終わってしまっているが）。読んで正解、今まで何となくやってきたテストの方法、経験がきちんとしたコンセプトで整理された。テストケースを作成するための図表がそれぞれの技法ごとに載っていて、実務への転用イメージも沸きやすい。自分の業務上で学んだテスト技法を利用したいときは、その図表を使ってテストケースの作成を進めればよい。 SEとしてプロジェクト推進をする最初に、こういったテスト法の本はさらって読んでおくべきだな。
【本書を読みながら気になったコト】
デシジョンテーブルはテスト設計の基本中の基本と言われるが、これは本来要件定義、基本設計のツールであったはず
→テスト技法に詳しくなり、パターンの洗い出しの技術が上がれば、設計の記述も上がる
《ブラックテスト技法》
〇同値クラステスト
独立した変数に対するテスト
図表：引数と期待する結果の組み合わせ
〇境界値テスト
独立した変数に対するテスト
同値クラステストケースに、境界値も加える
図表：引数と期待する結果の組み合わせ
〇デンジョンテーブルテスト
複数の条件に基づく行動、結果をテスト
図表：複数条件と行動、期待する結果の組み合わせ
→デンジョンテーブルと呼ぶ
〇ペア構成
環境やインプット値をペア毎ケースを作成しテスト
図表：存在するパターンを縦、横に並べた表
→直交表と呼ぶ
〇状態遷移テスト
あるオブジェクトの状態が複数存在、変化しうる際のテスト
図表：状態遷移図をまず作って、状態遷移図表を作る
状態遷移図表には、
・現在の状態
・イベント
・アクション
・次の状態
を含める。
全ての遷移パスを実行するテストケース作成、実施が望ましい
〇ドメイン分析テスト
同値クラステスト、境界値テストと違い、複数の変数を同時にテストする
・y = ax のような二次元表を利用する
・on off in out の概念を使ってテストケースを作る
図表：ドメインテストマトリックス
・複数変数を縦に並べ、変数ごとに on off in out で分割
・変数のon off in outごとに代表値を設定し、あり得る組み合わせごとに横の列を増やす
・列ごとに期待される結果を記載
〇ユースケーステスト
業務に沿ったシナリオを作成しテストする
図表：ユースケースシート
・操作内容、操作ステップ、期待する結果などを含める
《ホワイトボックステスト技法》
〇制御フローテスト
意図した通りに分岐して進むか、コードをテストする
図表：フローダイアグラム
→フローダイアグラムをテストケースの洗い出しとして利用
実際にコードが引数ごとに、フローダイアグラム通りに動くかは各プログラミング言語のツールでテストする
→存在するパスを全て通るようにテストができるのが理想
〇データーフローテスト
変数が定義、生成、使用、消滅される順序を記述し、ケース作成、テストする
図表：フローダイアグラム
→フローダイアグラムをテストケースの洗い出しとして利用
実際にコードが引数ごとに、フローダイアグラム通りに動くかは各プログラミング言語のツールでテストする
《テストパラダイム》
〇スクリプトテスト
事前に計画、テストケースを綿密に作成し、テストを行う
〇探索的テスト
テストを進め、その結果に応じて必要なテストを考案、ケース作成してテストする
→両方併用してテストを進められるのが理想
Posted by ブクログ
ソフトウェアのテストをする上で何を検証し、どんなロジックでテストを組むのか、というテスト手法に関して学ぶことができます。情報学の用語や概念も一部あるので、入門書より難易度は少し高めに感じました。
Posted by ブクログ
一つのトピックの分量は少なくコンパクトにまとめてあり、開発者の私がテスト、とりわけ Verification について勉強するのには、先日読んだ高橋さんの本とあわせて、ちょうど良かった。
特にデシジョンテーブル、直交表、全ペア生成などに関しては、その立脚点がうまく解説されていたように思う。
また、各種の手法の pros/cons をしっかりと取り上げているところは好感のポイント。
探索型のテスト、という概念は私にとって新鮮だった。
Posted by ブクログ
どうすれば少ないテストケースで有効なテストが実施できるかについて具体的な例とともに解説している。同値クラステストや境界値テストといったおなじみの技法から、デシジョンテーブルテスト、ペア構成テスト、状態遷移テストなどあまり知られていないものも紹介している。またブラックボックステストとホワイトボックステストの違いであるとか、テストの進め方についても言及している。
テストの進め方についてはスクリプトテストと呼ばれるテスト計画を立て、テストケースを設定しテストを行う従来型のテストの他に、テストケースを事前に決定できなかったり、前に実行した結果が大きく影響する、あるいは要件が曖昧であったりする場合に使用する探索的テストを紹介している。このどちらかが優れているというわけではなく必要に応じて使い分けたり融合させるべきだとしており、実用を重視した内容となっている。
実用重視と言えばテストの支援として欠陥の分類と終了判定を取り上げている。欠陥を分類することはテストの方向性やどこに重点を置くかを決めるのに有効というだけでなく開発プロセスにおいても有効であり手元においておくべき内容であると感じた。
一方テストの終了判定は皮肉交じりの内容となっていた。これは決してふざけているのではなく、テストの終了判定がいかに難しいかを如実に表しており、テスト経験者なら共感するであろうことが書かれている。
新人にテストを任せるというある種の企業文化が存在しているが、本書を読むと果たしてそれは正しいのかと疑問に思う。仕事を理解する上でテストという作業が有効であることは間違いないが、やはりテストの重要性を鑑みればリスクが高いと言わざるを得ない。また、ソフトウェアテストの重要性が高まっているものの、テストを専門にするエンジニアが少ないように感じる。そろそろテスト専門エンジニアの育成を考えてみるべき時なのかもしれない。
Posted by ブクログ
ソフトウェアテストの手法や考え方など基礎となるところが網羅されていると思う。
パーっと読み進めていき、まだまだ理解が足りないところもあるが、なんとなくテストの手法や不具合の定義など曖昧な部分が明確になった。
ソフトウェア開発者として、テストの手法などは確実に認知しておく必要があると思うので、この本はおすすめです。
TDDなどユニットテストなどを書くにも制御フローテストや境界値テスト、同値テストなどの考え方は知っておくべき内容だと思う。
Posted by ブクログ
今回は必要な部分だけを斜め読み。
和訳なので文章が所々読みにくかったり、作者の思いが分かりづらい例文が多いが、体系的にまとめられていて非常にためになった。
Posted by ブクログ
現時点では飛ばし読みで最後まで目を通したのみ。
目新しい発見はなかったが、それぞれのテスト手法の分類、位置付け、体系のようなものをざっくり把握できてよかった。
今すぐに精読はしないが、テストについての知識が必要な場面で取り出せると良さそう。
テストの成熟度の話や欠陥の分類は興味深かった。
Posted by ブクログ
＜きっかけ＞
テストについて教わったことがないなと思ったため
一度体系的に学習しておきたいと思ったため
＜感想＞
ソフトウェアテスト技法について体系的にまとめられていた。途中途中に挟まれるユーモアあふれる文章は、やっぱりも元洋書だなって感じ。知らない手法もいくつかあり、ペア構成テストやドメイン分析テストなどがその例だが、理解しきれておらず実用にもっていくのはなかなか難しい。何回か読み込む必要があると思う。最後に、刺さった言葉を一つ。「子供のテストでは、～結果は自分の意図したものだと～事実の起きた後に言う。本物のテストは～実行される前に結果は予測され、文書化されている。」つい手から動かしてしまうので胸に刻んでおきたい。
Posted by ブクログ
Section1と2は、のテスト技法について詳しい説明があり、参考になった。
演習問題もあるが正解が無いため、使えない。
Section4の15章の欠陥（障害）の分類も、自分が分類するときの、参考になった。
ただ、すべての分類を掲載してほしかった。
上記以外は記述量が少なく、参考にならない。
Posted by ブクログ
境界値テスト等、慣れた人はごく自然にやるテストについて書かれている。タイトルに偽りなし。
しかし古いというか固いというか、ちょっと時代遅れな気がする。
Posted by ブクログ
テストとはなんぞやと聞かれて、
種類ややり方を整理してくれている本。
もう一度体系立ててまとめるときにどうぞ。
（以下抜粋。○：完全抜粋、●：簡略抜粋）
●テストとは、テストされるソフトウェアの品質を測定して改善するために、
ソフトウェアテストをエンジニアリングし、利用し、保守しながら、
同時並行的に進めるライフサイクルプロセスである。（P.12）
●組み合わせの数が非常に大きいときは、
全てのペアのテストをします。
このペア構成テストの効果を理論的に保障してくれる
「ソフトウェア欠陥物理学」は存在しません。
ただ多くのプロジェクトでそれが成功しているという事実です。（P.88）
○状態遷移図はテストすべき状態、イベント、アクション、遷移を明確にしてくれるので、
テスト作業の指針として役に立ちます。（P.104）
○テストをいつ終了するかを判定するための基本的な条件を5つ挙げると、
以下のようになるでしょう。
・事前に決めたカバレッジの目標値を達成した
・欠陥検出率が、事前に決めたしきい値以下に下がった
・「次」の欠陥を見つけるのに要する限界コストが、
その欠陥で生じると予想される損害額よりも大きくなった
・プロジェクトチームが、製品をリリースしてもよいという合意に達した
・上司による「いいから出荷しろ」の一言
Posted by ブクログ
■ブラックボックステストの技法
・同値クラステスト
・境界値テスト
・デシジョンテーブルテスト
・ペア構成テスト
・状態遷移テスト
・ドメイン分析テスト
・ユースケーステスト
■ホワイトボックステストの技法
・制御フローテスト
・データフローテスト
■テストのパラダイム
・スクリプトテスト（事前計画テスト）
・探索的テスト（例：20の扉。頭の中に思い描いているものを20個の質問（Yes-Noで答えられる質問）を通じて当てるゲーム。仮に全ての質問を事前に計画しておいたとしたら、当てることはできないだろう。質問の結果を次の質問のインプットとする方法。）
