マインドマップを用いてテスト活動してみた
こんにちは。
iCARE QAEチームのぜにまるです。
最近QAEチームの取り組みとしてマインドマッピングを実施しているため、そちらについてブログを書いてみました！
もくじ
- マインドマップをやってみることになった経緯
- 1回目のマインドマッピング
- 2回目のマインドマッピング
- 3回目のマインドマッピング
- まとめ
- 所感
マインドマップをやってみることになった経緯
最近までチーム内で自分のみテストケースの作成やレビューを行っていましたが、メンバーが増えてきたことにより属人的な体制となったため、それを打開するべく開発側で作成されたテストケースの作成・レビューを他のQAEチームメンバーと一緒に行うことにしました。
チームメンバーと一緒に体系的にテスト分析・テスト設計することが少なかったため、自分がどのようにテストケースを考えているのかを伝えるのが難しいと感じていました。
フェロー（QAE技術顧問）の ブロッコリーさん に相談したところ、『「マインドマッピング」を用いてみると良いかもしれない』というアドバイスをいただき、チームで取り入れてみることにしました。
1回目のマインドマッピング
実施
ツールは、使用している方が社内に複数人いたので miro を使用しました。
QAEチーム内で仕様の読み合わせが終了した後、マインドマップについての本を読みながら仕様の構造をマインドマップにおこし、気になることや疑問点を付箋でメモしていきました。
※参考にした本: マインドマップから始めるソフトウェアテスト
実施結果
マインドマップを書き進めていくと、テキストやデザインでしか把握できなかった仕様が、階層や要素のそれぞれの関係を整理して理解できて、頭の整理にもなってよかったです。
また、仕様の不明瞭な点が仕様把握の段階で明確になったため、早期的に開発/ビジネスサイドに確認することができました。
ただ、チームでマインドマップを描いている時は、最初の中心のテーマからメインブランチを伸ばすのが難しいと感じていました。
上記を解決するため、ブロッコリーさんに相談したところ、
- メインブランチを書くのが難しいのであれば、メインブランチから考えるのではなく、複数の要素から束ねられたものがメインブランチとするように考えてもよい
- また、描かれたマインドマップは、条件や画面やドメイン知識などが入り乱れて記載されているので、それを分解すると良さそう
という旨の回答をいただきました。
▼1回目のマインドマッピング
2回目のマインドマッピング
実施
1回目とは違うプロジェクトにて、1回目と同じようにチーム内でマインドマップを描き、条件や画面を後ほど分解しようとしていました。
ただ、分解しようと試みてもなんともしっくりこなかったためブロッコリーさんに再度相談しました。
- 複数の条件にひもづく挙動が文として書かれているブランチがあり、それを「条件」と「挙動」に分けていくと良さそう
- 分けるときの粒度を同じ階層のものと合わせるとより整理されそう
と上記のアドバイスをいただいた通り、文として記載されたところを条件と挙動に分解して記載してみました。
実施結果
一つの操作に対して「条件」と「挙動」に分解することによって、仕様が噛み砕いて理解しやすくなり、条件の分岐が出しやすくなりました。
また、条件のみ、挙動のみを書き出すことによって、「この時はどうなるだろう？」など抜けていた観点が出てきやすくなりました。
▼2回目のマインドマッピング
3回目のマインドマッピング
実施
1,2回目まではテストケースレビューのための仕様を分析するためのマインドマップを描いていましたが、今回は別プロジェクトにて仕様が一部決まっている状態で、開発者も交えてマインドマップを描くこととなりました。
やり方としては、開発者の方に一通り機能の仕様をご説明いただき、出てきたワードやデザインをもとにマインドマップを簡易的に作成し、気になったところなどをマインドマップに付け足したり付箋に書き出したりしました。
実施結果
画面のデザインや画面を見ながら話していたため、具体的なUIについての意見が多く出ました。
ブロッコリーさんにご相談したところ、こちらのアドバイスをいただきました。
- どういった方法で開発するかなど具体的なUIの話（How）をする前に、一歩引いてこのプロジェクトで何をやりたいか、なぜやりたいのか（Why）を考えて、このプロジェクトにおいての重要なことについて共通認識を持った方が良い
- 一概には言えないが開発者やデザイナーなどは「How」を自ずと考えてしまうものなので、一歩引いて考えられるようにリードすることがQAの価値とも言える
確かにデザインや画面についてばかり考えており、このプロジェクトにおいて本当にやりたいことなどの共通認識が持てていなかったため、改めてWhyのマインドマップも作成してみようという流れになりました。
▼3回目のマインドマッピング
まとめ
- 最初から整理整頓しながら描くのではなく、思いつく限り出した後に整理する
- 具体的なUIについて考えを深めていくことも悪くないが、そもそもどうしてこのPJが必要なのか・このPJで何をしたいのかなど概念的なところを一歩引いて考えることがチームの共通認識につながる
- さまざまな開発フローにおいてマインドマップは有用である
所感
今まで属人的で1人で考えてきたことを、チームメンバーとあーだこーだ言いながらアウトプットできたことが楽しかったし、チームで活動している！と実感が湧きました。
また以前までは、テストケースを作成するという工程を体系的に他メンバーに伝えることができなかったけれど、一緒にマインドマップに取り組んでいるだけでその問題が少し解消されたと感じました。
Devチーム内に「QAEチームは最近こんなことやってるよ〜」と展開してみると、面白そうだと感じてくれた開発者の方も交えてマインドマップ作ってみよう、などのお話がでて、開発側との上流からの認識合わせにもこれから役立っていきそうだと感じました。
今回はここまでとなりますが、開発者を巻き込み、早期的にQAチームが開発フローに入ることができるため、継続的にマインドマッピングを実施していこうと思います。
