テスト観点をマインドマップで作成してみた話

はじめに

こんにちは、KINTOテクノロジーズ（以下、KTC）のQuality Engineering グループでQAエンジニアをしているろきです。

本記事では、マインドマップを使った観点作成の導入経緯、実際の使い方、そして運用を通じて見えてきたことをお伝えします。

マインドマップを試すことになった経緯

現在、QAチームでは観点をConfluenceのページで作成しており、画面単位ではなくテストの目的別（機能確認・表示確認・バリデーションなど）にページを作成し、箇条書きやテーブルで管理しています。
テストの目的別で観点を作成すると同一画面の観点が複数ページに分散するため、全体を一覧で見渡したいと感じる場面がありました。
そこで、1つのボードでQA対象範囲全体の観点を俯瞰できるマインドマップの活用を提案し、試験的に導入することになりました。

マインドマップの作成ルールと構造

ツールを導入するにあたり、作成ルールを統一しました。

使用ツール

マインドマップはMiroを使用しています。

基本構造

マインドマップは以下の階層構造で作成しています。

案件名_verX.X.X > 画面/機能 > 観点 > 因子 > 水準 > 期待値

何をマインドマップにするか

現在、KTCのQAチームでは、テスト観点を主に以下の5つに分類して作成しています。

• シナリオ
• 機能確認
• 表示確認
• バリデーション
• アドホック

このうち、マインドマップ化の対象としているのは主に以下の3つです。

• 機能確認
• 表示確認
• バリデーション

表示確認やバリデーションはConfluenceでリスト化して管理しているため、テスト対象ごとに「表示確認を参照」「バリデーションを参照」のように参照先を記載し、黄色のマーカーで色分けするルールにしています。こうすることで機能確認の観点との区分けがはっきりし、どの対象をどの観点で確認するかを過不足なく整理できます。

一方、シナリオテストやアドホックテストの観点はマインドマップにしません。
これらは、機能確認などと比べるとマインドマップで構造化して整理する必要性が低いため、従来通りConfluenceで文章形式のものを使用する運用としています。

使ってみてわかったメリット

テスト対象の観点を1か所で把握できる

マインドマップ導入における最大のメリットは、1つの画面/機能に関するすべてのテスト観点を1か所で把握できる点でした。

従来のドキュメント形式では観点の種類ごとにページが分かれているため、「この操作はどの観点で確認するのか」を複数ページにまたがって探す必要がありました。マインドマップでは画面/機能を起点に観点が集約されるため、作成時に「各テスト対象にどの観点が紐づいているか」をリアルタイムで確認しながら進めることができます。結果として、テスト対象物と観点の対応関係における過不足を発見し、修正しやすくなりました。

マインドマップがそのままテスト設計の「下書き」に

マインドマップは観点から因子・水準へと枝を広げていく構造上、「通知ON/通知OFF」「入力あり/なし」といった条件分岐を自然に書き出せます。具体的な条件分岐まで落とし込めるため、観点とテスト設計を同時に整理できるようになりました。

条件分岐を書くことで、観点と仕様の精度が上がる

条件分岐を書き出す過程で「この条件の場合の仕様が書かれていない」と気づくケースも増えました。観点作成の段階で仕様の抜け漏れを発見できるため、開発チームやPMへの仕様に関する質問や、仕様書レビューをスムーズに進めやすくなりました。

さらに、「ログイン済み/未ログイン」のように対になる条件が枝として横並びになるため、片方だけ記載されていないケースが視覚的にわかりやすくなります。ある観点の枝だけが極端に少ない・多いといったアンバランスも視覚的に気づきやすく、観点の粒度を揃えやすくなりました。

議論が活発になり、認識合わせに有用

これは導入前には想定していなかったことですが、マインドマップを開発チームとの認識合わせの場で使うと、議論がより活発になりました。視覚的に構造が見えることで「この条件でもテストしてほしい」「この枝はカバレッジが高いので減らしてもいいのでは」といった具体的なフィードバックが出やすくなり、認識合わせに有効でした。

見えてきた課題

Confluenceとの連携

MiroボードをConfluenceに埋め込む際、現状では画面/機能単位で特定範囲だけを埋め込むことができず、ボード全体が表示されてしまいます。画面/機能ごとにピンポイントで埋め込めるようになると、Confluenceとの連携がより使いやすくなると感じています。

コスト

現在はトライアルとして数人のみ契約していますが、チーム全体での利用が本格化する場合はコストが増加します。ボードの作成/編集には契約アカウントが必要ですが、ゲストアカウントであれば閲覧やコメント追加ができるため、用途に応じて使い分けていければと思っています。

まとめ

Confluenceと併用したマインドマップの導入は、テスト観点の具体化・可視化という点で大きな効果がありました。特に「観点が自然と具体的になる」「議論が活発になる」という副次効果は、設計品質向上に貢献していると感じています。

一方で、Confluence連携やコストといった課題も見えてきました。

まずは無料プランで気軽に試せるツールなので、「テスト観点の整理がうまくいかない」と感じているQAチームにはぜひ一度試していただきたいと思います。