読者です 読者をやめる 読者になる 読者になる

MasaoApril's Library.

Software Testingなネタを書いてみた。

探索的テスト(2)

exploratory testing

前回は、「探索的テストを実施した背景」について書いてみましたが、
深掘りする必要がありますので、続きを書いてみます。

探索的テストを実施した背景<その1>

テスト側の視点

(1)テストベースで必要な情報が不足

 開発側から提供された詳細仕様書は、自部署製品のみ詳細に記述されているが、
他部署製品に絡むところは、(特に開発する部分については)大雑把に記述があるのみで、
テスト分析が難しいという事情があります。
 また、仕様の欠損や誤りに気付かないことも要因として挙げられます。

(2)テスト分析に必要な工数がない

 前回、

「テスト対象の製品が多く、テスト系要員が不足していた。」

と述べましたが、
私を含むテスト部隊隊員は複数の製品を担当しつつ、
割り込み業務の形で市場不具合の原因調査や不具合修正確認のテストも実施しています。
そのため、本来必要であるテスト工数が、確保できない状況になっています。
(※複数のプロジェクトマネージャ間で、工数を調整頂いていますが、
  限界があり、工数圧縮で苦しめられることもあります。)

(3)スクリプトテストの限界

 テストの事前条件と事後条件を網羅的に記述すれば、
テスト漏れのリスクは小さくなりますが、
テスト実施工数が圧縮された場合、
テストを実施するテストケースを剪定する必要があります。
しかし、テスターさんによっては、根拠の無い剪定があり、
数多くのテストを実施しても、バグが発見できないことが多いです。

 また、プロジェクトが長期間、泥沼化した時、
数をこなすだけのテストを続けて実施した結果、
テスターさんのモチベーションが低下し、
バグ発見の感度がガタ落ちになる問題があります。

次回以降、

開発側の視点

プロジェクトマネージャの視点

他部署間の視点

について、書いてみます。