読者です 読者をやめる 読者になる 読者になる

mhlyc -presentation

ソフトウェアテスト、品質に関わること、たまに変なことを書いていくブログです。

長崎IT技術者会SIG 第1回マインドマップ本読書会(仕様分析) 開催レポート

長崎IT技術者会SIG 第1回マインドマップ本読書会(仕様分析)

先月実施した勉強会の開催レポートです。

nagasaki-it-engineers.connpass.com

 

※現在、追加のメンバー募集はしておりません。あらかじめご了承ください。

 

会の趣旨は、テストプロセス全体についてまとめられている書籍「マインドマップから始めるソフトウェアテスト」の読破と実践を通して、日々のテスト業務を改善しようというものです。

自分がこの書籍を読んで非常に現場に近く役立ちそうだと感じたことと、著者である池田暁さんが「8年前に出した書籍ではあるが、この書籍をテーマとした勉強会があればサポートをしたい」といったことを話されたことが開催のきっかけです。

幸い今回集まったメンバーはかなりモチベーションも高く、今後の勉強会も有意義なものになりそうです。

 

勉強会の流れ

勉強会の流れは以下のようになっています。

 

読書パート

  1. 章ごとに決められた担当者が、章の概要をざっくりスライドにまとめてきて、当日発表する
  2. 発表を聞く人は、それを聞いたり自分で本を読んだりして考えたこと、疑問点を書き出す
  3. 2で挙げた疑問点を皆で見ながら、議論する

演習パート

演習の題材:小型・防水・防塵ビデオカメラ『GoPro』

マニュアルを各自読み込み、各章の内容を実際に実践してみる

 

それでは、具体的に第1回(仕様分析)でどのような結果になったか書いていこうと思います。

 

読書パート(第1回)

第1回のテーマは「仕様分析」でした。越中谷さんに仕様分析の章について概要を発表いただきました。発表資料は今回の演習結果も含め、アップデート予定とのことです。

その後、参加者から出てきた疑問点、議論の結果をまとめました。

 

  • 要件定義書がある場合とない場合でアウトプットは異なるのか?

→本来なら、両方とも近いものがアウトプットになるべきではないか。

  • 要件定義書がある場合もテストカテゴリは使った方がいいのか?

→テストカテゴリを使うというよりは、「要件定義書から目次を抜き出す」という作業が「テストカテゴリから今回使うものを抽出する」という作業に対応するイメージではないか。

  • テストカテゴリを出すのが大変そう。
  • テストカテゴリは、過去のプロジェクトのテスト結果やノウハウから導かれるものという認識で合っている?
  • 仮に要件定義書がない場合と言っても、最低限のドメイン知識、ナレッジを持っていないと仕様分析は困難なのではないか?(このシステム(アプリケーション、製品)の目的は何?とか)
  • 仕様分析=テスト対象分析+テスト要求分析?(p.32を読むと、「テストの種類だけでなく、テストの開始・終了条件、人員体制なども〜」とある)
  • 仕様分析の最終的なアウトプットは何?マインドマップ

→どんなテストをすればいいのか決めること。テスト計画のもとになるもの。

マインドマップ以外に仕様分析のアウトプットはない?

→現場やドメイン、形態によってアウトプットは異なってくるのではないか?

  • ここでは仕様分析の後にテスト計画があるので、まずはプロジェクトの期間などの制約を気にせずに仕様分析をすることで良いのか?
  • p.84で言及されている「一般的なシステム構成」とは、ゆもつよメソッドでいう論理的機能構造に近い?
  • p.76でメインブランチは5つ挙げられているが、p.77の図ではブランチが4つしかない。

 

以上、全ての疑問点を解消することはできませんでしたが、概ね仕様分析に関する大きな疑問点は整理することができました。やはり大きいものは、「仕様分析は何をする工程で、何をアウトプットとして期待しているのか」という点です。

これといった結論は出なかったのですが、まずはこれを踏まえて実際に手を動かしてみようということになりました。

 

演習パート(第1回)

演習パートで仕様分析をやってみて、参加者の皆さんが描いたマインドマップです。

なお今回は以下の制約を前提として演習を行っています。

  • 演習の題材:小型・防水・防塵ビデオカメラ『GoPro』
  • 評価系、運用系、構成系、ボリュームテスト、ラッシュテストは対象外とする

 

書籍p.81のテストカテゴリをもとに作業しました。なのでメインブランチとその一階層下までは表記を揃えています。

また、途中から各メンバーでブランチを分担して描いています。が、どうも慣れていないせいかかなりメンバー間でばらつきのある結果となりました。

以下、自分の描いたマインドマップのみ載せておきます。

 

 

f:id:mhlyc:20151010135443j:plain

 

当たり前ですが、個人個人で描き方には大きく差が出ますね。マインドマップはこういった差が絶対的に存在してしまうツールなのですが、この属人性的なものをうまく業務に適用していくにはどうしたらいいか、といった話題も懇親会の中で上がりました。特に新人や経験の浅いメンバーがマインドマップを用いる場合、うまくレビューなどのプロセスを踏んでベテランの意見をフィードバックするのが重要そうです。

 

演習で出てきた感想としては、

  • マインドマップを描く前に、仕様書がしっかり頭に入ってないと手が止まる
  • あまり細かい定義や誤りなどを気にせずに、まずはどんどん描いていく方が良いのではないか
  • ダブりや間違いは後から解消するのが良さそう

といったものが挙がりました。

また、そもそもマインドマップの記法に習熟が必要という面もあるので、今後演習を進めていく中で解決していきたいです。

 

 

以上、簡単ですが開催レポートでした。皆様の参考になれば幸いです。

 

※今回のテーマとなっているマインドマップ本のリンクを貼っておきます。テストプロセス全般について学べて、初心者にも読みやすいのでオススメです。