Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
マインドマップで発想を広げてテストしよう /mm_and_testing
Search
k.i.
July 27, 2020
Technology
3
2k
マインドマップで発想を広げてテストしよう /mm_and_testing
ソフトウェアテストでのマインドマップの活用について思うところをまとめたものです。
他の図の話も少し。
ツール:Googleスライド(テーマ「コーラル」)、miro
k.i.
July 27, 2020
Tweet
Share
More Decks by k.i.
See All by k.i.
テスト設計チュートリアル ちびこん編 ’25
omn
2
620
JaSST'24 Tohoku基調講演/jasst24tohoku_keynote
omn
4
2.3k
同値分割&境界値分析Ver.2
omn
2
500
defect_report
omn
0
170
良いテストは良いフィードバック/wacate2020w
omn
1
1.8k
テスト観点を うまく議論し使い回すために できることを考える [公開用] / NagasakiQDG4th-Test-viewpoints
omn
1
3.1k
jasst18kyushu_workshop
omn
2
300
use-case-testing2016s
omn
0
170
Other Decks in Technology
See All in Technology
2025新卒研修・HTML/CSS #弁護士ドットコム
bengo4com
3
13k
Amazon Qで2Dゲームを作成してみた
siromi
0
110
データ基盤の管理者からGoogle Cloud全体の管理者になっていた話
zozotech
PRO
0
350
AWS DDoS攻撃防御の最前線
ryutakondo
1
130
o11yツールを乗り換えた話
tak0x00
1
310
帳票構造化タスクにおけるLLMファインチューニングの性能評価
yosukeyoshida
1
230
OPENLOGI Company Profile for engineer
hr01
1
37k
dipにおけるSRE変革の軌跡
dip_tech
PRO
1
230
製造業の課題解決に向けた機械学習の活用と、製造業特化LLM開発への挑戦
knt44kw
0
160
AIエージェントを現場で使う / 2025.08.07 著者陣に聞く!現場で活用するためのAIエージェント実践入門(Findyランチセッション)
smiyawaki0820
6
690
Amazon Bedrock AgentCoreのフロントエンドを探す旅 (Next.js編)
kmiya84377
1
120
LIFF CLIとngrokを使ったLIFF/LINEミニアプリのお手軽実機確認
diggymo
0
230
Featured
See All Featured
Optimizing for Happiness
mojombo
379
70k
The Invisible Side of Design
smashingmag
301
51k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
A Modern Web Designer's Workflow
chriscoyier
695
190k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.6k
Six Lessons from altMBA
skipperchong
28
3.9k
For a Future-Friendly Web
brad_frost
179
9.9k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
880
How GitHub (no longer) Works
holman
314
140k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
3.1k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
182
54k
Designing for Performance
lara
610
69k
Transcript
マインドマップ で発想を広げて テストしよう 2020年7⽉ Kumiko Iseri
本書の想定読者&注意 • 想定読者は、ソフトウェアテストでマインドマップを使うことに興味が あるが、やり⽅がよくわからない⽅ • 本書でのマインドマップの定義は、ゆるふわ ◦ 特定のルールに従わないとマインドマップと呼べないとも⾔われますが、 本書はそのあたり、ゆるゆるです マインドマップは、Buzan
Organisation Limitedの登録商標です。 その他登場する会社名、製品名などは、⼀般に各社の登録商標または商標です。
良いテスト︖ 根拠を説明可能 抜け漏れ少 コスパ⾼
良いテスト︖ 気付き、発想 根拠を説明可能 抜け漏れ少 コスパ⾼ ドキュメントを眺める だけでは難しい
良いテスト︖ マインドマップ 気付き、発想 根拠を説明可能 抜け漏れ少 コスパ⾼
マインドマップとは このプレゼンの準備も マインドマップで⾏っています。 本書内のマインドマップのキャプチャは 「miro」で作成しました。 https://miro.com/app/dashboard/
マインドマップとは
マインドマップの特徴 アウトプットは、中⼼から四⽅⼋⽅にブランチ(枝)が伸びる図 放射状
マインドマップの特徴 放射状 中⼼にテ ーマ ブランチに 単語 多⾊、絵、 記号 直感的
マインドマップとは
なぜマインドマップ︖ 「記憶、創造性、学習の3分野でとくに⼤きな効果を発揮する」 本「新版ザ・マインドマップ」を引⽤、参考にして作成 ⾃⼰分析 スケジュール 議事録 プレゼン ノート …
マインドマップの書き⽅ ❏ 1. 中央にテーマを書く(セントラル・イメージ) ❏ 2. セントラル・イメージからメインブランチを伸ばす ❏ 右上から、時計回り ❏
3. メインブランチにキーワードやイメージを1つ書く ❏ 4. メインブランチから連想や発想したことがあれば、 ブランチを伸ばしてキーワードやイメージを1つ書く ❏ 5. 更に連想や発想があれば、ブランチからブランチを伸ばして書く ❏ 6. 2-5を繰り返し、メインブランチやブランチを増やしていく ❏ 2-5の順序は問わない
マインドマップの書き⽅ ❏ 1. 中央にテーマを書く(セントラル・イメージ)
マインドマップの書き⽅ ❏ 2. セントラル・イメージからメインブランチを伸ばす ❏ 右上から、時計回り ❏ 3. メインブランチにキーワードやイメージを1つ書く
マインドマップの書き⽅ ❏ 4. メインブランチから連想や発想したことがあれば、 ブランチを伸ばしてキーワードやイメージを1つ書く
マインドマップの書き⽅ ❏ 5. 更に連想や発想があれば、ブランチからブランチを伸ばして書く ❏ 6. 2-5を繰り返し、メインブランチやブランチを増やしていく ❏ 2-5の順序は問わない
テストとマインドマップの例(再掲)
➢ 「無地の紙を使う」 ➢ 「横⻑で使う」 ➢ 「中⼼から描く」 ➢ 「テーマはイメージで描く」 ➢ 「1ブランチ=1ワード」
➢ 「ワードは単語で書く」 ➢ 「ブランチは曲線で」 ➢ 「強調する」 ➢ 「関連付ける」 ➢ 「独⾃のスタイルで」 ➢ 「創造的に」 ➢ 「楽しむ!」 本「[改訂新版]マインドマップから始めるソフトウェアテスト」より マインドマップのルール
マインドマップのガイドライン 本「新版ザ・マインドマップ」を 参考に作成
テストでマインドマップを使う理由 本「[改訂新版]マインドマップから始めるソフトウェアテスト」より 『マインドマップは「考える」作業です。テストケース 表を書く前にマインドマップを描くことによって、 仕様書の中⾝を整理します。整理する作業の中で、 さまざまな疑問や確認すべき点、記述漏れなどを発⾒ することができます。』
テスト計画の検討 インシデントレポートの準備 … 思考を発散させ様々な制約や可能性に⽬配りしたいとき まずは分析、設計がオススメ 図は、 http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J02.pdf を参考に作成 テストプロセスとマインドマップ 計画
分析 設計 実装 実⾏ 完了
悩み1︓厳密に書くか︖ ❖ 書くこと >>> ルール、ガイドラインを守ること ❖ 中⼼から、短い⾔葉で、⾊や記号などで強調ポイントがわかるように書く ➢ ツールの制約で無理なときは、できる範囲で ❖
改善はルール、ガイドラインなどを参考に ❖ 参考︓本「[改訂新版]マインドマップから始めるソフトウェアテスト」で 強調されているルール ➢ 「中⼼から描く」 ➢ 「ワードは単語で書く」 ➢ 「ブランチは曲線で」 ➢ 「楽しむ︕」
悩み2︓(メイン)ブランチが思いつかない︖ ❖ まず、わかっていることを書く ➢ 仕様→テスト条件 ❖ 下調べをする ➢ ユーザの業務や慣れ具合 ➢
過去に出たバグ ➢ 既存システムの動き ➢ 要件・設計 ❖ 既存のフレームワークや考え⽅を参考にする(諸刃の剣) ➢ テストタイプ、品質特性、… ➢ ◦とりあえず書けるし、考慮漏れの予防になることも ➢ ×発想が固定化、定型化しやすい ➢ 取捨選択や、追加の検討を
悩み3︓1回で綺麗に書けない むしろ、どんどん試⾏錯誤する ❖ 実は、メインブランチ「操作」より「検索条件の保存」などを先に書いていた ❖ 実は、「添付ファイル」は他の「対象項⽬」より、ずっと後に追加
テストでのマインドマップ ”私流” の書き⽅ ★ ブランチが思いつかなかったら「起きそうだけど起きたら嫌なことは︖」 ◦ 具体的なバグ→メインブランチは後で ★ 書きながら、抽象化や関係性の⾒直し ◦
具体や細部は「つまり何︖」→親のブランチは後で ◦ 親⼦、上下は随時⼊れ替え ◦ ⼀時的な空⽩ブランチもあり ★ 1ブランチ⽬は、テストタイプやシステムの構造を切り⼝にすることが多い ★ 他⼈の⽬を使う ◦ モブワーク、翌⽇の⾃分
テストとマインドマップの位置付け 中間成果物 がオススメ 思いついたこと何でも 発散に集中→収束に集中 キーワードだけにしやすい
マインドマップだけ︖ 根拠を説明可能 抜け漏れ少 コスパ⾼ 図を書こう 気付き、発想 仕様、制約の理解
ここでの「図」 ↑不要なわけではないが意識せずとも テストで使う場⾯が多い × ⽂章 箇条書き 表 ◦ 図形や線 事柄のほか関連も
図の効果 関連から連想 強調 抽象的表現 俯瞰 端的な表現 理解 発想
テストで活⽤を検討したい図、いろいろ 図の分類は最も使いそうなところ(それ以外でも使えることがある)
マインドマップは汎⽤的なのに、なぜ︖ 他の図はいらない︖ いえいえ、汎⽤的でないから役⽴つ場⾯もある ➔ 制約に従うことで考慮漏れを防ぐ ◆ ステートマシン図を書くと、状態遷移する条件が気になってくる ➔ ⽬的に特化した記法、ルールのため⾒易い ◆
CFDなら、処理の流れと分岐ごとの期待結果を分かりやすく表現できる
まとめ • 良いテストのための発想に、マインドマップの活⽤を ◦ まずはテスト分析、設計で使ってみては • 慣れてきたら、発想と理解のサポートに他の図も活⽤を
参考⽂献 いずれも本書執筆時点(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