ソフトウェアテストについて体系的に学んだことがないので、とりあえず何冊か本を読んで、概念や用語、手法などを知ろうと思い、最も易しそうで Amazon のレビューも良かったこの本から読んだ。文章が堅くなく、文量も少ないようで、一日で読めてしまった。内容は確かに易しくわかりやすい。そこに価値を認めるからには、詳細で網羅的・包括的とはいえない点は仕方ないというべきだろう。文体から受ける印象だけでいえば、筆者のキャラクターは好みではない。
テストをする上での考え方について、なるほどそう考えるのかと初めて知ったこともいくつかあり、読んでよかった。いくつか「それはどうかなぁ」と思うところもあった。どのみちこの本だけ読んで済ますわけにはいかなそうだし、そのつもりでもない。自動化テストについては懐疑的な立場で書かれていたが、自分の目下のゴールはそこなので、先人の見解を踏まえて「勘所はどこか？」を考えていきたい。
- スモークテストは自分が思っていたよりも「軽く浅い」テストのことを指すようなので、所要時間も短くて済むだろうから Commit ごと・Pull Request ごとに CI で走らせてもビルドジョブを専有しすぎることはなさそう
- 回帰テスト（リグレッションテスト）については自分のこれまでの理解で概ね間違っていなかったが、より正しい理解に近づいた・理解が深まったと思う
- 「回帰テストは自動化に向かない」と書いてあったが、じゃあどうやって回帰テストするのさ？という点が疑問（人力で増え続ける回帰テストをやり続けるわけにはいかないだろう）だがちょっと解釈を変えて、「テスト担当者の作業として自動化はしない。回帰テストは開発者が単体テストとして自動化すべきである」と考えたらしっくりきた（というかすでに大概のケースでそうやっている）
- 厄介なのは「相互に独立した複数のシステムをまたぐ連携機能のバグに対する回帰テスト」をどうするか？というところで、現状そういうものが（エッジケースだとしても）単一システムに対する自動化テストではカバーできないので人力テスト項目に追加せざるを得ず、テストの負担が増しているのだが、これは「もしその機能が再び壊れたとき、ソフトウェアが提供するサービスに致命的なダメージがあるのであれば、『出荷はおろかテストできる品質に達していない』とみなせるので、スモークテストに追加し開発者が新しいコードを書くたびに常時実行されるようにすべき（その自動化テストのメンテナンスコストはたとえ高くつこうが払わなければならない）」と考えてみたら割と納得感があるような気がする。
- 作者: 高橋寿一
- 出版社/メーカー: 翔泳社
- 発売日: 2013/12/10
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (7件) を見る
以下、ハイライト。
- まず境界値テストをやってください。そこで境界値に関わるバグをすべてつぶしてください。そしてもし入力エリアが二つ以上あるようなダイアログとかあるようならディシジョンテーブルテストを行ってください。そして状態が遷移するようなソフトウェアの場合は状態遷移をやってください
- もしそれでもバグが見つかる場合は二つの理由があります。 あなたの境界値テスト等のブラックボックステストのアプローチが間違っている（ちゃんと本書を理解していない
- 筆者の経験上、初期に書かれたそれほど練られていないテストケースを繰り返すことにはあまり意味がありません
- テストを実行しながら、どこかほかの部分に問題がないかを考え、そこをテストす
- ソフトウェアで弱いところを見つけたら、そこに重点を置き、その部分を十分にテストす
- テストケースを設計する際、パフォーマンスの要求定義に書かれた通りのテストケースを書いてはいけません。テストはバグを見つける作業だからです。ですから、要求定義通を逸脱するような（バグを発見するような）テストケースを設計しなければなりません
- テスト責任者は明確な予算策定とコストに対する意識を持つべきです。なぜなら品質とコストは相関関係にあるからです
- 48時間以内に重要度「高」のバグが発見されていないこ
- もしそのバグが非常にみっともないものであっても、システム全体をクラッシュさせたり、明らかにセキュリティ上の問題がある場合を除いて修正は思い留まるべきでしょう。コードを修正する場合は、その時点で出荷を延期し、すべてのテストサイクルをもう一回繰り返すことをお勧めします
- 最後の最後になってなんらかのコード修正を入れることは、それまで行ったテスト作業の努力を無にする危険があるのです
- メトリックスというのは、単に数字だけを取り上げて判断するのではなく、その数字の性質をよく知ったうえで利用するべきなのです
- バグメトリックスのもう一つの例は「バグの修正にどのくらい時間がかかるか」というものです
- テストの自動化を成功させるには、自動化コードの保守コストを低く保つことが必要です。なぜなら、まずい自動化プログラムはメインテナンスコストがかさみ、自動化のコストメリットがなくなってしまうからです
- 回帰テストは一見自動化に向くように思えますが、それは大きな間違いです
- そんなバグが以前あったからといって、印刷をしながらほかのすべての機能も組み合わせたりしてテストすることは間違っています
