EurekaMoments

This is my studying logs about Autonomous driving, Machine learning technologies and etc.

PlantUMLで学ぶソフトウェアテストのためのマインドマップの使い方

目次

背景・目的

ソフトウェアの品質を保つために、ソフトウェアテストによって
バグを見つけ出す事はとても重要です。ただし、ただ闇雲に大量の
テストをやろうとするだけだと、それらの準備や実行に時間が
掛かったり、テストケースがごちゃごちゃになって混乱したりと、
開発の効率を逆に落としてしまう事になってしまいます。
自分も最近になってソフトウェアのテストを自分で作るように
なったのですが、やはり何をどこまでテストすればいいのかを
決めるところで苦労しているのが現状です。
何かいい方法を探していたところ、下記の書籍を読んだことで、
テストを考える際に自分の頭の中を整理するマインドマップという
手法があるのを知りました。

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

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

今回の記事では、この書籍を読んで学んだ事のメモと、各章毎の
マインドマップを自分がPlantUMLで描いてみた例を紹介します。

PlantUMLによるマインドマップの描き方

PlantUMLには、UMLのダイアグラムだけでなく、マインドマップを
描く機能もあります。詳しい使い方については、こちらの記事が
分かりやすいので参照してください。
qiita.com

ソフトウェアテストって何?

  • ソフトウェアテストは、物作りの手順や方法など開発プロセスが
    持っている問題について、改善を促す事ができる。
  • ソフトウェアの開発時に要求分析や設計の工程があるように、
    テストにも仕様分析や設計の工程がある。
  • 開発の各設計ステップの成果物が完成次第、前倒しで対応するテスト
    の仕様分析に取り掛かる。

マインドマップって何?

  • 放射思考を使って、中心のセントラルイメージから、ブランチと
    呼ばれる曲線を延ばし、その上にキーワードを乗せていく。
  • 中心から描いていき、1ブランチ=1ワード、ワードはフレーズでは
    なく単語で描く。 f:id:sy4310:20191011231553p:plain
  • A3のような大きな紙で描く。
  • テストケース表を書く前にマインドマップを描くことによって、
    仕様書の中身を整理する。仕様書を深く読み込んでからテストケース
    を書くこと。
  • 下記は、割り勘ツールの仕様をマインドマップで整理している例。
    f:id:sy4310:20191011232728p:plain
  • 重複したワードが出て来ても残しておき、そのまま続ける。
  • 疑問に思った事柄や浮かんだ言葉は忘れずにメモしておく。
  • 仕様書に書かれていない抜け・漏れを見つけ出す事もある。
  • 複数のメンバーで描いたものを持ち寄って比較検討する事も効果的。

ソフトウェアテストでの使い方

  • 要件定義書がしっかり書かれている場合と、そうでない場合で、
    マインドマップの適用方法は変わってくる。
  • 現行の業務やシステムの課題には特に目を通しておく。
  • 描き出したブランチから、どんなテストが必要なのかを考える。
  • 要件定義書がないなら、要求をまとめる事から始める。 f:id:sy4310:20191012094056p:plain
  • テスト対象の種類やシステム形態によって、実施するテストタイプを
    マインドマップを描きながら検討する。
    f:id:sy4310:20191012094510p:plain

    テスト計画を立てる

  • どの項目とどの項目を合わせてテストできるか考える。

  • 別々に実施するか、同時に実施するか?
  • マインドマップを描きながら、テスト対象や合否判定基準などを
    具体的にしていく。
    f:id:sy4310:20191012095554p:plain
  • 計画が検討出来たら、今度は、テストを実行した結果得られる
    テスト成果物を検討する。
    f:id:sy4310:20191012100952p:plain

テスト設計

  • テストの目的を確認する
  • テスト対象の仕様を確認する
  • テスト項目の候補を挙げる
  • テスト項目の値を検討する
  • テスト項目の組み合わせを検討する
  • 顧客の振る舞いを考慮した負荷をかけなければ、性能に関する
    不具合を見つけられないことがある。 f:id:sy4310:20191012103931p:plain

テスト実装

  • 設計で検討した項目にしたがって、テストケースを変化させる
    パラメータが何かを検討する。 f:id:sy4310:20191012105257p:plain
  • テストケースとしてまとめる内容を定義したテストケース
    テンプレートもマインドマップを描いて下記のように検討する。
    f:id:sy4310:20191012110303p:plain

テスト実行

  • 実行した日時や担当者、気になる情報などを記録していく。
  • テストログを闇雲に発行しない。
  • テストログをマインドマップで描き、テスト結果がNGに
    なったテストケースを分析していく。
  • 異常内容を分析し、類似のテスト結果を見つけて、
    インシデントレポートにまとめる。 f:id:sy4310:20191012112905p:plain

テスト報告

  • 各項目の情報を集めつつ要約し、担当者としての見解を
    コメントとして残す。
  • 情報全体を俯瞰的に見て、それを文章としてまとめるので、
    試行錯誤が必要になる。
  • この試行錯誤にマインドマップを適用することができる。
  • 入出力情報を図で表現するときは、入力を左、出力を右に
    配置するのが一般的。
  • 左側に入力情報を配置したマインドマップの例。
    f:id:sy4310:20191012114749p:plain
  • 右側に出力情報を配置したマインドマップの例。 f:id:sy4310:20191012114846p:plain
  • 一番上のブランチから順に読んでいくと、それだけである程度
    文章として成り立ちそうなものになっているのが理想。