さて、今年も始まりました。ソフトウェアテストの小ネタのカレンダー | Advent Calendar 2023 - Qiitaの1日めの記事になります。

今回は、マインドマップを使ったテストについて、自分なりのやり方を書いていきます。マインドマップを使ってテストをしよう、という発想自体は新しいものではなく、かつ自分としても毎回ちょっとずつ変えながら色々試しているところです。なので皆さんのやり方を(まだカレンダー埋まってないところなどで)ぜひ教えてください。

ちなみにこの記事タイトルの元ネタは村上春樹です。

走ることについて語るときに僕の語ること - Wikipedia

ちょっと脱線:この記事を書こうと思ったきっかけ

会社でQA活動をしているなかで、開発の方に「自分のテストのやり方を見せる」とか「テストケースを作るまでの過程で、QAがどうやっているのかやり方の例を見せる」といった機会がありました。

自分はマインドマップだとしっくりくるので、そのへんを紹介したら

  • マインドマップをテストに使ったことはなかった
  • これはよさそう

という感想が開発者からチラホラ出てきて、だったらブログ記事に書いてみよう、と思った次第です。

自分なりのやり方1:スクリプトテストの場合

自分がテストにマインドマップを使うシチュエーションとして、大きく2パターンあります。

ひとつはスクリプトテスト、ざっくりいうと「テストケース」とか「テスト項目」を作るまでに使います。

スクリプトテストの中でも、特に

  • テスト分析
  • テスト設計 にあたるところでマインドマップを活用しています。

※ソフトウェアテストでマインドマップを使うなら必ず読んでほしい書籍『マインドマップから始めるソフトウェアテスト』では、テスト計画など他の段階での活用方法も掲載されています。

テスト分析

Image from Gyazo ざっくりこんな形でマインドマップを書いていきます。

書くときの(今時点での)マイルールとして、おおまかに左にInput情報を書き、右側にツリーを広げていきます。これは私個人の感覚かもしれませんが、マインドマップを書くときに右から左にツリーを広げて行こうと思うと窮屈な気持ちになって、思考があまり発散しない傾向にあります。

基本、色々なものは左が過去で右が未来だったり、数直線も左がマイナスで右がプラスだったり、右に思考を広げていくほうが自然な気がします。

なので、左側にはテスト分析をするにあたっての前提事項や、すでに決まっていることなどとして

  • テストベースは何か
  • プロジェクトの概要はどんなものか

を書いておくようにしています。

そして右には、主にテスト条件を書いていきます。が、テスト条件とは、を厳密に考えたり、「これってテスト設計で考えるべきことだよな・・・」など考えてしまうとこれまた思考の発散の妨げになるので、気にせずどんどん書き出すようにしています。同時に、テスト条件を考えながら出てきた疑問や、設計時に改めて考えたいことなども「気づいたこと・メモ」として残しておきます。

このように書き出したマインドマップを、一部は書いたままではなく組み合わせたり移動させたりして多少の構造化・整理をします。

そして、マインドマップの状態で開発チームに見てもらうこともありますし、別の形(Excelの表など)にテスト条件部分を移したうえでレビューを受けたり、などもしています。

テスト設計

Image from Gyazo

テスト設計もマインドマップで行います。

このとき、ひとつのマインドマップでテスト分析もテスト設計もやる派の方ももちろん居ると思いますが、自分は分けています。

ものすごく深い理由がある、というほどではないのですが・・・

マップを作り直すことによって一度思考自体がリフレッシュされる気がする、というのも理由のひとつです。あとはテスト分析後に誰かのレビューなど受けたとして、一度その時点でのスナップショットを取っておきたい、ということもあります。テスト設計中にテスト条件にフィードバックすることももちろんあるのですが、それとは別に取っておく、ということですね。

テスト設計時も、左がインプットで右がアウトプットという位置関係は一緒です。

先にテスト分析のマインドマップからテスト条件ブランチをまるっとコピペして、そこからテスト設計のブランチの先を書いていきます。

上の図には現れていませんが、テスト条件で挙げた「テストすべきこと」が、テスト設計の中でカバーされているかどうかなどをブランチの色を変えるなどしながらチェックしたりもします。

自分なりのやり方2:探索的テスト

Image from Gyazo 探索的テストをするときにも、マインドマップを使います。

おおまかなブランチの構成などはテスト分析のときに似ていますが、探索的テストのときにはよりフリースタイルです。

流派は色々あると思いますが、私は探索的テストをやる前にざっとドキュメントベースでどのへんやろうか考えてメモしておいたりします。テストチャーターというほどではなく、もう少しメモ的なものです。

メモ、でいうと事前の用意よりかは探索的テストをしながらメモをしておくことが多いです。

テストをしながら「あれも確かめよう」「こっちも見てみよう」というどんどん案が出てくるので、それを一旦マインドマップ上にメモしておいて、順にテストしていくイメージですね。

私は仕事中、開発の方とビデオ会議繋いで画面共有しながら探索的テストを見せたりするのですが、その際にもメモがあることによって「伊藤さん、**のところも見たほう良くないですか?」といった、ペアテスティングのナビゲーターのように振る舞ってもらえるのでとても良いですね。

使っているツール

いくつかのツールを試してみましたが、最も直感的に使える(と感じている) Xmindを愛用しています。

無料版ではいくつかの機能に制限がありますが、普通に使う分には不都合ないレベルです。

Xmindはいいぞ。

マインドマップでテストすると楽しい

これに尽きるのかなーと思っています。

自分がHAYST方とかゆもつよメソッドとかちゃんと出来ないからライトな自己流でやっちゃってる、という部分も多々あるのですが・・・

マインドマップでテストを作ると、特に作る過程を見せると、開発の方も「それよさそうだね」と思って一緒にやってくれたりするので、そういったきっかけづくりという面ではとても役に立っていると感じます。

もっとちゃんと知りたい、という方は『マインドマップから始めるソフトウェアテスト』を読んでみてください。

参考文献