WACATE2014夏 夜の分科会 -探索的テスト分科会- (3)：「失敗した事」「ノウハウ -現場-」

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

議論内容：2.失敗した事

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

2.1 固定観念

2.2 探索範囲

2.3 スキル/知識

2.1 固定観念

　固定観念にとらわれると、探索範囲が狭くかつテスト条件の粒度が細かくなり、重箱の隅を突くようなテストに至ります。重箱の隅を突くようなテストは、バグ検出できる数が頭打ちになることがあります。セッションベーステストで時間的に区切りを付ける工夫が必要です。

2.2 探索範囲：環境、条件など

　テスト対象のドメイン知識が中途半端に理解しているとき、環境や条件などの絞り込みが的外れになり、先述の2.1のような現象が発生します。探索範囲が狭くならないよう、次の2.3の対策を実施する必要があります。

2.3 スキル/知識：ドメイン知識不足

　過去のプロジェクトですが、ドメイン知識を保有していないテスターが探索的テストを実施すると、バグ検出できないことが多々ありました。対策としては、プロジェクトのリソースによりますが、テスト対象のドメイン知識を持っている有識者を探索的テスト実施者としてアサインすることをお勧めします。

議論内容：3.1 ノウハウ -現場-

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

3.1.1 現象

3.1.2 蓄積

3.1.3 経験

3.1.1 現象

　現場で起きている切り口として、「人」「バグの質」「バグ再現」「バグ発見のきっかけ」の4種類に分類してみました。

3.1.1.1 人

3.1.1.1.1 特定の人

・特定のタイミング

　バグを検出したとき、バグ再現しようと試みると、特定の人が特定のタイミングで苦も無く、すぐにバグが再現できることが挙げられました。

　私の現場ではベテランエンジニアの方で顕著に現れていました。また、私自身が検出したバグは、他のメンバーでバグ再現しようと試みましたが、上手く再現できませんでした。私の経験では、タイミングは学習した結果でバグ再現できるか否か左右されました。

・バグ検出の偏り

　バグ検出の傾向は、各メンバーによってバグ検出内容の偏りがあることが挙げられました。過去の経験やスキル、得意なところや興味のあるところでバグ検出に偏りがあるようですが、バグ検出時の観点を細かく見てしまうことも一因です。

3.1.1.1.2 バグハンター：鋭い気付き

　前項の3.1.1.1.1にもありますが、鋭い気付きでバグ検出するバグハンターが存在することが挙げられました。

　時々ですが、私の現場で「どうやったら、マニアックなバグを検出できるのか？」とメンバーが驚くバグを見つける方がいました。メンバーの話によると、その方は2～3年の間、とある製品の設計者に従事し、他の設計者のモジュールを組み合わせてコンポーネント統合テストを行ったところ、「嫌な予感がする」が的中するバグを目の当たりにしたそうです。そこで、他の設計者が担当していたモジュールを意識してシステム統合テストを実施していました。

3.1.1.1.3 担当の経験

　メンバーは、様々な教育及び開発経験を経て、チームとして集結します。

　私の現場では、ベテランのメンバーは様々な場所で開発を経験、若手のメンバーは一人開発した経験があり、経験談を聞くと興味深い話があります。特に失敗した経験があると、バグ検出の感度が鋭くなる実感があったとの声もあり、失敗のメカニズムを考えてみるのも有用でした。

3.1.1.2 バグの質

3.1.1.2.1 『今さらバグ』

　テスト開始して間もない頃に実施したテストではOKだったが、終盤に差し掛かった時に開始後のテストで検出できるバグが何故か検出されることがあります。「デグレード」と呼ばれるバグですが、「テスト開始して間もない頃に実施したテスト」を探索的テストの目的として実施すると、今さら(出てきた)バグに遭遇するようです。

3.1.1.2.2 ゴメンナサイレベル

　何らかの手違いで発生したバグが時々あるようです。例えば、コーディング時に変数の初期化を忘れることなど。

3.1.1.2.3 やばいバグ

　「このバグが出てしまうと、機能しなくなる」と言いたくなるバグが事例として挙がりました。

3.1.1.3 バグ再現：難しいケース

　探索的テストを実施すると、偶然検出したバグを条件を把握した上で実施したところ、上手く再現できないバグが多々あります。同じような操作をしても、微妙なタイミングでバグが再現できないこともあります。GUIで動作するアプリケーションをテスト対象する場合、キー入力やマウス入力のログを取り、再現できるようにテスト環境を整備することをお勧めします。

3.1.1.4 バグ発見のきっかけ：ドメイン知識が無くてもバグ検出

　議論内容：「失敗した事」の"(3)スキル/知識：ドメイン知識不足"と逆ですが、ドメイン知識に左右されない基本的な知識を保有した上で、議論内容：「失敗した事」の"(1)固定観念"に至らないような工夫をしたものと解釈しました。

3.1.2 蓄積

3.1.2.1 共有する機会(朝礼など)

3.1.2.1.1 バグ情報

　バグ情報は、インシデントレポートやお客様からのクレーム報告(市場不具合)から入手し、「何故、○○のバグが報告されたのか？」「どのような条件でバグが発生しているか？」を『原因』→『結果』が見える形で分析する必要があります。まずは、1つのインシデントレポートをメンバーで一緒に見ながら、問題 vs 我々の構図で考えてみることから始めるとよいです。

3.1.2.1.2 開発失敗事例

　バグの再発防止を目的としたバグ発生事例発表で何が原因なのか議論し、内容をまとめておくと、テストチャータの材料として活用できます。

3.1.2.1.3 バグ再現

　バグ発生時、開発者にバグ状況を確認頂くためにバグ再現を行いますが、バグ発生までのふるまいを観察してパターン化すると、テストチャータの情報の1つとして有用です。

3.1.2.2 ベテラン：欠陥のパターンをよく知っている

　議論内容：「ノウハウ：現場」の"(1-1-3)担当の経験"と重複しますが、『失敗した経験』をいくつか経験すると、失敗の傾向が掴めるようになります。

3.1.3 経験則

3.1.3.1 ペアテスト

　テスト対象の知見や経験、内部構造を熟知したメンバーと共にペアテストを実施すると、一方がテスト対象を操作し、他方がテスト対象の出力データ(結果)をモニタリングすると、挙動の変化に鋭く気付くことがあるため、バグ検出が頭打ちになった場合にペアテストで試してみるとよいと思います。

3.1.3.2 テストの量が少ない割にバグが出る機能

　少数のテストを実施後に複数のバグを検出したため、インシデントレポートを書く羽目になった経験がありますが、「80%のバグが"20%のモジュール"に内在する」という経験則があります。"20%のモジュール"を特定するには、これまで挙がった内容から、使えそうなところを試すとよいと思います。

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

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

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