Recommended
More Related Content
What's hot
What's hot (20)
Similar to マインドマップを使った 仕様分析＆テスト設計
Similar to マインドマップを使った 仕様分析＆テスト設計 (20)
More from Akira Ikeda
More from Akira Ikeda (20)
マインドマップを使った 仕様分析＆テスト設計
- 6. 6 皆さんどのようにテストケースを作っていますか？（上級者の場合） 上級者 仕様書 テストケース テストケースを書く前に，思考を発散させながら，かつＭＥＣＥを意識し て考える．なので，初級者に比較してテストケースの抜けが少なくなる！ また，弱点をつくようなテストケースが作成できる！ 分析/設計を行う どんな音？ 押し方は？ タイミング は？ 類似ソフト は？ ユーザは？ 昔どうしたん だっけ？ 上級者はテスト観点を発想/検討したうえで戦略的にテストケースを作成する ・テストを行うにあたって，テスト観点をしっかりと考える 「機能」「プラットホーム」「エンドユーザ」「ドメイン特性」「組織の ノウハウ」など ・テスト観点の階層や関連，組み合わせを考える ・不適切な仕様（仕様バグ）は摘出 → 設計部門に確認・修正依頼 ・テスト観点全体の構成を俯瞰して，重み付けや実行順番など考える などなど……
- 7. 7 実に多くを考えることが必要であるが… 考えるっていっても 頭の中だけじゃ 大 変 だよなー とりあえず，テス トケース表を使っ て考えようかな？ どうせ最終的には エクセルの表にな るわけだし～
- 12. 12 マインドマップとは？ •トニー・ブザンにより考え出された図解技法 − 脳の仕組みを取り入れたもの − 思考に沿って描いていく − 図を取り入れる − 自分の深層意識にアクセスする Wikipediaによる解説 表現したい概念の中心となるキーワードやイメージを図の中央に置き、 そこから放射状にキーワードやイメージを繋げていくことで、発想を延ば していく図解表現技法。 この方法によって複雑な概念もコンパクトに表現でき、非常に早く理解 できるとされ、注目され始めている。 人間の脳の意味ネットワークと呼ばれる意味記憶の構造によく適合して いるので、理解や記憶がしやすい。 また本来は紙とペンで描くものだが、コンピュータ上で描くための専用ソ フトウェアもいくつか存在する。
- 13. 13 マインドマップの特徴の一例 •マインドマップには以下のような様々な特徴がある − バードビュー •全体を俯瞰し易い − MECE（Mutually Exclusive and Collectively Exhaustive） •項目それぞれが重複することなく、全体集合として漏れがない − 学習が容易 •基本的なルールは単純で，紙とペンがあれば始められる − 半構造 •フリーなルールであるために，柔軟に構造を変更可能 − プレイバック効果 •あとで，「なぜそう考えたか」「何を描いたか」などを思い出しやすい − 発想力が刺激される •描いているうちに他の項目との関連などから新たな発想が生まれやすい •深層意識にアクセスし，情報を引き出す − 思考の流れが絵として表現される（見える化） •中心から外に対して思考が放射的に広がる これらの特徴を上手く生かそう♪
- 16. 16 「仕様分析」と「テスト設計」 仕様分析 テスト設計 テスト実装 テスト実行 仕様の理解・整 理・検討・テスト 観点の目付け テスト観点の発 想・検討・整理 テスト設計結果に 従ってテストケー ス作成（各種テス ト技法を利用） テストケースの作成 テストの実行 作業/概念で分ける ここにマインドマップ を使います 本日解説＆体験するのは この範囲です テスト実装により 作成されたテスト ケースを実行し， ログを取る
- 18. 18 仕様分析の作業と勘所（1） •設計仕様の理解・整理・検討 − 知らないものはテストできない！ − 設計仕様に関する思想や意図、構造や構成物を理解する •どういったものを作ろうとしているかのイメージをつかむ − 例えば、作ろうとしているのは鉄製の一人乗りブランコなのに、木製のかご型ブラ ンコのテストを考えても無駄 − 設計者が特に重要と考える部分は、テストでも重要度が高いことがほとんど − 顧客先でどのように利用されるのか •テストのおおまかな戦略の方向性やテストアイテムの認識 •品質目標の認識 •テスト設計の手がかりを作る − テストすべき“要求”や“要件”、“仕様”や“機能” − ソフトウェアのウィークポイントの目付け − 過去のテストの経験から、ひっかかるところ − バグの気配を感じるところ − その他の疑問点 •疑問が生じる箇所は仕様がこなれていない可能性がある 仕様分 析 テスト設計 テスト実装
- 19. 19 仕様分析の作業と勘所（2） •仕様の洩れ抜けの発見と修正へのアクション − 設計仕様の品質向上は、テストベースの品質向上 •仕様は、テストにおける“要求”のようなものである •設計工程では顧客要求は“曖昧、抜け、漏れがある“という前提で検討する •テストにおいても、仕様書を同様の前提で検討する必要がある − 仕様書は多くの場合テストケースの作成を目的としたドキュメントではないから − 仕様上の欠陥を発見したら、設計部門にフィードバックし、仕様（テスト における要求）の高品質化をはかる •仕様書の高品質化は即ちテストベースの高品質化であり、そこから生み出され るテスト設計仕様やテストケースの高品質化に寄与する − 良い仕様書からは、良いコードと良いテストケースが生まれる •テスト戦略へのフィードバック − 分析結果の情報をテストの戦略や計画に反映 仕様分 析 テスト設計 テスト実装 仕様が理解できなかったり洩れ抜けが多い場合、設計部門に見直しを要請する 仕様分析の作業はある意味においてテストの立場からのレビュー行為でもある どれだけ正しい仕様を深く理解できるかが良いテスト設計への鍵
- 20. 20 テスト設計の作業と勘所（1） •テスト観点の発想 − 「なにをテストしよう」「どうテストしよう」が思いつかないと話が始ま らない •仕様書の分析結果や過去の経験、組織ノウハウから •テストカテゴリの利用 − Myersの14のシステムテスト・カテゴリ • ボリューム、ストレス、効率、ストレージ、信頼性、構成、互換性、設置、回復、操作性、 セキュリティ、サービス性、文書、手続き − ISO/IEC 9126の品質特性 • 機能性、信頼性、使用性、効率性、保守性、移植性 •テスト設計を進めるなかで得られる新たな発想 テスト設 計 仕様分析 テスト実装 おさらい：テストの「観点」とはなんだろう？ テスト対象の持つ、テストすべき側面 テスト対象が達成すべき性質 テスト対象（及び含む世界）を、テストの立場からモデリングしたもの テストする必要が無い側面は、モデリングする必要が無い 達成する必要が無い性質は、モデリングする必要が無い 抽象的で、階層構造を持つ
- 21. 21 テスト設計の作業と勘所（2） •テスト観点の剪定 − テスト観点には重要度や優先度が存在する •全てのテストは多くの場合やりきれないため、テスト観点に優先度をつける − 一歩進めて、リスクベースドテスト（戦略）的に考えても良い •テストする必要のない観点や優先度・重要度の低い観点は切り落とす − 切り落としたテスト観点とその情報は記録に残しておくこと •「なぜ切り落としたのか」の理由も合わせて記録しておく •テスト観点の整理 − 無秩序に発想したテスト観点を整える •観点の階層や観点間の関連を検討する •テスト戦略へのフィードバック − テスト設計結果の情報をテストの戦略や計画に反映 テスト設 計 仕様分析 テスト実装 ここでどれだけテスト観点を発想できるかがテスト設計の鍵 しかし，テスト観点をただ洗い出すだけでは不十分 テスト観点の剪定を行い階層や関連関係を整理する
- 22. 22 （ご参考）テスト実装の作業と勘所 •テスト設計結果に基づいてテストケースを作成 − 各種テスト技法を活用し、具体的なパラメータを決める •テスト設計では中か小項目くらいまでを決めるイメージ （テストケースフォーマットが大・中・小項目・テストケースである場合） •テスト観点間の組み合わせを考えたテストケース作り − 例えば、CPUとメモリの構成と負荷パタンの組み合わせ − そのほか直交表における因子など •テスト観点の重要度を意識する − 重要度が高い観点は、テストケースも増やす必要がある − テストケースのレビュー重要度も変える •テスト観点や関連の漏れがないか考える − テストケースとして実装する最中にひらめくことがある テスト実 装 仕様分析 テスト設計 テスト観点モデルに従って、すんなりとテストケースが作られることが理想 作りにくかったり、テスト観点の漏れが多い場合、テスト設計を見直す
- 25. 25 分析と設計は一緒に考えたほうが良い •意識的に仕様の分析とテスト設計は分けにくい − 作業時の思考は，それほど綺麗に分けられない •テスト設計をしていたら、いつの間にか分析を行っていた •分析していたのに、いつの間にかテスト設計視点で考えていた •設計していたら分析が甘いことに気がついた − そのため工程を厳密に区切ると、工程終了レビューの回数が増え、工数が 増えていく（つまり手戻りの増加） − 仕様分析とテスト設計とで作業上の責務は分けるが、両方同時に考えたほ うがボトルネックが小さくなる 仕様分析 テスト設計 テスト実装 実際に作業を行うと，分析と設計は 行ったりきたりする レ ビ ュ ー レ ビ ュ ー
- 26. 26 マインドマップ適用の基本的な作業手順と範囲 テスト設計 テストベース （仕様書） テストケース Mind Map 直接転記 しない テスト実装 仕様分析も マインドマップで考える 仕様分析
- 27. 27 （ちょいコツ）仕様分析には３色ボールペンも活用しよう！ •仕様分析をマインドマップだけで行うのはかなり大変 − セントラルイメージやメインブランチがなかなか決まらない •まず仕様書を３色ボールペンでチェックし，マインドマッ プを描く手がかりとする − 赤：客観的に「重要」な箇所 − 青：客観的に「まあまあ重要」な箇所 − 緑：主観的に「気になる」箇所 •チェックしている時点で，仕様の洩れや抜け， 間違いに気がつくことも多い − マインドマップを描く前に，テストベースの 品質向上できる − 仕様分析するに値する品質となっているかの チェックとしてもいいだろう
- 30. 30 マインドマップを描く際に意識すべき3つのポイント あ わ せ て ， 前 述 の 勘 所 と マ イ ン ド マ ッ プ の 特 性 を 上 手 く 生 か す 1. 仕様の把握と疑問点の洗い出し ・ 仕様の学習 ・ ウィークポイントの目付け ・ 疑問点の洗い出し 2. 発散思考の活用によるテスト観点の洗い出し ・ 少しでも多くの観点を挙げる ・ 挙がらなかったテスト観点に関するテストケースが 抜ける ・ 途中立ち止まって，自分に突っ込みを入れる ・ 「それだけ？」「そこ？」「まだあるやろ？」 ・ ブランチが伸びてないところは要注意 3. 洗い出されたテスト観点を整理する ・ テスト観点の階層関係 ・ テスト観点の重要度，優先度 ・ テスト観点間の関係
- 31. 31 テスト設計にマインドマップを使う上での注意点 • マインドマップは思考の発散に重きをおいたツール − 発散と収束をひとつのマップで行ってもいいが，発散のマップと収束のマップはわ けて作成することをオススメ • 収束のマップはNGTなど他の記法を使っても良い • マインドマップ→NGT，マインドマップ→FV表，などなど • 思考を際限なく発散させない − 無秩序に発散させていくと巨大なマインドマップができあがる − どこかで立ち止まって見直す必要あり • マインドマップは客観的には描かれない − 完成したマインドマップの内容は、他の人とは確実に異なる − 他の人のマインドマップを馬鹿にしない（人格否定に受け取られる） • マインドマップに正解はない • マインドマップを描くことを目的化しない − 綺麗な絵がかけても気づきがなければ意味が無い • 他の記法と連携させる − マインドマップの中に他の図表を“絵”として埋め込む • デシジョンテーブルや状態遷移図・表など − これらは絵とみなすことができる
- 32. 32 参考文献 • マインドマップ − トニーブザン：『ザ・マインドマップ』，ダイヤモンド社，2005 • 3色ボールペン − 斎藤孝：『3色ボールペンで読む日本語』，角川書店，2002 • ソフトウェアテスト with マインドマップ − Akira Ikeda：『Using MindMap for Software Testing Activities」，2008 The 1st Tianjin International Conference on Software Testing（Tianjin，China）， 2008 − Micky Suzuki，Akira Ikeda,：『Using MindMap for Software Testing Activities」，2007 ASTA International Software testing conference（Seoul， Korea），2008 − 池田暁，鈴木三紀夫：『マインドマップから始めるソフトウェアテスト』，技術評 論社，2007 − 池田暁，鈴木三紀夫：『マインドマップから始めるテスト設計 実況セミナー』，ソ フトウェアテストPRESS vol.5，技術評論社，2007 − 池田暁，鈴木三紀夫：『マインドマップから始めるテストケース設計』，ソフト ウェアテストPRESS vol.4，技術評論社，2007 − 池田暁，鈴木三紀夫：『マインドマップから始めるテスト設計』，ソフトウェアテ ストPRESS vol.3，技術評論社，2006 − 池田暁，鈴木三紀夫：『3色ボールペンとマインドマップの活用』講演資料， JaSST’06 Osaka，2007