こんにちは。
inomata@QAです。
今回はテスト範囲が広い場合のアプローチを考えたいと思います。
まあ経験からくる反省なんですけどね。（なんの経験かは推して知るべし）
製品の根っこの部分をいじったりしてテスト範囲が広い場合、担当のテスターは憂鬱極まりないです。
そういう状況で作成されたテストケースは広く薄いものになりがちで、最悪正常系しか検討されてなかったりします。
それでリリース後にバグが見つかったりすると、何ともいたたまれない気持ちになります。というかこの場合はバグが出ます。結構な可能性で。
そんなことになって皆不幸になる前に、ちゃんと戦略的にテストをやりましょう。
こんな場合みたいにテスト範囲が広い場合は、テスト範囲を細かく区切るようにして対策していきましょう。
なんでこれが有効なんでしょうか？
テスターはテストをしていると、その集中力によって事前に定義したこと以上のテストをしたくなります。これは事前情報からじゃ見えなかった部分が見えたり、過去の経験からくる嗅覚によるものです。そうやって考えられたテストケースは割とバグを発見してくれます。
開発だって一応テストして次のフェーズに渡すわけですから、正常系くらいのテストじゃバグは出ません。
優れたテスターこそ、いやらしいパターンを思いついたりするものだったりします。（セキュリティテスト担当者然り）こうしてバグの発見率をあげましょう。
このとき、区切られた範囲は担当者を変えたほうがよいでしょう。人を変更することによって視点を変えることができますし、バグの修正に対するテストによって、テスト範囲の発散を防ぐことができます。
範囲を区切るアプローチとしては機能別、バグの発生別の2つがあります。
機能別はその通り、製品の機能が異なる部分で区切ります。その機能を熟知する担当を充てれば効果は高いですね。
バグの発生別は、テストによって発生するバグの傾向から考える方法です。バグが出やすい場所を見つけたらその部分に集中させる、おなじ種類のバグがでるからそのパターンに集中させるといったものです。これはバグが偏在するという法則にしたがってのことです。なおこの法則は本当です。
と、こんなアプローチを書きましたがいかがでしょうか。まとめると、
1.テスト範囲を細かく分ける。
2.範囲は機能別に分ける。その際は担当者を変える。
3.バグの発生具合を見て範囲を調整するとなおよい
のようになります。
よく見るとテストの基本戦術の塊みたいな感じもしますね。やっぱり基礎は大事なものです。
この記事がソフトウェアテストの参考になりますように。
2 コメント
Write コメント機能の捉え方やテスターの責務がハッキリしないのですが、気になったので質問させてください。
Reply1.テストの総数や割り合いについて
方法論としてはわかったのですが、テストの総数については触れられていません。
「テスターの探索的テストに委任する割合を多くする」ことで「対策を立てる前に想定していた薄く広いテストケースの割合を減らす」ことをするのでしょうか？
それとも、「テストケース自体は変更せずに、テスターに勘を働かせてもらうための戦略」ということでしょうか？
2.機能間の組み合わせについて
機能の捉え方が触れらていないので、意味のない質問になってしまうかもしれませんが。
この手法では「機能間の組合せによるテスト」については触れられていませんが、コンテキストによってはそのような部分にこそ「嫌らしいバグ」が潜んでいる可能性があるかもしれません。
そちらについては発生する可能性が低い/優先度が低いなどの理由によるものなのでしょうか。
コメントありがとうございます
Reply>1.テストの総数や割り合いについて
テストをしっかりやるべきフェーズで効果的なテストをしよう。といいたかったので、これは前者に当てはまります。少ないテストでより多くのバグを発見するのが良いテストと考えています。
>2.機能間の組み合わせについて
するどいご指摘です。確かに機能間の組み合わせはあまり考えていませんでした。。。
機能間といっても関連の強い部分で範囲を区切って、その中で組み合わせテストも行うというのも良いアプローチだと思います。どういう観点で、いかにして区切るかというのがテストケースの大きなポイントだと思います。決して優先度/可能性が低いというわけではありません。