ソフトウェアテストを助ける発想支援ツール

SWEST9での講演資料。
http://swest.toppers.jp/SWEST9/report.html

Transcript

1. © Akira Ikeda SWEST9 ソフトウェアテストを助ける 発想支援ツール 池田 暁
2. © Akira Ikeda SWEST9 2 普段テストをどのように行っていますか？ • テストは頭を使う作業である – テストベースは設計者が検討を重ね作りこまれた仕様書など – 静的テストでは，作り込まれた仕様書をテスト対象とする – 静的テストを合格したテストベースをもとに，実現されたソフトウェアのどこ にバグが潜んでいるかを考える • テスト初心者にありがちなケース – 仕様書から直接Excelシートの表にテストケースを書く • 多くの場合、文言の変換しか行われない • 転記作業に陥り，仕様書の内容を吟味しない • 表を埋めるために，適当に数値を変えて水増し（境界値テストの意識なし） • ベテランはどうしているか – 仕様書を分析し，最適なテスト戦略を考え，最終的にテストケースに落とし 込む – この際，過去の経験の再利用や，網羅性の確保と観点の抜けの防止の努 力をする テストはいかに深く考え，多くの発想を得るかが勝負である
3. © Akira Ikeda SWEST9 3 テストには，より高い発想力・想像力が必要 • テストの作業は次のように進められる – 仕様分析 • 仕様書等のテストベースを分析する • 実施すべきテストの種類，テストの終了/判断基準，人員/環境など – テスト計画 • 仕様分析での情報を，具体的な計画に起こしていく – テスト設計 • テストの計画にしたがって，テスト項目に作成する – テスト実装 • テスト設計にしたがって，テストケースを作成する – テスト実行 • テストケースを実際に実行し，テストログを作成するとともに，必要があればイ ンシデントレポートを発行し，管理する – テスト報告 • テストが終了したら，テストドキュメントをもとに報告書を作成し，報告を行う 各作業品質の向上には，より高い発想力・想像力が必要
4. © Akira Ikeda SWEST9 4 発想支援ツールは何を使っていますか？ • ツールはたくさんあるけれど – 石川ダイアグラム • どちらかというと情報の分析や整理？ • 不良やその根本原因の分析に有効だろう – 系統図 • これも石川ダイアグラムと同様，どちらかというと分析や整理だろう – マンダラート • ３＊３のマトリクスを埋めていく • マスが空いていると気持ち悪いから，なんとしても埋めたくなる（発想を促す） – マインドマップ • 思考を描きとめ，全体を俯瞰できることで，新たな気付きや発想を促す • あらゆる可能性を考えなければならないテストと相性が良い – 他にも，付箋紙とかいろいろ 不良の分析はQC七つ道具などを活用すればよいが， テスト設計や戦略の検討にはマンダラートやマインドマップが有効
5. © Akira Ikeda SWEST9 5 テストとマインドマップのちょっとイイ関係 • マインドマップを使うメリットを3つほど挙げてみる – 一覧性，バードビューという特性が，網羅性の検討を支援する • テストは常に“網羅”を意識する →ドキュメントに関する網羅，コードに関する網羅，機能に対する網羅，要求 に対する網羅，それぞれの組み合わせにおける網羅etc… – マインドマップに描かれたキーワードから新たな発想や気付きを得られる • キーワード間の関連に気がつきやすい →関連を見つけ出すことで，さらなる関連や新たな観点を獲得できる • 本来描かれるはずであるキーワードが無いことに気がつく →これが仕様や観点の“抜け”であることが多い – 自然と情報が整理されていく（本当に必要な情報のみが抽出できる） • 紙のスペース上，自然とキーワード，しかも重要なものが描かれていく • また，描く際にそのキーワードが本当に必要なのか自然と検討している マインドマップは、テストに対し様々な発想支援を行う （ある種のモデリングツールとして機能する）
6. © Akira Ikeda SWEST9 6 自由記述かテンプレートか • マインドマップには利用スタイルがある – 自由記述型 • ルール無しに自由に描いていく • ひたすら思考を発散させながら思いつくままに描いていく – ブレーンストーミング向き – 探索型テスティング向き • 抽象レベルを特に意識しなくても良い（いくらでも詳細化できる） • 発散した思考は，別プロセスで収束させる必要がある – テンプレート型 • メイン・ブランチ，ブランチのひな形を使う • ゆるやかなルールが存在していることが多い – 情報の分析や整理に使われることが多い（系統図っぽく使われる） – カテゴリ型テスト向き（ISO9126品質特性など） • 抽象レベルが固定されることが多い • 思考がテンプレートに縛られるため，自由記述型に比べて発想力は落ちる 何をどう検討するかで，スタイルを選択する
7. © Akira Ikeda SWEST9 7 マインドマップを使う上での注意 • 思考を際限なく発散させない – 無秩序に発散させていくと巨大なマインドマップができあがる – どこかで立ち止まって見直す必要あり • マインドマップは客観的には描かれない – 完成したマインドマップの内容は，他の人とは確実に異なる – 他の人のマインドマップを馬鹿にしない（人格否定に受け取られる） • マインドマップに正解はない • マインドマップを描くことを目的化しない – 綺麗な絵がかけても気づきがなければ意味が無い – 汚くても沢山の気づきが描かれているほうが良い ツールは使いよう マインドマップを上手に描けることと，テストをうまくやれることは違う
8. © Akira Ikeda SWEST9 8 まとめ１ テストには発想力が必要 • テスト設計は発想力・想像力が必要である – したがって，発想力・想像力を刺激するツールの活用は重要 • マインドマップ，マンダラート，などなど • ソフトウェアテストは実行だけじゃない – 実行前と実行後に行うべき作業がある – 装備やルートの確認を行わないままに登山するようなものだ →遭難してあたりまえ，遭難しないように事前にしっかりと戦略を立てる – うまく実行するために，すべての可能性を考え，漏れがないように準備を行う →漏れの防止にマインドマップが有効 • マインドマップには利用スタイルがある – 自由記述型かテンプレート型か – 発想を得たいのか，物事をまとめたいのか – 手書きかツールか – 自分のみが見るのか，誰かと共有するのか テストは発想力が必要とされ，発想力を促進するために マインドマップを発想支援ツールとして使う
9. © Akira Ikeda SWEST9 9 まとめ２ テスト・モデリングを意識する • マインドマップを使うことはテスト・モデリングをおこなっているようなもの – コーディングの前にはUML，フローチャート，PADなどを使ってモデリングしている • これがちゃんとやられていなければ，質の悪いコードができあがる – テストも，テストケースを書く前にしっかりとモデリングする必要がある • モデリングされずに作成されたテストケースの質ははたして？ • マインドマップをモデリングツールとして利用する • 他の記法と連携させる – 他の記法を組み合わせても良い • マインドマップの中に他の図を埋め込む • デシジョンテーブルや状態遷移図・表など – 他の記法の前処理に使う • マインドマップでテスト観点を洗い出し（発散），NGTに落とし込む（収束）のもいいだろう • レビューにも生かす – 自分の考え，他人の考えを可視化することで，レビュー品質が向上する • 適切な指摘が可能に，また，部下の指導ツールとしてもいいだろう 発想支援ツールとしてだけではなく，テスト・モデリングの １ツールとして意識することで，より高レベルのテスト設計が行える
10. © Akira Ikeda SWEST9 ご静聴ありがとうございました 是非，テスト設計に マインドマップを使ってみてください！