続・JaSST'12東海 SIG

続･「探索的テストから考えるテスト現場の工夫」

前回の続きです。

SIG実施後に、下記7つの要素は、
私とベテランエンジニアで探索的テストを実施したときに、
押さえていたポイントでした。

1. 情報源
2. ふりかえり内容
3. ○○が多い/○○な傾向がある
4. 観察
5. 推測
6. 教訓
7. ○○をやってみた

以下、7つの要素の詳細について、
探索的テスト実施時の様子を思い出しながら述べます。

情報源

当時、開発課のテストグループにいたので、
開発者の情報はアクセスしやすい状態でした。
私が頻繁に情報収集していたものとしては、

1. ソフトウェア設計書レビューの指摘リスト
2. ソフトウェア設計者同士の質問メモ(Excelファイル)
3. 外部仕様書の更新部分
4. 開発者の過去の設計資料
5. あらゆる製品の市場不具合関連ドキュメント

の5点でした。
毎朝ざっと見て、変化した内容に着目していました。

ふりかえり内容

開発側

1. 市場不具合関連ドキュメントの不具合発生原因の内容
2. 反省会資料
3. 過去のインシデントレポート(最低でも2世代前のプロジェクトまで)の設計見直し内容

開発部隊の弱点を特定するのに利用しました。

テスト側

1. 過去のインシデントレポートでテストケースに無かったもの
2. 過去のテストケースで、テスト結果が解釈によって分かれそうなもの
3. コピー&ペースト&モディファイなテストケース

詰めが甘いテストケースを特定し、
「自分らだったら、テストケースをどうやって洗練させるか？」
ということを自問自答しました。

○○が多い/○○な傾向がある

収集した情報をマインドマップやKJ法で整理するときに集中している内容を
キーワードとしてメモしました。

観察

テスト中、テスト対象の変数値やLED等のI/Oを1時間張り付いてモニタして、
S/Wがどのような挙動をしているか注視しました。

推測

前述の[観察]と連動しますが、
「どのような入力や外乱を与えたら、
S/Wの挙動が滅茶苦茶になって、システムがクラッシュ/破壊できるだろうか？」
と[○○が多い/○○な傾向がある]の内容と照らし合わせて考えてみました。

教訓

過去に設計やテストで大きな失敗したとき、
次のプロジェクトで失敗しないための方策を考えたときのアイディアを利用しました。

○○をやってみた

[ふりかえり]の内容と連動しますが、
自問自答した後、
(テスト仕様には全く記述がないけど)自分がやったことがない操作や入力を敢えてやってみました。

上手く表現できたか自信がないですが、
上記で述べた要素で探索的テストを実施すると、
過去のプロジェクトより潜在不具合を見つけやすいことを肌で感じています。

次回は、「探索的テスト研究会」立ち上げにあたり、
私が考えている方針を述べたいと思います。