FaRSeTの説明③(テスト分析・設計)

前回の記事の続きです。

仕様変更が多いプロジェクトに対して、仕様変更の頻度によりアプローチを変えるということを書きました。

今回は

・仕様変更が少ない要素(業務要件)

 ⇒探索的テスト実施前にマインドマップを活用して業務分析

について書いていきます。

短納期開発による並行プロセスでは十分な開発ドキュメントが揃っていないことが多いため、テスト分析に視覚的効果と共有性が高い「マインドマップ」を活用することを考えました。

なぜマインドマップを活用したかというと、

  • できるだけドキュメントを作らない(短納期なので、なるべく作りたくない)」
  • 関係者同士のコミュニケーションを促進させる(ドキュメントの不足はここで補う)
  • 楽しさを演出(ここ、意外と重要)

といったことを重視したからです。エクセルやワードで作るのは、時間がかかる上に、それを他人が見てレビューするのも大変だし、なにより辛いので。(仕事は辛いもの・・・なのかもしれませんが)

具体的には以下を行います。

・開発側とテストチームが業務要件の不明点の確認などを行う

⇒短納期プロジェクトはドキュメントが少ない/不備があったりするので、ここで関係者同士のコミュニケーションでそのスキマを埋めていきます。ここは大事。

「利用者分析(想定ユーザー)」「業務シチュエーション分析」「システム分析」

⇒誰が、どのような場面で、どのように(何を)使うのか、を分析します。5W1Hの簡易版です。あまり「型」にはめないようにしています(型をつくると、どうしてもそこに無理やり当てはめてしまいたくなるので)。なので、あまり型を考えずに思うままに書いていった方が良い気がしています。

関係者内でマインドマップのレビューを行い、内容の合意を行うことでテストの漏れを減らす。

⇒ここは最重要。関係者内での「合意」「納得」がここで決まっちゃいます(この後はもう探索的テスト~結果報告なので、レビュータイミングがここしかない)

分析結果は後述のテストチャータに反映

⇒分析しても後のプロセスに生かせないと意味がありません。この後の探索的テストのテストチャーターに組み込みます。

マインドマップの例は

https://www.juse.jp/sqip/symposium/2018/timetable/files/A2-2_ronbun.pdf

の「図1」を参照ください。

さて、次回はテストチャーターの設計について書きます。

ーーー

補足です。

マインドマップでのソフトウェアテストといえば

池田暁,鈴木三紀夫,マインドマップから始めるソフトウェアテスト,技術評論社,2007

ですね。私もこの本はよく読みました。ソフトウェアテストの手法が「テスト対象をよく知ってる人が勘と経験で頑張る」の世界だった時代において、とても大きなインパクトを受けました。

以来、マインドマップでテスト分析~設計という手法が浸透したと思いますし、FaRSeTにおいても利用させて頂いています。

また、やっぱりマインドマップ書くのって楽しいんですよね。そして、他人の書いたマインドマップを見るのも面白いし、疑問点や作り方へのツッコミも含めて議論が活発化すると思います。

また、どこまで書き方を揃えるか・・・とか、整合性をとるか・・・とかの問題もありますが、今のところは縛らないようにしています。