【感想・ネタバレ】知識ゼロから学ぶソフトウェアテスト 【改訂版】のレビュー

高橋寿一

テスト技術者必読のロングセラー！8年振りのリニューアル登場

エンジニアとしての心得やソフトウェアテストにできること、できないこと、など初心者がまず知っておかなければならないことがらにはじまり、必ず実施される各種テスト手法の基礎とポイント、アジャイルなど新しい開発手法に対応したテストの考え方など、テスト技術者にとって不可欠な知識と情報を、親しみやすい記述や例示で判りやすく解説した一冊です。テスト技術者の入門書かつ最適の定番書として、ソフトウェア開発現場のニーズに即した内容を取捨選択のうえ、カラー化して一層読みやすくパワーアップして再登場しました！

ソフトウェアテストに携わる初歩のエンジニア／テスト技術者を育成・養成する立場の方におすすめです。

※本電子書籍は同名出版物を底本とし作成しました。記載内容は印刷出版当時のものです。
※印刷出版再現のため電子書籍としては不要な情報を含んでいる場合があります。
※印刷出版とは異なる表記・表現の場合があります。予めご了承ください。
※プレビューにてお手持ちの電子端末での表示状態をご確認の上、商品をお買い求めください。

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

## テストで大事なこと

- テストで大事なのは、どの部分にバグが出やすいか、そこをどのようにテストすれば十分な品質が得られるかを知ること
- バグは平均的に散らばっているものではない。バグの出やすい箇所、出にくい箇所がある。(80%のバグが20%のコードに含まれているというデータもある)
- テストは限られた時間で行う最大公約数的な仕事。時間がないからテストしないという選択肢はない
- James曰く、「ソフトウェアは4つの仕事しかしない。なので、その4つの振る舞いをテストすれば良い」
- 4つとは、 `入力を処理する`、 `出力を処理する`、 `計算を行う`、 `データを保存する` それらに対して適切にテストすれば、ほとんどのバグが発見できる
- テストケースを省略するのはやむを得ないが、その省略されたテストケースでバグを出してはいけない
- テストするのに「良いデータ」と「悪いデータ」が存在する
- 良いデータ例
- ユーザーがよく使いそうなデータ
- プログラムが許す最小のデータ
- プログラムが許す最大のデータ
- ゼロ
- 悪いデータ例
- 非常に小さなデータ(-99999,0.0000001など)
- 非常に大きいデータ(999999,1099999など)
- 長いデータ(abdajohadamklmdklamombamoaなど)
- 無効なデータ
- とっとと楽して60%のバグを見つけ、そのほかのバグがなぜ発生したか、どうやって防止するかに時間を費やすかが、より建設的なテスト担当者の役割
- 品質を目に見えるものにするには
- なるべく誤差がなく人間の市場や恣意に左右されないものを選ぶ
- 開発するソフトウェアの品質を十分代表するものを選ぶ
- Googleのバグ予測システムでは、いつ何回修正されたかしか見ていない。修正された回数が多いほど、修正が最近ほどバグが潜んでいるということ。

# テスト手法

## ホワイトボックステスト

- プログラムの論理構造が正しいかを解析するテスト
- 人間の時間をたくさん使って内部構造を解析しテストする
- 論理構造の正しさのみをテストするため、 `ソフトウェアの仕様が間違っていることから起こるバグは発見できない。`

### 制御パステスト

- プログラムがどのような振る舞いをして、どのように制御されていくかをテストする手法
- カバレッジ率の値を取るために使われる
- 制御パステストによるコードカバレッジテストの本質は、フローチャートをちゃんとカバーすることにある

### ステートメントカバレッジ

- 制御パステストの一部
- ステートメントカバレッジだけでテストを終了することは危険
- 分岐条件がカバーしきれないなど、非常に弱いテスト手法

### ブランチカバレッジ

- `分岐コードに対してそれぞれの判定条件がTrue/Falseの結果を少なくとも1回ずつ持つようにテストケースを書く`
- 分岐を網羅するため、テストケースの数がかなり増える点が問題点
- バグの発生状況を見てから、バグがたくさん出る部分に対してブランチカバレッジを実行するのは悪くないアイデア

## ブラックボックステスト

- ブラックボックステストは、プログラムをブラックボックスと見立てて、 `様々な入力を行うことによって、ソースコード利用せずテストを行う手法`

### 同値分割法

- 同値分割とは、入力領域を「同値クラス」という部分集合に分割し、その部分集合に入る入力値を透過とみなす作業
- つまり、可能な入力値のうち同様の入力値は等価とみなしてテストする手法
- 同値クラスの分け方は
- 有効同値：プログラムが期待する入力値
- 無効同値：有効同値以外の入力値
- 実践的な同値クラスの選び方は、 `ポイントは代表する同値が全てのエレメントを網羅しているか`です

### 境界値分析法

- 同値分割法とセットで使われる手法
- プログラムで「境界」と呼ばれる場所は常にバグが潜んでいるので、強化位置近くは詳しくテストする必要がある

## ランダムテスト/アドホックテスト

- テストケースを考えず、行き当たりばったり、なんら考えなしに入力や操作を行う手法

### まとめ

テストは

1. まずは強化位置テストを行い、境界地にまつわるバグを全て潰す
2. ディシジョンテーブルテスト行う
3. 状態遷移テストを行う

## 探索的テスト

- ソフトウェアの理解とテスト設計とテスト実行を同時に行うテスト
- すべてのテストを実施するのは時間的に無理、できてもすべてのバグは見つからない。
それならいちいちテストケースを書く代わりに、製品を 学習 したうえでテスト 設計 して 実行 してバグ報告を 並行 してやっちゃえば手っ取り早い。 というスタイル
- 探索的テストの唯一のデメリットは、非機能要求(=品質特定)のテストにあまり向かない

## 非機能要求のテスト

- 非機能要求(=品質特定)とは、「ソフトウェアが持つべき特性」で、機能的な側面と非機能的な側面の両方の属性を示したもの。
- とくに大事なのは、機密性、信頼性、パフォーマンス

### パフォーマンステスト

- ソフトウェアを設計もしくは企画する段階で設定されたソフトウェアの性能が期待された通り出ているかをチェックするためのテスト
- レスポンスタイムや、入力データサイズなどの設計前にソフトウェアのパフォーマンスを定義する

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

ソフトウェアテストって実行してエラーが出なければOK?
くらい何も知らなかったのですが、
この本でテストにはどんな種類があるのかと、最近話題の非機能要求のテストはやり方が確立されていないという事を理解した。
これからテスト仕様書の作り方を勉強する予定。

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

ソフトウェアテストの定番書。やわらかい文章で読みやすかった。
以下キーワード
・ブラックボックステスト
　①入力部があれば境界値テスト
　②複数入力部があればディシジョンテーブルテスト
　③ダイアログボックス遷移があれば状態遷移テスト
・テストケースツールTestlink
・ソフトウェアで弱いところを見つけたら、その部分を十分にテストする