MasaoApril's Library.

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

JaSST'13東海SIG(16)「テストチャータの役割」

JaSST'13東海SIG(15)からの続きです。

SIGでの議論内容(1)

 JaSST'13東海SIG(14)及びJaSST'13東海SIG(15)では、ホワイトボードに付箋に貼った内容を紹介しましたが、今回から数回に分けてホワイトボードを見ながら議論したことについて紹介します。

スライドのチャータ

What/When/Whereをどう書けばよいか分からない(前項の説明との繋がりがよく分からない)

無理があるのでは?

 当初(JaSST'13東海SIG(13))、テストチャータを切り口をWhat/When/Whereから検討すると作りやすいのでは?と思いました。しかし、探索的テストの知見は体系的にまとまっていないため、知見と知見との繋がりが見えず、切り口としては良くない結果となりました。

 そこで、探索的テストで必要なことを付箋に自由形式で書き出すことにしました。

テストチャータの役割

  1. 探索的テストの経験がなくても、探索的テスト実施できるようになる補助輪
  2. バグを探索しやすくする

 テストチャータは、ad-hocなテストを防止する役割を持ちますが、記載された内容はある意味、暗黙知形式知と化したものと捉えることができるため、探索的テストが未経験でも多少バグを探索しやすくなる役割を持ちます。ただし、探索的テストでバグを検出しやすくするため、テストチャータの表記をどのように表現すればよいか、議論の余地があります。

 私がテストチャータ作成に至るまでに悩む事として、下記4点があります。

  1. 探索目的の設定
  2. テストチャータ作成のための分析
  3. 記載内容の抽象度
  4. 記載内容の量

 1.は、何を探索するのか探索目的を設定しないと、ad-hocなテストを実施することに繋がりやすいですので、効果的にバグ検出できない可能性があります。私が実際に探索的テストを実施したとき、朝会などの定期ミーティングで探索目標を「これまでのテストであまり実施していなさそうな機能」「インシデントでよく報告された機能」としました。今後の課題として、探索目的の内容とバグ検出数の相関がないか、計測するメトリクスをGQM法のアプローチで検討する必要があります。

 2.は、バグ探索を容易に実施するため、テストチャータ作成のための分析をどのように行うか検討する必要があります。JaSST'11東海の経験発表で分析したのは、「外部仕様書」「テスト仕様書」「ユーザマニュアル」のドキュメントです。もう少し掘り下げると、ドキュメント内容を「操作」「動作」「設定」「構成」「出力」で分解してマインドマップや表でまとめ、「操作×操作」「動作×操作」「動作×動作」の組み合わせを2次元マトリクスとして表現し、探索的テスト実施時に活用しました。「設定」「構成」「出力」の3要素は、探索的テスト実施時の補助的な情報の位置づけとしました。しかし、どのような要素の組み合わせがバグ検出の効率がよいか、さらなる検討が必要です。

 3.は、抽象度を高めるとどのようにテストを実施すればよいか、分からなくなります。逆に抽象度を低くする(具象度を高くする)とスクリプトテストと同様となり、探索的テストでは無くなります。抽象と具象のバランスは、開発ドメイン/開発メンバーのスキルなどによって変わりますので、状況に合わせた調整が必要だと考えます。例えば、ベテランエンジニアと探索的テストを実施する場合、抽象度をキーワードで想像できるレベルに設定することは問題ないと判断しますが、経験が浅いエンジニアと探索的テストを実施するとき、抽象度を低くすることが考えられますがどの程度、抽象度を低くするかは何らかの基準が無いと難しいと思います。

 4.は、探索的テスト実施工数が数人月程度でしたのでやりきれる量として、2.で言及した2次元マトリクスを10項目×10項目の規模に留めました。根拠は、1項目で○人時と見積もったためです。探索的テスト実施工数とテストチャータの記載内容の量をどの程度にするかは、3.の抽象度とのトレードオフと考えます。

 次回も、議論内容の続きを書きます。