ソフトウェアテストの順番

このエントリーをはてなブックマークに追加
こんにちは。QA担当inomataです。

 オリンピックも終わって8月も後半です。でもまだ暑いです。学生の方は「そろそろ宿題に手を着けなければヤバイ。」あるいは「どうせもう間に合わないからここで手を着けたら負けだ。」みたいな謎の葛藤に追われてるでしょう。わたしの中学校は全教科に宿題が出されていて、上手くスケジュールを組まないと到底終わらない量でした。もはや中学生の夏休みの思い出はそんなものしかありません。夏休みにおける宿題の必要性について自問自答していたあのころが懐かしい。。

 さて、テストにおいてもスケジュール(順番)というのはかなり重要です。
エクセルから専用のテストツールまで。各々のテストケースはいろいろなツールで管理されていると思いますが、それを実行する人、特に日本人であれば必ず上から下へ、左から右に実行します。以前実験した事があるんですが、5人のテスターにエクセルで書かれたテストケースを渡すと、必ずこの順番で実施しました。それ自体が悪いという事ではありませんが、このテストケースは順番が考慮されているか?というのが重要になってきます。

 テストエンジニアは製品のバグを見つけなければなりません。発見されるバグは市場においてインパクトの高いものが望まれます。同時に発見されたバグは開発へ素早いフィードバックが求められます。つまり、市場においてインパクトの高いバグを素早く発見して開発へフィードバックしなさいという事です。
「何当たり前のこと言ってんだ?」と思われたでしょう。ではもう一回お手元のテストケースを見てください。そのテストケースは今言った事が反映されているでしょうか?

 特にこれは、テストケースを作成する人とテストを実施する人が別である場合で重要です。テストケース内に必ず実施する順番を明記しておかなければなりません。でないと、テスト終盤になって修正が困難なバグが発見されて・・・とか、テストの後半が実施されていない(実話)!という悪夢を見る羽目になります。(後者は別の話か・・・)

 では順番どうするのか?という話になると思いますが、これは一般的なリスクの識別、評価と同じになります。再現した時のインパクトと、それが起こりうる可能性に点数を付けて順番を決めます。品質業界ではFMEAという手法がメジャーじゃないでしょうか。「リスク評価」で検索すればgoogle先生がいろいろ教えてくれます。
また、別の観点から見ると、重要な機能(それが動かないと他の機能がテストできない等)を優先することも重要です。
順番を決めると、前述のように重大な問題を早期解決しやすくできるほか、数値で評価出来るので明確なテスト終了基準も設ける事が出来ます。良い事だらけですね。

 と、ここまでTIPSのように書いてきましたが、これはリスクベーステストという手法です。テスト技法というよりはプロセスの品質を改善するもので、大規模で長期間にわたるプロジェクトでは必須の手法と言えるでしょう。リスクベーステストはRex Black氏の著書に詳しく載っていると思います。

リスクベーステストで良いテストライフを!
次の記事
« Prev Post
前の記事
Next Post »

3 コメント

Write コメント
@kyon_mm
AUTHOR
2012年10月10日 20:00 delete

テストの優先順位が途中で変更になることはないのでしょうか?
また、そのような場合にExcelのような形式でも優先順位の柔軟な変更に追いつけるのでしょうか?
そのへんの運用的なコツがあればぜひ教えていただきたいです。

Reply
avatar
匿名
AUTHOR
2012年10月10日 20:24 delete

いつも、参考にさせて頂いております。

実施優先順位についてリスクの評価結果を 反映させるという点、その通りだなぁと思いました。

どの単位で優先順位をつけるか?という点は私の場 合、 テストケース単位だと日々、Bugの状況で変わってき てしまい保守や管理が複雑になる という理由からテストケースの上位単位(テストタイプ もしくはテストスイート)で やるようにしてます。

現実的には、テストタイプとテスト対象(例えば機能や モジュールなど)が、 N対Nで存在するので苦労するのですが。 ※この辺はリスクベーステストでもうまく説明できて いない気がします。

上記のような管理上の問題がありリスク評価結果を具 体的なテストの実施優先度に 紐付けするにはもう少しなんらかのテクニックが必要 かなという気がします。

Reply
avatar
inomata
AUTHOR
2012年10月11日 17:27 delete

>テストの優先順位が途中で変更になることはないのでしょうか?
優先順位をつける単位が大きめなので変更は少ないです。むしろ変更が多い単位ではつけないです。(管理できなくなるので)

あとからのコード変更が大変!
重要な機能!(リリースが早い、よく使われる等)

の2つを意識だけで、後々大変なことにはならないのです。
あまり細かい単位で管理する必要もないかと思います。

Reply
avatar
Related Posts Plugin for WordPress, Blogger...