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

高橋寿一

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

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

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

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

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

IEEE 829のテストプランテンプレート
テストプラン文書番号
リファレンス
はじめに
テストアイテム
テストするべき機能必要のない機能
アプローチ
人員計画トレーニング計画
スケジュール
リスクとその対策
承認
に終了基準を追記

自動化はスモークテスト、パフォーマンステストAPIテストに向いてる

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

ソフトウェアのテストは、新人の仕事という考え方があるが、それは間違っている。
ソフトウェアのテストは、熟練で経験豊富な技術者の仕事。その中の、ルーチンワーク的に手順化された部分を新人にさせるのは、悪くないかも知れない。そのことを、しっかりとお互いに理解した上で。

ソフトウェアテストは、会社に入って何年もの間、実施してきた。
もう一度、勉強し直しだ。
勉強は、楽しい。

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

組み込み業界の会社に入社して2年目のときに読んだ本．誤植がいくらかあった気がしましたが，「知識ゼロから」と謳っている分，内容がわかりやすかった印象を受けた．ゼロではなくなったと思う．

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

ホンマかいなということが、いっぱい書いてる。
是非、実践してみたいが、この本を先に読んでもらわないと、承認を得ることはできないよ!

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

ソフトウェアテストの基本的な考え方や手法について、平易な言葉できちんと伝えている。テスト自体やテスト手法について
学びたいと思った人へ、初めて読む本としてオススメできる。

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

本書は古典から先端までを扱い、それらは決して易しい内容ではないはずなのですが、フランクな語り口で恐ろしく軽く読めるように仕上げられています。

初心者にとってはソフトウェアテストにどのような技術があるのかを知るための入門書ですが、中級者にとっては本来そこそこ難しく語られる技術の大事な所を短時間で確認できる本にもなります。参考文献が充実しており、文献ポインタとしても役に立ちます。読み返す価値のある本です。

本書には直接書いていないのですが、著者はTDDと探索的テストを合わせた手法をアジャイル開発時代に合ったテストとして提唱しており、本書の至る所にその思想が垣間見られます。

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

タイトルの通り、知識ゼロの方を対象として書かれた本だと感じた。そのため様々な手法を幅広く、浅く書かれているぶん、それぞれの内容を深く学びたいと思われた場合、参考著書などを活用して別の書籍を読む必要がある。

ソフトウエアテストを最初に学ぶ人にとって、初手に読む本としては良いと思う。

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

## テストで大事なこと

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

# テスト手法

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

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

### 制御パステスト

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

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

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

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

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

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

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

### 同値分割法

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

### 境界値分析法

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

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

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

### まとめ

テストは

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

## 探索的テスト

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

## 非機能要求のテスト

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

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

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

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

知識ゼロから学ぶソフトウェアテスト、のタイトル通りの本。 この手の本ではめずらしく、非常に砕けた表現でさくっと読めるのがよい。 でも基本はおさえているし、現場の経験に基づく指針が示されているので、ただのソフトウェアテスト入門本よりは参考になる。 とにかく、基本に忠実に。

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

タイトルにある通り、知識ゼロからでも読める。
若干、著者の口語混じりの体験談と解説が続くので、
そこがあうかどうか読み手による。
テストの考え方、カバレッジの考え方、機能要件・非機能要件のテスト、テストメトリックスの考え方などなど
テスト関連の解説が続いていくので、ソフトウェアテストに
関心がある方は読んでみたら良いともう。

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

ソフトウェアのテストにおける基本的なことを
改めて復習したいと思って手に取りました。

結構テストにはかかわってきたほうですが、
それでも知らないことが多かったりと、
ちゃんと勉強してないなあと反省。

【勉強になったこと】
・カバレッジテストで見つけられないバグ
　プログラムのループに関するバグ
　要求仕様に関係するバグ
　データ、タイミングに関するバグ

・ソフトウェアの仕事は大きく4つ
　入力、出力、計算、保存

・バグの47%はプログラムの4%に偏在している。
　なので定性・定量的に品質が悪い箇所を見つけたら、
　そこに集中してテストをするというアプローチが
　費用対効果の面でも品質の良いテストが出来る。

