ソフトウェアテストでのマインドマップの活用について思うところをまとめたものです。 他の図の話も少し。
ツール：Googleスライド（テーマ「コーラル」）、miro
マインドマップで発想を広げてテストしよう2020年7⽉Kumiko Iseri
View Slide
本書の想定読者＆注意● 想定読者は、ソフトウェアテストでマインドマップを使うことに興味があるが、やり⽅がよくわからない⽅● 本書でのマインドマップの定義は、ゆるふわ○ 特定のルールに従わないとマインドマップと呼べないとも⾔われますが、本書はそのあたり、ゆるゆるですマインドマップは、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
omn
sansantech
yamamuteki
rdlabo
oracle4engineer
koheiawa
otanet
minorun365
lemiorhan
yokawasa
orimanabu
revcomm_inc
mottox2
eileencodes
rmw
keathley
jrom
keithpitt
aleyda
bkeepers
schacon
holman
addyosmani
kneath