1

マインドマップを使った 仕様分析＆テスト設計

JaSST’08 Kyushu

2008年11月7日

池田 暁

2

ワークショップのはじめに

本日，皆さんには

沢山手を動かしていただきます

まず最初に簡単な

チュートリアルを行います

そして，最後に

発表していただきます！

次に演習（個人・グループ）です

3

本日のお品書き（前半）：チュートリアル

4

本日のお品書き（前半）：チュートリアル

その前に…

5

皆さんどのようにテストケースを作っていますか？（初級者の場合）

仕様書 テストケース

初級者

(仕様例)

ボタンを押すと音が出る

(テストケース例)

ボタンを押すと音が出ることを確認

初級者の悩み

・テストケースのヌケが多い！

・異常系のテストケースが抜ける！

・機能を組み合せを考慮したテストケースがかけない！

・テスト技法の使いどころがわからない！

・組織で積み上げられたノウハウが活用できない！

・自分の経験が再利用できない！

などなど……

ほぼ，転記

語尾を付け足して

完成させる…

6

皆さんどのようにテストケースを作っていますか？（上級者の場合）

上級者

仕様書 テストケース

テストケースを書く前に，思考を発散させながら，かつＭＥＣＥを意識して考える．なので，初級者に比較してテストケースの抜けが少なくなる！

また，弱点をつくようなテストケースが作成できる！

分析/設計を行う

どんな音？ 押し方は？

タイミングは？

類似ソフトは？

ユーザは？

昔どうしたん

だっけ？

上級者はテスト観点を発想/検討したうえで戦略的にテストケースを作成する

・テストを行うにあたって，テスト観点をしっかりと考える

「機能」「プラットホーム」「エンドユーザ」「ドメイン特性」「組織の ノウハウ」など

・テスト観点の階層や関連，組み合わせを考える

・不適切な仕様（仕様バグ）は摘出 → 設計部門に確認・修正依頼

・テスト観点全体の構成を俯瞰して，重み付けや実行順番など考える

などなど……

7

実に多くを考えることが必要であるが…

考えるっていっても

頭の中だけじゃ

大 変 だよなー

とりあえず，テストケース表を使って考えようかな？

どうせ最終的にはエクセルの表になるわけだし～

8

では，どういった記法（ツール）がいいのだろうか？

表で観点を出す，

つまりブレストは

難しいな～

じゃぁ，そのような特徴をもつ発想支援ツール，

マインドマップを

使ってみたら？

試行錯誤できる

記法がいいな

整理するためには

全体を俯瞰

できなくちゃ できれば構造化

しやすいものが

いいかも

でも，発想力を刺激してくれるものでないと，

観点が抜けちゃう！

9

マインドマップの利用イメージ（コンセプト）

仕様書 テストケース

初級者

上級者と同じレベルの思考はできないが，「考える」行為を明確に実行できる！（もちろんマインドマップの効果で発想力もアップ）

これにより，単なる転記から脱却でき，テストケースの品質も向上する！

上級者

仕様書 テストケース

考えを見える化することで，分析＆設計という行為をより高度化する！

また，発散思考を利用して思考をブーストする！

さらに，マインドマップをテスト観点の構造化ツールとして使うことで，

テストのアーキテクチャを検討し，より戦略的なテストを行う！

マインドマップを描く

もっともっと考える

10

つまり，考える道具としてマインドマップを活用する

テストケースの品質に大きな影響を与え，

かつ，発散思考が特に重要な

・仕様分析

・テスト設計

にマインドマップを使ってみようというコンセプトです（テスト実装は範囲外）

前半のチュートリアルでは

・マインドマップの概要

・マインドマップの適用を見据えた

仕様分析＆テスト設計の作業と勘所

・マインドマップを使った作業手順

を説明します

11

本日のお品書き（前半）：チュートリアル

12

マインドマップとは？

•トニー・ブザンにより考え出された図解技法

− 脳の仕組みを取り入れたもの

