MasaoApril's Library.

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

WACATE2014夏 夜の分科会 -探索的テスト分科会- (2)：「上手くいった事」

exploratory testing WACATE SeparateMeeting

　6/21(土)～22(日)に開催されたWACATE2014夏の1日目夜に実施した「夜の分科会」で議論された内容を5～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. まとめ

議論内容：1.上手くいった事

　「上手くいった事」に関する内容をマインドマップで示します。

WACATE2014 夜の分科会(上手くいったこと)

※念のため、内容をまとめたマインドマップ(全体)を再掲します。

WACATE2014_夜の分科会_まとめ

　議論された内容を整理したところ、下記3点に集約されました。

1.1 情報収集&整理
1.2 プロセス
1.3 アプローチ

1.1 情報収集&整理

1.1.1 過去情報

1.1.1.1 テストケース

　過去のテストケースから、テストの目的やテストの観点を明確にした上で、次に実施するテストを検討してからテスト実施したところ、バグが検出される事例がありました。後述する「(1-1-2)不具合情報」と組み合わせると、より効果的です。

1.1.1.2 不具合情報

　お客様からの製品クレームである「市場不具合」と製品開発部署からの不具合報告である「インシデントレポート」をテストチャータの情報源として活用する傾向があります。

1.1.1.2.1 市場不具合

　市場不具合の事例や体験が経験知(欠陥内容のノウハウ)として蓄積され、他開発のテスト工程で経験知(欠陥内容のノウハウ)をトリガーに閃いた結果、バグが検出される話題がありました。もしかしたら、欠陥を引き起こす要因と欠陥内容のパターンが知らないうちに結びついているかもしれません。

　市場不具合発生時に開発組織内で

  1. 「不具合状況報告」
  2. 「不具合再現」
  3. 「不具合条件特定」
  4. 「不具合修正」
  5. 「不具合修正確認」
  6. 「お客様へ(不具合に関する)報告」

の対応することがありますが、1.「不具合状況報告」の情報をテストチャータとして活用し、2.「不具合再現」で『不具合条件』を推測&動作したところ、不具合条件を特定したことがあります。

　開発組織の弱さに関する情報として、『不具合条件』を蓄積し、テストチャータのベースとして活用することも一案です。また、(肥大化して使い辛いと批判されがちな)設計のチェックリストも過去の市場不具合からの教訓が少なからず内在しますので、テストチャータとして活用することも検討の余地があります。

1.1.1.2.2 インシデントレポート

　インシデントレポートは、バグ情報のノウハウが凝縮されています。過去のプロジェクトのインシデントレポートから欠陥のパターンをまとめた上で、どのように探索するか探索する手段を検討する余地があります。

1.1.2 設計情報：ソフトウェア設計の変更点

　仕様変更に関わる問題が派生開発の現場で現れるが、開発者でFMEA(Failure Mode and Effect Analysis)などの手段でソフトウェア変更による不具合の影響を検証できていない場合、ソフトウェア変更に起因するバグが(開発者のスキルの良し悪しに依存するが)多発することが予想されます。事前に開発者からソフトウェアの変更点について聞き出し、開発情報として整理してから、『(変更前後の)挙動の違い』をベースに何を探索するのか、探索する目的を検討することも有用です。

1.2 プロセス

1.2.1 本気でテスト実施

　没頭して製品を使用するようにテストを実施すると、バグが検出された事例が挙がりました。ユーザシナリオのテストを実施しているとのことですが、James Whittakerの著書である"Exploratory Software Testing"のChapter6:Exploratory Testing in Practice に現場の事例があり、ユーザシナリオのテストをアドリブ交えて進めることに類似していると思いました。

1.2.2 スクリプトテストの延長

　私も時々ですが、スクリプトテスト実施中にスクリプトテストをベースに探索的テストを実施しています。また、I. M. Testyのblog記事"Exploratory testing vs. Scripted testing; Is it really only either or?"によると、「スクリプトテストと探索的テストの両方を活用するとテスト実施時の欠陥検出やスクリプトテストをブラッシュアップすることに寄与する」ことが言及されており、テストを改善するアプローチとしては有用です。

1.2.3 バグ修正確認

　前項(2-2)に類似していますが、バグ修正確認時に即席でバグ修正を確認するためのスクリプトテストを分析/設計/実装を行いますが、バグ周りの機能も悪影響がないことを確認するため、探索的にテストすることがあります。

1.3 アプローチ

1.3.1 観察：微妙な挙動の違い

　バグ検出のきっかけとして、入力値に対する出力(テスト対象の挙動)が仕様と異なると認識した時が挙げられます。コーディングミスまたは仕様の誤りによって引き起こされる、見えない境界値を発見したことになります。

1.3.2 推測：バグ発見時、発生条件を特定

　検出されたバグの特徴や傾向を学習した後、バグが検出された機能周辺を切り出し、観測してバグ発生条件を特定するため、バグが検出しやすくなります。

1.3.3 進め方：考えないでテスト実施

　ドメイン知識無しで探索的にテスト対象をテスト実施すると、バグが検出された事例がありました。議論で挙がりましたが、ドメイン知識が豊富な状況で探索的テストを実施するとバグ検出しやすい事と相反します。何故だろう？と疑問がありましたが、先入観が無い状態で探索的テストを実施すると、バグを見落とすリスクを低減できるのではと思いました。

次回の内容(予定)：赤文字部分

  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. まとめ