知識ゼロから学ぶソフトウェアテスト
情報
下記2つの記事を読んで、テスト入門書としてよさそうと思い選んだ。
第1章 はじめに
ソフトウェアテストで重要なのは、どの部分にバグが出やすいのか、そこにどのようなテスト手法を適用すれば十分な品質が得られるかを知ることである
三角形問題
ソフトウェアテストという作業はプログラミングに負けず劣らず困難であり、創造的な仕事です [NAS99]
第2章 ソフトウェアテストの基本 -ホワイトボックステスト-
すべてのソフトウェアテストの基礎となるが、実務において必ずしも有用とは限らない
プログラムの論理構造が正しいかを解析するテスト
ブラックボックステストより優れているというのは大きな間違い
論理構造の正しさのみをテストするため、ソフトウェアの仕様が間違っていることから起こるバグは発見できない
tommy.iconん？条件の説明はあるのにどういうバグだったかの説明は無し？
ステートメントカバレッジ
ブランチカバレッジ
カバレッジは一般商用ソフトウェアであれば60〜90%程度で十分
第3章 エンジニアがもっともよく使う手法 -ブラックボックステスト-
「テストは楽。プログラマはキャッチアップ大変 」(韓国のテスト業界No.1 Wonil)
ソフトウェアは4つの仕事しかない (James Whittaker)。これらの振る舞いさえテストすればよい。
入力
出力
計算
保存
ゼロは常に特別な値なので、入力できる場合は必ずテストケースに入れる
行うテスト
もし入力ダイアログボックスがあれば境界値テスト
もし複数の入力ダイアログボックスがあればディシジョンテーブルテスト
もしダイアログボックスの遷移があれば状態遷移テスト
テストで60%のバグが見つけられれば御の字
とっとと楽して60%のバグを見つけ、そのほかのバグがなぜ発生したか、そしてどうやって防止するかに時間を費やす
第4章 探索的テスト
探索的テストとはソフトウェアの理解とテスト設計とテスト実行を同時に行うテストである
tommy.icon要はテストケースドキュメント作成などの無駄をなるべく減らすということなのかな？
第5章 機能あらざるもののテスト、最難関のテストに挑む -非機能要求のテスト-
パフォーマンステストで発見されるバグは最悪のバグ
最初の設計からやり直しが必要な場合もあるため、ある程度プログラムが動くようになった時点で、定期的に実行する
セキュリティテストは難しい
静的解析ツールを使用したアプローチが主流になっていくのではないか
tommy.icon非機能要求に対してはこれだと言えるテストがないようで難しいと思った
第6章 ソフトウェアテスト運用の基本 -テスト成功の方程式-
テストは早く始めるほど良い
全体の感想
tommy.iconまえがきからいきなり「まあ」とか書いていて癖が強そうな文章の印象がある
tommy.iconなんか口の悪い主観的で余計な文章が入り込んでて読みにくいなぁ
tommy.iconこういう癖のある語り方って口頭だと面白いんだけど文章にすると刺々しいよなぁ
tommy.icon著者はアカデミックな知識のある方だけどこの本は実践的なものになっているってのは良い
tommy.iconテストの世界も「銀の弾などない」のだなぁ
tommy.iconバグ0は無理なのでコストと品質のバランスを上手く取りながらテストをすることが重要なのだろうな
tommy.icon「どうすればいい」という答えを提示してくれるというよりは「やり方は色々あってテストって難しいんですよ」という本だったかな