リスクベース、経験ベースでテストスコープを削る

はじめまして。
HumanCrestの津久井です。

私は入社以来、7年間組込製品の検証業務に携わっております。
日頃、現場で様々な問題に遭遇しますが、その中で学び、実践している点について
お話させていただきます。

私の役割は主に、対象となる組込製品全体のテストスコープについて考えることです。

何を優先してテストし、何をテスト対象外とするかについてはいつも頭を悩ませており、
実施する/しないを判断する際に、「どちらかと言えば実施したほうがよい」という判断基準で
テストを実施してしまうと、時間がいくらあっても足りなくなってしまいます。
しかし、時間に限りがあることを理由に、安易に「実施しない」という判断は決して出来ません。
「実施しない」ということ自体リスク以外の何物でもありません。

そもそも全数テストは不可能。
だからこそ、様々なアプローチでテストスコープを決定して、
効率的なテスト実施数(テスト品質)を確保し、QCDのバランスをとることが求められます。

全テスト項目を実施するほど時間は無い(確保出来ない)。
よって、実施するテストスコープをある程度絞らなければならない。
ではどのようにしてテストスコープを絞るのか。

いろいろなアプローチがありますが、私が実際に行っている絞り方の一つをご紹介します。

■リスクベース、経験ベースでテストスコープを削る

私の担当している組込製品は過去に何機種も市場に出ていますし、
それら組込製品の検証業務にも携わってまいりました。
製品仕様書はもちろんのこと、過去機種のテスト結果、不具合の内容や修正確認結果など、
とても参考になる情報がそろっています。

それらの情報の中から特に、注意して目を向けているのは以下の内容です。
・すでに市場に出ている製品とまったく同じ機能はどれくらいあるのか
・新機能/進化した機能はどれくらいあるのか
・過去の類似した製品のテスト結果はどうであったか
・過去の類似した製品で検出された不具合はどのようなものがあるのか
・ソース上、同じ遷移/制御をおこなっている箇所はどれくらいあるのか
・ユーザーが一番触れる機能はどこか

これらの情報から、優先的に実施すべきテストがだんだんと見えてきます。
・新機能や変更点のある機能と、その機能が関連する箇所
・過去機種で不具合が多かった機能のテスト項目

また、考えられる組み合わせの全数ではなく、ある程度間引いて実施してよさそうなテストも
同時に見えてきます。

・すでに市場に出ている製品とまったく同じ機能
・ソース上では同じ箇所

もちろん上記にあげた内容はあくまでも例えです。
実際はそんなに簡単に割り切れないと思いますし、テスト項目を減らすということは、
そんなに簡単な事ではありません。

ちなみに私の現場では、上長とレビューを行うことで最終的なテストスコープが決定します。
テストケースレビューを行うということは、最終決定と合意形成を得る最上級の場です。
そのレビューで私の考えをしっかりと伝える為にも、多くの情報を用意する場面も少なくありません。

■最後に
リスクベース、経験ベースでテストスコープを削るという方法で、実際にテストスコープを絞ることが出来、
テスト項目を減らすことにもつながっています。

テストスコープを絞る材料を増やす為にも、常日頃から意識的に情報を残し、
残した情報を後で確認しやすいように整理し、これらを将来的に参考になる情報としてよい形で蓄えることが、
最終的に”リスクベース、経験ベースでテストスコープを削る”ということにつながります。

苦労して実施したテスト項目や、報告した不具合、提出した報告書、これらはいわば我々の財産。
テストを構成管理して、ナレッジを貯め、活用出来るよう常に意識していくことで、次のテストに必ず役立ちます。

これは、組込製品の検証業務だけの話ではなく、すべてのQA業務で言えるのではないかと思っています。

このエントリーをはてなブックマークに追加