− 思考に沿って描いていく

− 図を取り入れる

− 自分の深層意識にアクセスする

Wikipediaによる解説

表現したい概念の中心となるキーワードやイメージを図の中央に置き、そこから放射状にキーワードやイメージを繋げていくことで、発想を延ばしていく図解表現技法。

この方法によって複雑な概念もコンパクトに表現でき、非常に早く理解できるとされ、注目され始めている。

人間の脳の意味ネットワークと呼ばれる意味記憶の構造によく適合しているので、理解や記憶がしやすい。

また本来は紙とペンで描くものだが、コンピュータ上で描くための専用ソフトウェアもいくつか存在する。

13

マインドマップの特徴の一例

•マインドマップには以下のような様々な特徴がある − バードビュー

•全体を俯瞰し易い

− MECE（Mutually Exclusive and Collectively Exhaustive） •項目それぞれが重複することなく、全体集合として漏れがない

− 学習が容易 •基本的なルールは単純で，紙とペンがあれば始められる

− 半構造 •フリーなルールであるために，柔軟に構造を変更可能

− プレイバック効果 •あとで，「なぜそう考えたか」「何を描いたか」などを思い出しやすい

− 発想力が刺激される •描いているうちに他の項目との関連などから新たな発想が生まれやすい

•深層意識にアクセスし，情報を引き出す

− 思考の流れが絵として表現される（見える化） •中心から外に対して思考が放射的に広がる

これらの特徴を上手く生かそう♪

14

デモ：マインドマップで自己紹介ネタを作ってみよう！

15

本日のお品書き（前半）：チュートリアル

済

16

「仕様分析」と「テスト設計」

仕様分析 テスト設計 テスト実装 テスト実行

仕様の理解・整理・検討・テスト観点の目付け

テスト観点の発想・検討・整理

テスト設計結果に従ってテストケース作成（各種テスト技法を利用）

テストケースの作成 テストの実行

作業/概念で分ける

ここにマインドマップを使います

本日解説＆体験するのは

この範囲です

テスト実装により作成されたテストケースを実行し，ログを取る

17

ソフトウェア開発 テスト開発

開発作業とテスト作業のおおまかな対比イメージ

要求分析

設計

実装

仕様分析

テスト設計

テスト実装

顧客要求を分析し、ソフトウェアとして実現可能か検討する

分析結果に基づいて、設計モデルの作成や仕様の決定を行う

モデルや仕様に基づいて、プログラム言語を使ってプログラムコードとして実装する

テストベースを分析し、どのようなテストが実現可能か検討する

分析結果に基づいて、テスト観点モデルの作成やテスト設計仕様を決定する

モデルやテスト仕様に基づいて、テスト技法を使ってテストケースとして実装する

テスト実行

設計仕様書が主なテストベースとなる

プログラム テストケース

18

仕様分析の作業と勘所（1）

•設計仕様の理解・整理・検討

− 知らないものはテストできない！

− 設計仕様に関する思想や意図、構造や構成物を理解する

•どういったものを作ろうとしているかのイメージをつかむ

− 例えば、作ろうとしているのは鉄製の一人乗りブランコなのに、木製のかご型ブランコのテストを考えても無駄

− 設計者が特に重要と考える部分は、テストでも重要度が高いことがほとんど

− 顧客先でどのように利用されるのか

•テストのおおまかな戦略の方向性やテストアイテムの認識

•品質目標の認識

•テスト設計の手がかりを作る

− テストすべき“要求”や“要件”、“仕様”や“機能”

− ソフトウェアのウィークポイントの目付け

− 過去のテストの経験から、ひっかかるところ

− バグの気配を感じるところ

− その他の疑問点

•疑問が生じる箇所は仕様がこなれていない可能性がある

仕様分析

テスト設計 テスト実装

19

仕様分析の作業と勘所（2）

•仕様の洩れ抜けの発見と修正へのアクション

− 設計仕様の品質向上は、テストベースの品質向上

