もう２週間くらい前の話ですが、軽く読み返しました。
いちばんやさしいソフトウェアテストの本 (技評SE新書 19)/石原 一宏
￥882
Amazon.co.jp
この本を買った時期はとにかくテストについて色々知りたくて、もう１冊買ってるんですが、
そちらは後日。
『いちばんやさしい』と謳っているだけあり、かなり噛み砕いて書かれている印象です。
広く浅くですが、開発の流れから、テストの意味、種類、ちょっとしたスキルまで書かれていて、
読みやすいと思います。
個人的に印象に残ったところをいくつか。
● 正しい製品を作っているか？/正しく製品を作っているか？
この２つは異なる概念であり、またテストでは仕様通り動くこと以外にもチェックすべき点が
ある、というところを書かれています。本書の中では
Verification（正しく） ⇔ Validation（正しい）
と、表現されています。
● 対象範囲/非対象範囲
テストする範囲、テストしない範囲をきちっと決める。
しない範囲があるかないかはその製品によると思いますが、テスト範囲を整理
することで、MECEにテストすることに近づくことができるのかな、と。
当たり前のことだけれど、意識的に行うことでテストの品質の向上につながると思います。
● 組み合わせテスト
テスト項目の組み合わせによって、パラメータの数多の組み合わせをチェック可能な数まで
落とし込むことができます。
また、経験的にエラーは「2つまでのパラメータの組み合わせで発生している」ことが知られている
ため、この方法で網羅的にエラーをチェックすることができるそうです。
（参考：第1回 組み合わせテストの技法）
組み合わせ法に関しては、網羅的に行うことは出来る反面、それでも100%はカバーできませんし、
パラメータのとり方によっては、カバー率が低くなる可能性があるため、何と何を組み合わせるかは
熟慮する必要があります。
ただ、組み合わせテストに関しては、今回自分がテストを行うにあたり、この考え方を念頭に
パラメータを眺めてみると、変更がない（必要がない）パラメータを２つ抜き出すことができた
ため、それらを組み合わせることによって無駄なチェックを減らすことが出来たように思います。
本来の使い方として正しいかはわかりませんが、意識して項目を精査すると、効率的なテストを
行うことができると感じました。
個人的には手法よりも、先に出てきた”正しい”製品かどうかのチェック、が非常に重要であると
言う点が、納得させられました。
特にユーザからリリース前に直接チェックを受けられないWEBの開発では、ユーザにとってどれだけ
正しい（利用しやすい、ストレスが少ない）製品かを意識することが大切。
自分自身、面倒くさがりな性格で、仕様通りやん！と思いたくなってしまうこともありますが、
やはり使ってもらう、ということの意識をしっかり持って作るようにしたいと思います。
しかしやればやるほどテストは難しい気がします
より効率的に（一番いいのは、テストでくまなくチェックし、バグを洗い出しきることだと思います）、
よりよいテストができるように、経験積んでいきたいと思います。
次はこれかなー。
現場の仕事がバリバリ進む ソフトウェアテスト手法/高橋 寿一
￥2,499
Amazon.co.jp