mhlyc -practice

ソフトウェアテストと品質保証がメインテーマです。

「初級者向け マインドマップによるテスト分析設計勉強会」参加メモ

テスト分析・設計のお話(手帳のメモから書き起し)

こちらの勉強会に出た時のメモがありましたので、書き起こしてまとめておきました。

nagasaki-it-engineers.connpass.com

 以下、勉強会の時にとったメモです。

f:id:mhlyc:20151228173904j:plain

f:id:mhlyc:20151228174407j:plain

f:id:mhlyc:20151228174410j:plain

f:id:mhlyc:20151228174414j:plain

ちょっと読みづらくて何が書いてあるかわからないですね。なのでここに記事としてまとめていきたいと思います。

何のメモ?

まずこれが何のメモなのかというと、「初級者向け マインドマップによるテスト分析設計勉強会」の参加メモです。

なので、そもそもテスト分析・設計というのが何で、どうしてやらないといけないのか、なぜマインドマップが有効なのかといったことについて書かれています。

向きの話〜コピペテストではいけない理由〜

要求と要件の違いは何でしょうか?

一般に、たくさん、ほぼ無限大にある要求から問題を特定したものを要件と言うことが多いようです。この要件を、計算機世界で実現するために転写したものが仕様と言われます。なので要件を仕様に落としていくのは、保証する範囲を狭めていく向きといえます。

仕様化するにあたって、「こう動くべき」「こう動かないべき」ということを決めていきます。そして、ソフトウェアをテストするときはこれを確認します。

ですがここには落とし穴があります。というのは、ソフトウェアの機能は「こう動くべき」「こう動かないべき」という2通りなのではなく、往々にして「どう動くのか定義されていない」という未知の領域が含まれています。テストではこの未知の領域も含めて「ユーザにとって不都合なことが発生しない」ことを保証しなければいけませんから、当然そういったテストもしなければなりません。

しかし、仕様書を読むとどうでしょう。「こう動くべき」「こう動かないべき」ということはある程度書かれてはいますが、そういった仕様とは全く関係のないテストはなかなか思いつくことが難しいです。これは仕様化とは逆の、保証する範囲を広げていく向きなので設計の頭で行うのはなおさら困難です。

仕様書をもとにしたテスト(いわゆる コピペテストというやつ)には品質保証的な意味で限界があることがあり、それをどうにかしたいというのがテスト分析・設計のモチベーションであると僕は理解しています。それで、その一つの解法が「マインドマップを利用したテスト観点の発想」なわけです。

テストケース表から発想することの問題点〜マインドマップの活用〜

一般的なやり方では、テスト観点というのはテストケース表をもとに発想していくわけですが、これはあまり良くありません。というのも、テストケース表は形式上、階層化に限界があったり階層じゃないのに階層っぽく見えてしまったり、何のテスト観点を見ているか分かりづらかったりと、あまり発想と表現に優れた形式ではないのです。というところから、発散思考のツールであるマインドマップを活用したら良いのでは、となります。

マインドマップの描き方

マインドマップの描き方については、たくさん本やWebに情報があります。1ブランチ1ワードとか、いろいろマインドマップにはルールがあります。特に図解するということには大きな意味があります。図解して考えることで、いきなり深掘りしていくよりも発想しやすくなります。

仕様書の読み方

仕様書を読んでいくときは、基本的に「メモを入れて、汚くしていく」ことを心がけます。この時3色ボールペンなどを使うのも良いです。そうすることで仕様が頭に入りやすくなります。

マインドマップを描く前に

実際にマインドマップを描いていく時は、きちんと仕様書を読み込みインプットしてからの方が圧倒的に効率が良いです。結局、マインドマップは短時間(長くても20〜30分?)でバッと書き出していくので、仕様書が頭に入っていないと露骨にボトルネックになります。(これは別途実施しているマインドマップ勉強会での演習でもかなり感じていることです…)

以上メモから思い出したことをまとめてみました。かなり大事なことが書かれていました…振り返りは大切です。これからはきちんと随時まとめをしていこうと思います。