$30 off During Our Annual Pro Sale. View Details »

マインドマップで発想を広げてテストしよう /mm_and_testing

k.i.
July 27, 2020

マインドマップで発想を広げてテストしよう /mm_and_testing

ソフトウェアテストでのマインドマップの活用について思うところをまとめたものです。
他の図の話も少し。

ツール:Googleスライド(テーマ「コーラル」)、miro

k.i.

July 27, 2020
Tweet

More Decks by k.i.

Other Decks in Technology

Transcript

  1. マインドマップ
    で発想を広げて
    テストしよう
    2020年7⽉
    Kumiko Iseri

    View Slide

  2. 本書の想定読者&注意
    ● 想定読者は、ソフトウェアテストでマインドマップを使うことに興味が
    あるが、やり⽅がよくわからない⽅
    ● 本書でのマインドマップの定義は、ゆるふわ
    ○ 特定のルールに従わないとマインドマップと呼べないとも⾔われますが、
    本書はそのあたり、ゆるゆるです
    マインドマップは、Buzan Organisation Limitedの登録商標です。
    その他登場する会社名、製品名などは、⼀般に各社の登録商標または商標です。

    View Slide

  3. 良いテスト︖
    根拠を説明可能
    抜け漏れ少
    コスパ⾼

    View Slide

  4. 良いテスト︖
    気付き、発想
    根拠を説明可能
    抜け漏れ少
    コスパ⾼
    ドキュメントを眺める
    だけでは難しい

    View Slide

  5. 良いテスト︖
    マインドマップ
    気付き、発想
    根拠を説明可能
    抜け漏れ少
    コスパ⾼

    View Slide

  6. マインドマップとは
    このプレゼンの準備も
    マインドマップで⾏っています。
    本書内のマインドマップのキャプチャは
    「miro」で作成しました。
    https://miro.com/app/dashboard/

    View Slide

  7. マインドマップとは

    View Slide

  8. マインドマップの特徴
    アウトプットは、中⼼から四⽅⼋⽅にブランチ(枝)が伸びる図
    放射状

    View Slide

  9. マインドマップの特徴
    放射状
    中⼼にテ
    ーマ
    ブランチに
    単語
    多⾊、絵、
    記号
    直感的

    View Slide

  10. マインドマップとは

    View Slide

  11. なぜマインドマップ︖
    「記憶、創造性、学習の3分野でとくに⼤きな効果を発揮する」
    本「新版ザ・マインドマップ」を引⽤、参考にして作成
    ⾃⼰分析 スケジュール 議事録
    プレゼン ノート …

    View Slide

  12. マインドマップの書き⽅
    ❏ 1. 中央にテーマを書く(セントラル・イメージ)
    ❏ 2. セントラル・イメージからメインブランチを伸ばす
    ❏ 右上から、時計回り
    ❏ 3. メインブランチにキーワードやイメージを1つ書く
    ❏ 4. メインブランチから連想や発想したことがあれば、
    ブランチを伸ばしてキーワードやイメージを1つ書く
    ❏ 5. 更に連想や発想があれば、ブランチからブランチを伸ばして書く
    ❏ 6. 2-5を繰り返し、メインブランチやブランチを増やしていく
    ❏ 2-5の順序は問わない

    View Slide

  13. マインドマップの書き⽅
    ❏ 1. 中央にテーマを書く(セントラル・イメージ)

    View Slide

  14. マインドマップの書き⽅
    ❏ 2. セントラル・イメージからメインブランチを伸ばす
    ❏ 右上から、時計回り
    ❏ 3. メインブランチにキーワードやイメージを1つ書く

    View Slide

  15. マインドマップの書き⽅
    ❏ 4. メインブランチから連想や発想したことがあれば、
    ブランチを伸ばしてキーワードやイメージを1つ書く

    View Slide

  16. マインドマップの書き⽅
    ❏ 5. 更に連想や発想があれば、ブランチからブランチを伸ばして書く
    ❏ 6. 2-5を繰り返し、メインブランチやブランチを増やしていく
    ❏ 2-5の順序は問わない

    View Slide

  17. テストとマインドマップの例(再掲)

    View Slide

  18. ➢ 「無地の紙を使う」
    ➢ 「横⻑で使う」
    ➢ 「中⼼から描く」
    ➢ 「テーマはイメージで描く」
    ➢ 「1ブランチ=1ワード」
    ➢ 「ワードは単語で書く」
    ➢ 「ブランチは曲線で」
    ➢ 「強調する」
    ➢ 「関連付ける」
    ➢ 「独⾃のスタイルで」
    ➢ 「創造的に」
    ➢ 「楽しむ!」
    本「[改訂新版]マインドマップから始めるソフトウェアテスト」より
    マインドマップのルール

    View Slide

  19. マインドマップのガイドライン
    本「新版ザ・マインドマップ」を
    参考に作成

    View Slide

  20. テストでマインドマップを使う理由
    本「[改訂新版]マインドマップから始めるソフトウェアテスト」より
    『マインドマップは「考える」作業です。テストケース
    表を書く前にマインドマップを描くことによって、
    仕様書の中⾝を整理します。整理する作業の中で、
    さまざまな疑問や確認すべき点、記述漏れなどを発⾒
    することができます。』

    View Slide

  21. テスト計画の検討
    インシデントレポートの準備

    思考を発散させ様々な制約や可能性に⽬配りしたいとき
    まずは分析、設計がオススメ
    図は、 http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J02.pdf を参考に作成
    テストプロセスとマインドマップ
    計画 分析 設計 実装 実⾏ 完了

    View Slide

  22. 悩み1︓厳密に書くか︖
    ❖ 書くこと >>> ルール、ガイドラインを守ること
    ❖ 中⼼から、短い⾔葉で、⾊や記号などで強調ポイントがわかるように書く
    ➢ ツールの制約で無理なときは、できる範囲で
    ❖ 改善はルール、ガイドラインなどを参考に
    ❖ 参考︓本「[改訂新版]マインドマップから始めるソフトウェアテスト」で
    強調されているルール
    ➢ 「中⼼から描く」
    ➢ 「ワードは単語で書く」
    ➢ 「ブランチは曲線で」
    ➢ 「楽しむ︕」

    View Slide

  23. 悩み2︓(メイン)ブランチが思いつかない︖
    ❖ まず、わかっていることを書く
    ➢ 仕様→テスト条件
    ❖ 下調べをする
    ➢ ユーザの業務や慣れ具合
    ➢ 過去に出たバグ
    ➢ 既存システムの動き
    ➢ 要件・設計
    ❖ 既存のフレームワークや考え⽅を参考にする(諸刃の剣)
    ➢ テストタイプ、品質特性、…
    ➢ ○とりあえず書けるし、考慮漏れの予防になることも
    ➢ ×発想が固定化、定型化しやすい
    ➢ 取捨選択や、追加の検討を

    View Slide

  24. 悩み3︓1回で綺麗に書けない
    むしろ、どんどん試⾏錯誤する
    ❖ 実は、メインブランチ「操作」より「検索条件の保存」などを先に書いていた
    ❖ 実は、「添付ファイル」は他の「対象項⽬」より、ずっと後に追加

    View Slide

  25. テストでのマインドマップ ”私流” の書き⽅
    ★ ブランチが思いつかなかったら「起きそうだけど起きたら嫌なことは︖」
    ○ 具体的なバグ→メインブランチは後で
    ★ 書きながら、抽象化や関係性の⾒直し
    ○ 具体や細部は「つまり何︖」→親のブランチは後で
    ○ 親⼦、上下は随時⼊れ替え
    ○ ⼀時的な空⽩ブランチもあり
    ★ 1ブランチ⽬は、テストタイプやシステムの構造を切り⼝にすることが多い
    ★ 他⼈の⽬を使う
    ○ モブワーク、翌⽇の⾃分

    View Slide

  26. テストとマインドマップの位置付け
    中間成果物
    がオススメ
    思いついたこと何でも
    発散に集中→収束に集中
    キーワードだけにしやすい

    View Slide

  27. マインドマップだけ︖
    根拠を説明可能
    抜け漏れ少
    コスパ⾼
    図を書こう
    気付き、発想
    仕様、制約の理解

    View Slide

  28. ここでの「図」
    ↑不要なわけではないが意識せずとも
    テストで使う場⾯が多い
    ×
    ⽂章
    箇条書き


    図形や線
    事柄のほか関連も

    View Slide

  29. 図の効果
    関連から連想
    強調
    抽象的表現
    俯瞰
    端的な表現
    理解
    発想

    View Slide

  30. テストで活⽤を検討したい図、いろいろ
    図の分類は最も使いそうなところ(それ以外でも使えることがある)

    View Slide

  31. マインドマップは汎⽤的なのに、なぜ︖
    他の図はいらない︖
    いえいえ、汎⽤的でないから役⽴つ場⾯もある
    ➔ 制約に従うことで考慮漏れを防ぐ
    ◆ ステートマシン図を書くと、状態遷移する条件が気になってくる
    ➔ ⽬的に特化した記法、ルールのため⾒易い
    ◆ CFDなら、処理の流れと分岐ごとの期待結果を分かりやすく表現できる

    View Slide

  32. まとめ
    ● 良いテストのための発想に、マインドマップの活⽤を
    ○ まずはテスト分析、設計で使ってみては
    ● 慣れてきたら、発想と理解のサポートに他の図も活⽤を

    View Slide

  33. 参考⽂献
    いずれも本書執筆時点(2020/07/26)の情報
    マインドマップ
    ● [改訂新版]マインドマップから始めるソフトウェアテスト
    ○ 池⽥ 暁 (著), 鈴⽊ 三紀夫 (著),2019年,技術評論社
    ● 新版 ザ・マインドマップ(R)
    ○ トニー・ブザン (著), バリー・ブザン (著), 近⽥ 美季⼦ (翻訳),2013年,ダイヤモンド社
    ● https://ja.wikipedia.org/wiki/%E3%83%9E%E3%82%A4%E3%83%B3%E3%83%89%E3%83%9E%E3%83%83
    %E3%83%97
    マインドマップ以外の図
    ● UML https://www.itsenka.com/contents/development/uml/
    ● ラルフチャート http://www.jasst.jp/symposium/jasst18tohoku/pdf/S3-3-3.pdf
    ● NGT http://jasst.jp/archives/jasst06e/pdf/E2-3.pdf
    ● CFD http://softest.cocolog-nifty.com/blog/2011/04/cfd4-28d6.html

    View Slide