マインドマップを使ってテストケースを考えてみた

こんにちは。カメゾーです。

 

今年の4月に、「マインドマップから始めるソフトウェアテスト」の改定版が発売されました。ある方にこの本をオススメされすぐに購入しましたが、本が届いた頃には、既に読み終わったかのような謎の満足感を感じ、1ヶ月ぐらい放置してました。

 

ブログを始めるということもあり、ネタ作りも兼ねて、本を読みマインドマップを書いてみたので、今回はそれについて記事を書いていきます。

[改訂新版]マインドマップから始めるソフトウェアテスト

[改訂新版]マインドマップから始めるソフトウェアテスト

 

 

やったこと

・一人で読んでみて、QAチーム内で内容を軽く共有

マインドマップ書く人決め

・各々が適当に改修予定のチケットを選び、マインドマップのテーマ決定

マインドマップ作成

・やってみた感想の共有

こんな感じの流れで進めました。

そして実際に書いてみたマインドマップはこちらです。

 

僕が書いたマインドマップ

(日付関係の改修チケット)

 

 

f:id:kamezon:20190616151827p:plain

最初(右上から時計回りに書いていった)は戸惑いながらだったので、あまり手が進みませんでしたが、後半はあれよこれよと進み、所要時間は1時間弱でした。

 

沖縄メンバーが書いたマインドマップ

(表示順関係の改修チケット)

f:id:kamezon:20190616151545j:plain

迷いに迷ったらしく、作っては消してを3回繰り返したそうです。

 

 

やってみた感想

 

・あくまで思考法の一つ

本の中でも言及されていましたが、漏れのないテストケースを書く時の考え方の一つであり、これをすることでテストケース作成が早くなるわけではないです。ただ、テストケースの書き方がよくわかっていない人や、まだ慣れていない方には、一度マインドマップを使って、思考を整理してみることをオススメします!

 

・テストケースのレビューをしやすい(気がする)

テストケースを書き並べていっても、その人がどういう考え方をしたのか、過程が見えにくいです。マインドマップを書くことにより、どういうパターンを見ようと思ったのか、なぜこのケースを省いたのかなどを、他者が理解しやすいと感じました。

 

 

反省点

マインドマップを書いた効果がわかりづらい

今回は、それぞれが別々のチケットを対象にしてしまったがために、マインドマップを使うことの有益性がわかりづらくなってしまいました...

 

今度は同じチケットを対象に、マインドマップ作成→テストケース作成パターンといきなりテストケース作成パターンで、どれほど違いが出るのか検証してみたいと思います!