「ソフトウェアテスト293の鉄則」を読んだ

テスト本２冊目。

ソフトウェアテスト293の鉄則

著者はテスト業界の偉い人たちらしい。中には「知識ゼロから学ぶソフトウェアテスト」で見たことのある名前もあった。 本書は鉄則とあるが、テストにおける重要な規則を教科書的に網羅した本ではない。 見出しこそ「〜べし、〜せよ」というものが多いが、どちらかというとテーマごとに複数の著者が持ちあったエッセイ集という性格が強いと思う。

とにかく網羅しているテーマの範囲が広く、自動化やドキュメントはもちろん、キャリアや転職やマネジメント、テスターの評価なども扱っている。 日頃からテストに関して疑問に思っていることや違和感などがあれば本書のどこかでハッとさせられる記述が見つかるかもしれない。

初心者が読む本というより、ある程度経験がありながらもテストという作業にうまく言語化できない違和感を抱えている人が読むのが良いと思う。

新しく知ったこと

• テストの５大要素

  • テストの実施者
  • 網羅性
  • 発見したい問題
  • 作業内容
  • 結果の判定方法

• テストの自動化は難しい

  • 戦略・計画がまともでないと失敗する
    • テストの目的を理解、説明できない人に自動化を行わせてはいけない
  • 同じテストケースを実施するなら人間がやる方が価値がある。
    • コンピューターはテストケース以外のことを問題意識を持って観察はしない
      • 異音がする、極端な性能劣化が発生する、画面がちらつくなど

考え直したこと

• カバレッジ
  • 100%でも足りない
    • 実装されていないことによるバグの発見が漏れる*1
    • テストの漏れは数字からはわからない
  • 昔数万行の仕様が不明のレガシーコードをカバレッジを取りながらテストしたことがある。
    • バグが発生する・しないテストデータ両方でメソッドごとにカバレッジを計測し、差分が出た箇所を精読してバグを見つけた
    • あの時はちょっと感動した
    • バグを探す糸口としてカバレッジはかなり有効だと思う。
• IEEE 829 (ドキュメント)
  • ドキュメントを管理できるスケジュール、プロセスになっていない場合、採用すべきでない
  • 膨大な資料の作成は考える力を奪い問題意識を持って取り組むことを妨げる

*1:意外とある^^;