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

MasaoApril's Library.

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

JaSST'14東京(1)

JaSST exploratory testing

ソフトウェアテストシンポジウム'14東京に参加しました。前回は、コミュニティブースの話でしたが、本稿は参加したセッションの内容で思ったこと感じたことを書いてみます。
 今回は、「探索的テストを活用したシステム開発手法の提案」です。

探索的テストのメリット/デメリット

・メリット

(1)バグ検出率:高い
(2)S/Wの非機能的なところの指摘:可能

 私も実際に適用したときに実感しましたが、(1)は(バグ検出率のメトリクスが何かは不明ですが)テスト実施工数当たりのバグ報告数は、スクリプトテストよりは高い実感があります。(2)については、多くはないですが「○○の操作手順が煩雑だよね」とメンバーと話したことがありました。

・デメリット

(1)追加のテスト:増加
(2)バグ再現率:低い

 (1)と(2)は陥りがちですが、工夫次第で制御できると思いました。(1)は、1日に追加する項目数に制限をかける。(2)は、ペアで探索的テストを実施し、一人はテスト実施し、もう一人はテスト実施中のモニタリングを行いながら、操作や設定内容をメモ書きすることも有効です。

SIのプロジェクト

・計画に乗ったプロジェクト

・SIのテストで求められていること

(1)客観性
(2)可監査性

 SIのプロジェクトで(2)の可監査性が重要視されているという状況なので、公式なテスト(スクリプトテスト)でエビデンスが必要と解釈しました。探索的テストは、ad-hocテストとして誤用されることがあるので、何をどのようにテスト実施したかエビデンスを残す仕組みが必要です。

5W

[Why]

Q:探索的テストは受け入れられるか?
A内部のQCD向上を目的とする

[What]

Q:ターゲットは?
A:異常が分かりやすいS/W(例えば、UI系)

[Who]

Q:誰が探索的テストを実施するのか?
A:業務ノウハウ(経験)を熟知した人

[Where]

Q:どのような環境で探索的テストを実施するのか?
A:非機能系は不向き(機能テストに向いている)

[When]

Q:いつ終えるのか?
A:信頼度成長曲線が探索的テストと相性が良い

 探索的テストを実施する理由を説明するとき、5Wを用いて問いかける形で検討すると、ステークホルダが納得しやすいと思いました。また、テストチャータのベースになりそうだと思いました。

戦略

どこを攻めるのか?

マインドマップから検討

 メンバーで共有する形は、表現の違いはありますが、私が適用したときと同じであることに気付きました。問題vs我々の構図で進めると効果的です。

どう攻めるか?

・過去のトラブル
・意地悪漢字

 過去の経験を引き出す工夫として、過去のトラブルを活用することが探索的テストでは必須と思います。また、意地悪漢字(鈴木三紀夫氏考案)は、メンバーの暗黙知を引き出すアプローチして有効と思います。

やらないこと

・不具合発生の再現

 理由:再現しないことが多いため

・バグの解析

 理由:時間がかかるため

 限られたリソースで探索的テストを実施する場面が多々ありますので、ステークホルダに対し「やること」「やらないこと」を明示し、合意を取ることは必要です。

Q&A

 下記2点の質問をしました。メモとして残しますので、参考頂ければ幸いです。

Q1:探索的テストと信頼成長曲線の相性がよい理由は?

A1:スクリプトテスト(公式なテスト)で信頼性成長度曲線が信用できるか?という検証するため。理由は、恣意的に操作できることを懸念しているため。探索的テストの場合、実施順序や操作が難しいため、信頼成長度曲線の曲線が操作しにくい特徴がある。

Q2:マインドマップはテストチャータなのか?

A2:マインドマップは、テストチャータと言い難いと考えている。なぜなら、テスト中にマインドマップの枝が増え、実施するテスト量のコントロールができないため。テストチャータのベースは、スモークテストの結果を用いている。

次回は、「テスト設計コンテスト2014決勝戦」です。