•仕様は、テストにおける“要求”のようなものである

•設計工程では顧客要求は“曖昧、抜け、漏れがある“という前提で検討する

•テストにおいても、仕様書を同様の前提で検討する必要がある

− 仕様書は多くの場合テストケースの作成を目的としたドキュメントではないから

− 仕様上の欠陥を発見したら、設計部門にフィードバックし、仕様（テストにおける要求）の高品質化をはかる

•仕様書の高品質化は即ちテストベースの高品質化であり、そこから生み出されるテスト設計仕様やテストケースの高品質化に寄与する

− 良い仕様書からは、良いコードと良いテストケースが生まれる

•テスト戦略へのフィードバック

− 分析結果の情報をテストの戦略や計画に反映

仕様分析

テスト設計 テスト実装

仕様が理解できなかったり洩れ抜けが多い場合、設計部門に見直しを要請する

仕様分析の作業はある意味においてテストの立場からのレビュー行為でもある

どれだけ正しい仕様を深く理解できるかが良いテスト設計への鍵

20

テスト設計の作業と勘所（1）

•テスト観点の発想

− 「なにをテストしよう」「どうテストしよう」が思いつかないと話が始まらない

•仕様書の分析結果や過去の経験、組織ノウハウから

•テストカテゴリの利用

− Myersの14のシステムテスト・カテゴリ

• ボリューム、ストレス、効率、ストレージ、信頼性、構成、互換性、設置、回復、操作性、セキュリティ、サービス性、文書、手続き

− ISO/IEC 9126の品質特性

• 機能性、信頼性、使用性、効率性、保守性、移植性

•テスト設計を進めるなかで得られる新たな発想

テスト設計

仕様分析 テスト実装

おさらい：テストの「観点」とはなんだろう？

テスト対象の持つ、テストすべき側面

テスト対象が達成すべき性質

テスト対象（及び含む世界）を、テストの立場からモデリングしたもの

テストする必要が無い側面は、モデリングする必要が無い

達成する必要が無い性質は、モデリングする必要が無い

抽象的で、階層構造を持つ

21

テスト設計の作業と勘所（2）

•テスト観点の剪定

− テスト観点には重要度や優先度が存在する

•全てのテストは多くの場合やりきれないため、テスト観点に優先度をつける

− 一歩進めて、リスクベースドテスト（戦略）的に考えても良い

•テストする必要のない観点や優先度・重要度の低い観点は切り落とす

− 切り落としたテスト観点とその情報は記録に残しておくこと

•「なぜ切り落としたのか」の理由も合わせて記録しておく

•テスト観点の整理

− 無秩序に発想したテスト観点を整える

•観点の階層や観点間の関連を検討する

•テスト戦略へのフィードバック

− テスト設計結果の情報をテストの戦略や計画に反映

テスト設計

仕様分析 テスト実装

ここでどれだけテスト観点を発想できるかがテスト設計の鍵

しかし，テスト観点をただ洗い出すだけでは不十分

テスト観点の剪定を行い階層や関連関係を整理する

22

（ご参考）テスト実装の作業と勘所

•テスト設計結果に基づいてテストケースを作成

− 各種テスト技法を活用し、具体的なパラメータを決める

•テスト設計では中か小項目くらいまでを決めるイメージ （テストケースフォーマットが大・中・小項目・テストケースである場合）

•テスト観点間の組み合わせを考えたテストケース作り

− 例えば、CPUとメモリの構成と負荷パタンの組み合わせ

− そのほか直交表における因子など

•テスト観点の重要度を意識する

− 重要度が高い観点は、テストケースも増やす必要がある

− テストケースのレビュー重要度も変える

•テスト観点や関連の漏れがないか考える

− テストケースとして実装する最中にひらめくことがある

テスト実装

仕様分析 テスト設計

テスト観点モデルに従って、すんなりとテストケースが作られることが理想

作りにくかったり、テスト観点の漏れが多い場合、テスト設計を見直す

23

