MasaoApril's Library.

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

WACATE2014夏 夜の分科会 -探索的テスト分科会-(5) ：「報告」「マネジメント」

exploratory testing SeparateMeeting WACATE

　6/21(土)～22(日)に開催されたWACATE2014夏の1日目夜に実施した「夜の分科会」で議論された内容を5～6回に分けてまとめます。 今回は、第5回目です。

今回の内容：赤文字部分

  1. 上手くいった事
    1. 情報収集&整理
    2. プロセス
    3. アプローチ
  2. 失敗した事
    1. 固定観念
    2. 探索範囲
    3. スキル/知識
  3. ノウハウ
    1. 現場
      1. 現象
      2. 蓄積
      3. 経験則
    2. 議論
      1. スキル
      2. チーム
      3. 素質
      4. 適用範囲
      5. マネージメント
    3. 課題
      1. バグの嗅覚
      2. 方法論
      3. スキル
      4. 言語化
      5. テストチャータ
  4. 報告
    1. 報告事項
  5. マネジメント
    1. 戦略
    2. 実施期間
    3. 実施範囲
    4. アプローチ
    5. 探索的テストの効果
    6. バグが無いことを探索する
  6. まとめ

議論内容：4. 報告

・報告事項

　「テスト実施手順の記録するには？」と「どのようなレポートを記載すればよいか？」の2点が挙がりました。

「テスト実施手順の記録するには？」

　探索的テストはテスト実施手順を記載しないため、バグ発見後にバグ再現を行うことが困難です。テスト実施内容を記録する仕組み(操作ログ、パケットキャプチャ、ビデオカメラ撮影、ペアテストの相方によるメモなど)が必要です。

「どのようなレポートを記載すればよいか？」

　レポートに記載すべき内容で何が必要か決まっていない組織が多い印象でした。特にエビデンスの残し方は各参加者共通の悩みであり、バグ発生時の再現内容(バグ発生条件や手順)は情報が欠損するため、バグ発生原因の特定に時間がかかったり、特定に至らないこともあります。少なくとも前述のテスト実施手順を簡単にメモすることが必要です。

議論内容：5. マネジメント

　議論された内容を下記6点にまとめました。

5.1 戦略
5.2 実施期間
5.3 実施範囲
5.4 アプローチ
5.5 探索的テストの効果
5.6 バグが無いことを探索する

5.1 戦略

　スクリプトテストと探索的テストにかける費用(時間)を各々どの程度にするか、模索しているプロジェクトが多い印象でした。スクリプトテストの付随として探索的テストを実施するか、スクリプトテストに必要な工数が確保できないためやむを得ず探索的テストを実施するか、状況はまちまちですが、「テストで製品の何を保証するか？」を軸に戦略を練ることが重要です。

5.2 実施期間

　実践している参加者の組織では、全体のテスト工数の1/3を探索的テストとしているそうです。前項の「5.1 戦略」でも言及しましたが、「テストで製品の何を保証するか？」をステークホルダとすり合わせして実施期間を決めることができれば、「テストで製品の○○をどう保証するか？」検討することができます。

5.3 実施範囲

　スクリプトテストで実施したテストと(工数の制約で)実施できなかったテストがあれば、後者のテストを探索的テストでカバーすることもテストの工数が確保しづらい状況では有効です。また、スクリプトテストバグ修正の影響範囲を確認するために、影響のありそうな機能を探索してテストを実施することも時間効率面で有効です。

5.4 アプローチ

5.4.1 役割(位置づけ)

　「スクリプトテストを補うため」「スクリプトテストで見つけづらい欠陥を見つける手段」といった役割を組織内で議論して決めるとよいと思います。

5.4.2 変更

　現プロジェクト：探索的テスト→次プロジェクト：スクリプトテストに切り換え、探索的テストで得られたノウハウをスクリプトテストにフィードバックすると、スクリプトテストでバグ発見の面で改善することが期待されます。逆に、現プロジェクト：スクリプトテスト→次プロジェクト：探索的テストに切り換え、スクリプトテストでバグ発見が頭打ちに至ったときに実施すると、バグ発見数が改善できる場合があります。

5.4.3 併用

　前項「5.4.2 変更」は、スクリプトテストと探索的テストはプロジェクト毎のテストですが、現プロジェクトでスクリプトテストと探索的テストを交互に実施し、両者のアプローチの弱点を補うアプローチもあります。例えば、初めはスクリプトテストを実施し、バグが発生した時かバグが出てこないときに探索的テストに切り換える方法があります。しかし、スクリプトテストと探索的テストを切り換える判断基準を決めなければ、ad-hocテストに至ることもあり、事例があればインタビューして、改善案を検討する必要があります。

5.5 探索的テストの効果

　探索的テスト実施後の結果をどのように評価するのか、参加者から評価基準をどのように設定すればよいか難しいという意見がありました。また、探索的テストのカバレッジの定義についても結論が出ない状態でした。探索的テストを実施したことにより、何のメリット/デメリットがあるか？を議論する余地があります。

5.6 バグが無いことを探索する

　探索的テストは、バグがあることを念頭に置いて実施しますが、逆に「バグが無い」ことを示すために探索的テストを実施する組織もあるそうです。バグを無いことを証明するのは難しいことですが、「限られた工数でここまでやりました」と説明責任を果たす手段の1つになりそうです。

次回の内容：赤文字部分

　次回は、最終回 6.まとめです。

  1. 上手くいった事
    1. 情報収集&整理
    2. プロセス
    3. アプローチ
  2. 失敗した事
    1. 固定観念
    2. 探索範囲
    3. スキル/知識
  3. ノウハウ
    1. 現場
      1. 現象
      2. 蓄積
      3. 経験則
    2. 議論
      1. スキル
      2. チーム
      3. 素質
      4. 適用範囲
      5. マネージメント
    3. 課題
      1. バグの嗅覚
      2. 方法論
      3. スキル
      4. 言語化
      5. テストチャータ
  4. 報告
    1. 報告事項
  5. マネジメント
    1. 戦略
    2. 実施期間
    3. 実施範囲
    4. アプローチ
    5. 探索的テストの効果
    6. バグが無いことを探索する
  6. まとめ