JaSST'13東海SIG(10)
JaSST'13東海SIG(9)からの続きです。
今回は、「JaSST'12東海SIGでの気付き」の【5.推測】です。
(※1/25の午前に公開したものと同じです(形式上、再掲)。私のミスで【4.観察】より先に本稿を公開してしまいました。)
探索的テストを探索する from Masao Tsuzuki
(1)設計書が無い状態で外部から内部処理を推測
(ベテランの)開発経験者と共にテスト実施するとき、テスト実施結果を見て、開発経験者から「多分、○○な処理しているんだな」と話されることがあります。開発経験者もコーディング後のテストで色々と痛い目に遭っているので、痛い目に遭わないようにどうコーディングすればよいか工夫することで、経験として蓄積します。テスト実施をきっかけに開発者と情報共有すると、探索的テストも効果的になります。
以前、栃木で開催された「とちぎテストの会議02」で@miwa719さんが発表された『もやもや探索的テスト』でも言及されていました。
(2)過去の不具合が多発するモジュールの挙動
ソフトウェアメトリクスを学ぶと「ソフトウェアの80%の欠陥は20%のモジュールに偏在する」という言葉を目にしますが、(経験的に)探索的テストも例外ではないので、「80%の欠陥は20%のモジュールに偏在する」をメンバーで共有し、どこに欠陥が偏在しているか(時々)議論しています。
(3)入力や外乱の候補(ノイズ、誤操作)
テスト対象が通信系機器のファームウェアですので、下記をベースにメンバーで候補を考えています。
- 通信ケーブルの抜き差し
- 電源ON/OFF
- 電源に磁界を変化させるようなノイズを印加
- 操作ミス
- 設定ミス
(4)開発メンバーがミスしやすいタスク
難しそうな事を取り組んでいる事や急な依頼(不具合調査など)、デッドラインが迫っているタスクといったアウトプットに着目しています。
(5)不具合現象から引き起こす損害(失敗事例)
市場不具合のレポートのうち、「○○システムが不具合で△△時間停止した」という現象に着目し、似た事例はないか？調査した上で、メンバーに話して共有しています。
次回は、「JaSST'12東海SIGでの気付き」の【6.教訓】です。