本日のお品書き（前半）：チュートリアル

済 済

24

マインドマップ適用時の基本的な作業手順と範囲

テスト設計 テストベース

（仕様書）

テストケース

Mind Map

直接転記しない

テスト実装

テスト設計に マインドマップを適用する

マインドマップではなく、 各種テスト技法を活用する

分析と設計の成果物として マインドマップが作成される

仕様分析

25

分析と設計は一緒に考えたほうが良い

•意識的に仕様の分析とテスト設計は分けにくい

− 作業時の思考は，それほど綺麗に分けられない

•テスト設計をしていたら、いつの間にか分析を行っていた

•分析していたのに、いつの間にかテスト設計視点で考えていた

•設計していたら分析が甘いことに気がついた

− そのため工程を厳密に区切ると、工程終了レビューの回数が増え、工数が増えていく（つまり手戻りの増加）

− 仕様分析とテスト設計とで作業上の責務は分けるが、両方同時に考えたほうがボトルネックが小さくなる

仕様分析 テスト設計 テスト実装

実際に作業を行うと，分析と設計は

行ったりきたりする

レビュー

レビュー

26

マインドマップ適用の基本的な作業手順と範囲

テスト設計 テストベース

（仕様書）

テストケース

Mind Map

直接転記しない

テスト実装

仕様分析も マインドマップで考える

仕様分析

27

（ちょいコツ）仕様分析には３色ボールペンも活用しよう！

•仕様分析をマインドマップだけで行うのはかなり大変

− セントラルイメージやメインブランチがなかなか決まらない

•まず仕様書を３色ボールペンでチェックし，マインドマッ

プを描く手がかりとする

− 赤：客観的に「重要」な箇所

− 青：客観的に「まあまあ重要」な箇所

− 緑：主観的に「気になる」箇所

•チェックしている時点で，仕様の洩れや抜け，

間違いに気がつくことも多い

− マインドマップを描く前に，テストベースの 品質向上できる

− 仕様分析するに値する品質となっているかの チェックとしてもいいだろう

28

仕様分析に３色ボールペンを使う

テスト設計 テストベース

（仕様書）

テストケース

Mind Map

直接転記しない

テスト実装

仕様分析

仕様分析に ３色ボールペンも使う

29

全体の作業イメージ

テスト設計 テストベース

（仕様書）

テストケース

Mind Map

テスト実装

仕様分析

仕様分析に ３色ボールペンも使う

仕様分析とテスト設計を マインドマップで考える

マインドマップではなく、 各種テスト技法を活用する

分析と設計の成果物として マインドマップが作成される

#あわせてチェックが入った

仕様書も作成される

30

マインドマップを描く際に意識すべき3つのポイント

あわせて，前述の勘所と

マインドマップの特性を上手く生かす

1. 仕様の把握と疑問点の洗い出し

・ 仕様の学習 ・ ウィークポイントの目付け ・ 疑問点の洗い出し

2. 発散思考の活用によるテスト観点の洗い出し

・ 少しでも多くの観点を挙げる ・ 挙がらなかったテスト観点に関するテストケースが 抜ける ・ 途中立ち止まって，自分に突っ込みを入れる ・ 「それだけ？」「そこ？」「まだあるやろ？」 ・ ブランチが伸びてないところは要注意

3. 洗い出されたテスト観点を整理する

・ テスト観点の階層関係 ・ テスト観点の重要度，優先度 ・ テスト観点間の関係

31

テスト設計にマインドマップを使う上での注意点

• マインドマップは思考の発散に重きをおいたツール

− 発散と収束をひとつのマップで行ってもいいが，発散のマップと収束のマップはわけて作成することをオススメ

• 収束のマップはNGTなど他の記法を使っても良い

• マインドマップ→NGT，マインドマップ→FV表，などなど

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

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

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

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

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

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

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

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

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

• 他の記法と連携させる

− マインドマップの中に他の図表を“絵”として埋め込む

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

− これらは絵とみなすことができる

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