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

MasaoApril's Library.

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

探索的テスト(1)

本blogを書こうとした経緯

  2011年11月にJaSST'11 Tokaiで探索的テストについての経験発表

(http://www.jasst.jp/archives/jasst11n/pdf/S5.pdf)、

TEF東海合宿(http://kokucheese.com/event/index/27280/)で

「探索的テスト適用事例から半年をふりかえって」を発表&議論、

ソフトウェアテストワークショップ(WACATE)2012夏

(http://wacate.jp/2012/summer/program.html)の夜の分科会で、

「探索的テストを語ろまい!」を実施しました。

 

 しかし、多くの方からのご意見&ご感想から、

何が探索的なのかよく分からないとの声がありました。

 原因は、自分の頭の中で体系化できていないことが挙げられます。

 

 実は、WACATE2012夏の夜の分科会が終わった後、

探索的テストについて上手く説明できなかったことで、

落ち込んで涙を飲みました。悔しさで。

(※参加頂いた皆さまには、大変申し訳ない気持ちで一杯です。)

 

 だが、落ち込んでいる場合でもないし、

もう少し探索的テストについて議論したい方も少なからずいらっしゃるので、

一度blogの形で自分の頭の中を出し、

整理した上で体系化をしてみようと思いました。

 

以下、上手くまとまらないのですが、まずは書き出してみます。

 

探索的テストを実施した背景

  1. スクリプトテストでは検出できないバグがシステムテストのフェーズで数多く流出。
  2. スクリプトテストの仕様を設計する工数が圧縮され、詳細なテスト仕様が記述できなかった。
  3. 前述の内容と重複しますが、テスト側に開発案件が来る段階で、開発全体のフェーズとしては、詳細設計~コーディング~単体テストに移行されており、統合テストが目前であった。
  4. テスト対象の製品が多く、テスト系要員が不足していた。
  5. 開発側の余裕が無く、テストまで気が回らない。

 

 と、いったことから、スクリプトテストを実施しようにも、網羅的にテストできる環境が難しい状況でした。

 結果、バグの見逃しが多数出て、システムテストの段階で大変なことになりました。

 

もう少し、深掘りしたほうがよさそうですが、まずはここまでです。