WACATE2014夏 夜の分科会 -探索的テスト分科会-(4) ：「ノウハウ -議論-」「ノウハウ -課題-」

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

今回の内容：赤文字部分

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

議論内容：3.2 ノウハウ -議論-

　議論内容を5つのキーワードとしてまとめました。

3.2.1 スキル

3.2.2 チーム

3.2.3 素質

3.2.4 適用範囲

3.2.5 マネージメント

3.2.1 スキル

3.2.1.1 底上げするには？

　探索的テストが得意な人はなかなか見つからないかもしれませんが、普段のテスト(スクリプトテスト)を観察すると、お手本になる人が見つかるかもしれません。
　例えば、インシデントレポートに登録された内容から、「困る方々が多数出そうな内容のバグ」や「ピンポイントのタイミングや条件でしか発見できないバグ」に着目すると、お手本になることもあります。

3.2.1.2 センスの養い方は？

　バグを見つけるためのセンスを養うことも探索的テストを上手く進めるために必要な要素ですが、どのようにセンスを養うのか難しい面があると思います。生活の中や会社生活の中でできそうなのは、「自動販売機」「食品スーパーのセルフレジ」「銀行のATM」「地下鉄の券売機」「Amazon.comに代表される通販サイト」「エアコンなどのリモコン」を操作するときに15秒程度「どのような操作を行うと、システムやデバイスが壊れるだろうか？」を考えて操作し、挙動を観察することが、センスを養う近道と思います。

3.2.2 チーム

3.2.2.1 オフショア企業での探索的テストの活用

　私の現場では、オフショア企業とやりとりした経験がありませんが、派遣社員の方と探索的テストを実践した経験から言うと、テストを実施する目的を共有することが上手く活用できるカギです。また、製品がどのように使われるか、望ましくない動作についても議論する必要があります。

3.2.2.2 どのようにマネージするか？

　探索的テストを実施するとき、困ったこととして「時間をかけてもバグが見つからない」ことでした。また、テスト対象の探索範囲が狭くなりがちで「様々な手段を講じたがバグが見つからなかった」こともあります。
　私が実践したときは、

1. 「30分テスト実施して、挙動が変化しないときは、一旦打ち切ろう」
2. 「手段が細かすぎないよう、お互いに何をやったか、朝一に情報共有を行おう」

の2点をグランドルールとして運営しました。

　探索的テストに関する様々な資料や様々な方との話から、セッションベーステストでマネージすることが多い印象でした。

3.2.3 素質

3.2.3.1 探索的テストと相性のよい性格は？

　WACATE2014夏(3)：「クロージングセッション」でも書きましたが、

1. 「徹底的に追い詰める感覚を持っている」
2. 「徹底的に記録を取る」

の『徹底的』に取り組む性格もこれまでの経験からの傾向を見ると、該当すると思います。

3.2.4 適用範囲

3.2.4.1 探索的テストの適用範囲

　ミドルウェアは探索的テストに適用できるか？という話がありました。探索する目的によっては、適用できるのではと思いますが、(開発マネージャに交渉してOKが出たら)試行し、結果から適用できそうか判断するのがよいと思います。また、開発状況を整理した上で国内外の事例を集め、プラクティスとしてまとめることもこれからの課題です。

3.2.5 マネージメント

　実践されている方から「1セッションをどのように計画すればよいか？」という話題が挙がりました。JaSST'13東海のSIGでも「探索的テストの計画があるのでは？」という話題がありましたが、海外ではセッションベーステストでマネジメントを行っているようですので、セッションベーステストに関する知見を集約する必要があります。(今後の課題)

議論内容：3.3 ノウハウ -課題-

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

3.3.1 バグの嗅覚

3.3.2 方法論

3.3.3 スキル

3.3.4 言語化

3.3.5 テストチャータ

3.3.1 バグの嗅覚

　・バグを発見できる人/バグを発見できない人

　WACATE2014夏(3)：「クロージングセッション」の「(1)バグを見つけるのが上手い人」やJaSST'13東海SIG(8)の【3.○○が多い/○○な傾向】、 JaSST'13東海SIG(9)の【4.観察】、JaSST'13東海SIG(10)の【5.推測】の要素をメンバーに話しができるか否かがカギとなります。

3.3.2 方法論

3.3.2.1 上手いやり方が分からないが...

　適用した方によると、担当者に一任しているのが現状とのことでした。担当者に探索的テスト実施における裁量をどの程度持たせるか、担当者のドメイン知識とテスト対象に対する理解の程度がカギになりそうです。

3.3.2.2 どうやったら、バグを見つけられるのかを共有できない...

　過去のインシデントレポートから、どのようにバグを見つけたのか過程が説明できると、バグの見つけ方パターンが見えてくるのではと思います。また、探索的テスト実施中に発見したバグを紹介する機会を設け、バグ情報を共有することも必要と思います。

3.3.3 スキル

　テスターの熟練度が大きな要因となりますが、スキルの測り方として「これまで経験した教育(教育機関や業務に関わる研修など)」「インシデントレポートの記載内容(バグの発生条件、再現手順など)」「仕様書などのレビュー時の指摘内容」が参考情報になります。

3.3.4 言語化

　言語化できると、「3.2.1 スキル」や「3.2.2 チーム」、「3.3.2.2 どうやったら、バグを見つけられるのかを共有できない...」の問題が解決できる糸口になりますが、ソフトウェアの欠陥に関する知見(書籍「ソフトウェア病理学」、直交欠陥分類(ODC:Orthogonal Defect Classification)のような情報整理が必要と思います(今後の課題)。

3.3.5 テストチャータ

3.3.5.1 観点出し

　観点出しは、初めて探索的テストを実施するときに障壁になった点でした。(批判が多数ありましたが、)私の実例では、外部仕様書やマニュアルの項目から抽出し、実施前にテストの目的をメンバーと共有する形で運営しました。また、テスト分析の成果物やISO25010の製品品質モデルを参考にしてメンバーで観点を議論することも有用です。

3.3.5.1 抜けや漏れ

　探索的テストにおける網羅性は、議論になることがありますが、網羅することに専念すると重箱の隅に突くことになり、バグが見つからないことに至ります。探索的テスト実施時に抜けや漏れに気付いたら、テストチャータに追加や変更することが現実的な手段と思います。

　次回は、下記を予定しています。

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

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