・テストは同じようなケースをたくさんやるのではなく、
　探索型でテストするのが実は最も精度が高い。
　その際に重要なポイントは、
　①テストを実行しながら、どこかほかの部分に
　　問題がないかを考え、そこをテストする。
　②ソフトウェアで弱いところを見つけたら、
　　そこを重点的にテストする。

・平均的なWebアプリケーションは計画時に想定した
　パフォーマンスの72%しか出ないという調査結果も
　ある。

・パフォーマンステストの5つのステップ
　①アーキテクチャバリデーション
　②パフォーマンスベンチマーク
　③パフォーマンス回帰テスト
　④パフォーマンスチューニング、アクセプタンステスト
　⑤24 X 7パフォーマンスモニター

・テストプランはIEEE829をベースに、
　カスタマイズするとよい。

・IBMの調査によると、平均的なソフトウェアのコード
　1,000行のうちに60個のバグが存在すると言われている。

・テストケース数に対する指標を提言しているものは
　ほとんどない。日立ソフトで、ソースコード10～
　15行あたりに1テストケースだったという例がある
　程度。

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

先輩から頂いた本を再読。
テストの全体像と勘所がわかりやすく書いてあり、素敵な本。

- 8割のバグは2割のコードが生み出している
- 完璧ではなく、十分な品質を保つ
- ホワイトボックステスト・ブラックボックステスト
- 同値分解・境界値テスト
- 探索テスト
- 非機能要件テスト (機密性、信頼性、パフォーマンス)
- テスト自動化の罠
- (ススメ)モジュールごとにテストする。集中的にテストする。

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

具体的なテスト技法を学ぶというより、テストはどのような観点からやるべきものなのか、どのような手法に分類されるのかといった、これからテストをやるための視座を与えるような1冊。平易な言葉と優しい語り口なので、入門書としてすごくよかった。

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

本当に「知識ゼロ」あるいはそれに相当する知識量の人にとっては最適な一冊。

まえがきにあるように、確かに文字が大きく、もう少し内容を詰めて書けるのでは？と思うこともあるが、著者がわざと大胆に削った結果だから、そこに文句を言ってもしょうがない。中身をさらっと読んで納得して買うべし。

「テスト技法の本」というより「テストってこういうことをやるんだよ」という、テストのエキスパートから語られる実践的な意見が切り口となっており参考になる。

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

IEEE829の存在を知れたことだけで、有意義でした。テストの考え方と実践まで、簡単に書いてあり、入り口としてとても役に立ちました。

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

ホワイトボックステスト、ブラックボックステスト、探索的テスト、非機能テストの基本がまとめられている。

この試験方法では、こんなバグは出ないという記載がよかった。経験則で持っているものを文章にされた感じ。加えて、こんなテストのやりかたを試してみたけど、向いてなかった向いていた、という実話ベースの部分もよい。もっとあってもよいくらい。最後に表などで、テストに関するサマリがあるとさらによい本になったと思う。最後に索引があるのは素晴らしい。

TDD(Test Driven Development)の話、単体テストをやりながらソースコードを書く話、サイクロマチック(Cyclomatic)複雑度の話はより詳しく勉強したい。

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

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

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

まさかテストに関する本が「楽しく」読めるとは思わなかった。各種テスト手法の基礎とポイント、アジャイルなど新しい開発手法に対応したテストの考え方など、平易な文章でわかりやすく解説されている。テストに詳しくない職場の人にもぜひオススメしたい一冊。

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

知識ほんとにゼロで読みましたが、
知らない単語で当たり前の様に
使われる言葉が多かった気がします。

○学習事項
・境界値分析と網羅
・テストに完全はないんだなぁ
・取捨選択が大事なんだなぁ

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

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

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

初心者向けの内容ということで、どんなテスト手法があるか全体像を把握することができた。

過去にテスト手法について勉強していたつもりだったが、誤解していたところや、なんとなくでテストを書いていたところもあったので、改めたい。