© Akira Ikeda SWEST9

ソフトウェアテストを助ける

発想支援ツール

池田 暁

© Akira Ikeda SWEST9 2

普段テストをどのように行っていますか？

• テストは頭を使う作業である – テストベースは設計者が検討を重ね作りこまれた仕様書など

– 静的テストでは，作り込まれた仕様書をテスト対象とする

– 静的テストを合格したテストベースをもとに，実現されたソフトウェアのどこにバグが潜んでいるかを考える

• テスト初心者にありがちなケース – 仕様書から直接Excelシートの表にテストケースを書く

• 多くの場合、文言の変換しか行われない

• 転記作業に陥り，仕様書の内容を吟味しない

• 表を埋めるために，適当に数値を変えて水増し（境界値テストの意識なし）

• ベテランはどうしているか

– 仕様書を分析し，最適なテスト戦略を考え，最終的にテストケースに落とし込む

– この際，過去の経験の再利用や，網羅性の確保と観点の抜けの防止の努力をする

テストはいかに深く考え，多くの発想を得るかが勝負である

© Akira Ikeda SWEST9 3

テストには，より高い発想力・想像力が必要

• テストの作業は次のように進められる

– 仕様分析

• 仕様書等のテストベースを分析する

• 実施すべきテストの種類，テストの終了/判断基準，人員/環境など

– テスト計画

• 仕様分析での情報を，具体的な計画に起こしていく

– テスト設計

• テストの計画にしたがって，テスト項目に作成する

– テスト実装

• テスト設計にしたがって，テストケースを作成する

– テスト実行

• テストケースを実際に実行し，テストログを作成するとともに，必要があればインシデントレポートを発行し，管理する

– テスト報告

• テストが終了したら，テストドキュメントをもとに報告書を作成し，報告を行う

各作業品質の向上には，より高い発想力・想像力が必要

© Akira Ikeda SWEST9 4

発想支援ツールは何を使っていますか？

• ツールはたくさんあるけれど

– 石川ダイアグラム

• どちらかというと情報の分析や整理？

• 不良やその根本原因の分析に有効だろう

– 系統図

• これも石川ダイアグラムと同様，どちらかというと分析や整理だろう

– マンダラート

• ３＊３のマトリクスを埋めていく

• マスが空いていると気持ち悪いから，なんとしても埋めたくなる（発想を促す）

– マインドマップ

• 思考を描きとめ，全体を俯瞰できることで，新たな気付きや発想を促す

• あらゆる可能性を考えなければならないテストと相性が良い

– 他にも，付箋紙とかいろいろ

不良の分析はQC七つ道具などを活用すればよいが，

テスト設計や戦略の検討にはマンダラートやマインドマップが有効

© Akira Ikeda SWEST9 5

テストとマインドマップのちょっとイイ関係

• マインドマップを使うメリットを3つほど挙げてみる

– 一覧性，バードビューという特性が，網羅性の検討を支援する

• テストは常に“網羅”を意識する

→ドキュメントに関する網羅，コードに関する網羅，機能に対する網羅，要求に対する網羅，それぞれの組み合わせにおける網羅etc…

– マインドマップに描かれたキーワードから新たな発想や気付きを得られる

• キーワード間の関連に気がつきやすい

→関連を見つけ出すことで，さらなる関連や新たな観点を獲得できる

• 本来描かれるはずであるキーワードが無いことに気がつく

→これが仕様や観点の“抜け”であることが多い

– 自然と情報が整理されていく（本当に必要な情報のみが抽出できる）

• 紙のスペース上，自然とキーワード，しかも重要なものが描かれていく

• また，描く際にそのキーワードが本当に必要なのか自然と検討している

マインドマップは、テストに対し様々な発想支援を行う

（ある種のモデリングツールとして機能する）

© Akira Ikeda SWEST9 6

自由記述かテンプレートか

• マインドマップには利用スタイルがある

– 自由記述型

• ルール無しに自由に描いていく

• ひたすら思考を発散させながら思いつくままに描いていく

– ブレーンストーミング向き

– 探索型テスティング向き

• 抽象レベルを特に意識しなくても良い（いくらでも詳細化できる）

• 発散した思考は，別プロセスで収束させる必要がある

– テンプレート型

• メイン・ブランチ，ブランチのひな形を使う

• ゆるやかなルールが存在していることが多い

– 情報の分析や整理に使われることが多い（系統図っぽく使われる）

– カテゴリ型テスト向き（ISO9126品質特性など）

• 抽象レベルが固定されることが多い

• 思考がテンプレートに縛られるため，自由記述型に比べて発想力は落ちる

何をどう検討するかで，スタイルを選択する

© Akira Ikeda SWEST9 7

マインドマップを使う上での注意

• 思考を際限なく発散させない

– 無秩序に発散させていくと巨大なマインドマップができあがる

– どこかで立ち止まって見直す必要あり

• マインドマップは客観的には描かれない

– 完成したマインドマップの内容は，他の人とは確実に異なる

– 他の人のマインドマップを馬鹿にしない（人格否定に受け取られる）

• マインドマップに正解はない

• マインドマップを描くことを目的化しない

– 綺麗な絵がかけても気づきがなければ意味が無い

– 汚くても沢山の気づきが描かれているほうが良い

ツールは使いよう

マインドマップを上手に描けることと，テストをうまくやれることは違う

© Akira Ikeda SWEST9 8

まとめ１ テストには発想力が必要

• テスト設計は発想力・想像力が必要である

– したがって，発想力・想像力を刺激するツールの活用は重要

• マインドマップ，マンダラート，などなど

• ソフトウェアテストは実行だけじゃない

– 実行前と実行後に行うべき作業がある

– 装備やルートの確認を行わないままに登山するようなものだ

→遭難してあたりまえ，遭難しないように事前にしっかりと戦略を立てる

– うまく実行するために，すべての可能性を考え，漏れがないように準備を行う

→漏れの防止にマインドマップが有効

• マインドマップには利用スタイルがある

– 自由記述型かテンプレート型か

– 発想を得たいのか，物事をまとめたいのか

– 手書きかツールか

– 自分のみが見るのか，誰かと共有するのか

テストは発想力が必要とされ，発想力を促進するために

マインドマップを発想支援ツールとして使う

© Akira Ikeda SWEST9 9

まとめ２ テスト・モデリングを意識する

• マインドマップを使うことはテスト・モデリングをおこなっているようなもの

– コーディングの前にはUML，フローチャート，PADなどを使ってモデリングしている

• これがちゃんとやられていなければ，質の悪いコードができあがる

– テストも，テストケースを書く前にしっかりとモデリングする必要がある

• モデリングされずに作成されたテストケースの質ははたして？

• マインドマップをモデリングツールとして利用する

• 他の記法と連携させる

– 他の記法を組み合わせても良い

• マインドマップの中に他の図を埋め込む

• デシジョンテーブルや状態遷移図・表など

– 他の記法の前処理に使う

• マインドマップでテスト観点を洗い出し（発散），NGTに落とし込む（収束）のもいいだろう

• レビューにも生かす

– 自分の考え，他人の考えを可視化することで，レビュー品質が向上する

• 適切な指摘が可能に，また，部下の指導ツールとしてもいいだろう

発想支援ツールとしてだけではなく，テスト・モデリングの

１ツールとして意識することで，より高レベルのテスト設計が行える

© Akira Ikeda SWEST9

ご静聴ありがとうございました

是非，テスト設計に

マインドマップを使ってみてください！