(2021年版) ソフトウェアテストの上流設計-5 機能一覧の作成

前回のnoteから、ゆもつよメソッドとして特徴的なテスト分析の説明にはいってます。2021年5月28日に開催予定のJaSST東北2021で行うワークショップとリンクした内容になっていきます。

今回は、テスト対象を分析した際の成果物となる機能一覧について説明します。カバー画像の機能一覧作成の矢羽のところになります。

テスト対象の機能の仕様を整理し、再分類をする

前回のnoteでざっくりと全体像を絵で描くことである程度の理解したら、仕様書などテストベースをちゃんと読んでいき、そこから理解したことを分解し整理しなおします。

ソフトウェアテストは大抵の場合、テスト対象の機能にある入力を与えて動作させた結果（出力）が期待と一致しているかを確認します。その為、テスト対象はどのような機能（フィーチャー）が集まって成り立っているのかという視点で整理すると全体像を抜けもれなく把握することができます。

整理した機能を一覧にする際、テストベースを右から左へコピーするようなイメージで転記するべきではありません。同じ機能でも、様々なドキュメントに異なった表現で記述されている事が多くあり、よく理解していくと、一つの機能の画面レイアウトに関する仕様、入力データの仕様、とりうる状態などで違う仕様書に記載されている、もしくは違う章に記載されていることがあるからです。別々に書いてあるものを一つの機能としてまとめることを再分類と呼んでます。

上記のスライドは2010年の雑誌への寄稿でも使ったもので、その後も、ゆもつよメソッドの講演をするときにはいつも使っている、デジカメの例で示した仕様書から機能一覧にしていく時のイメージ図です。例えば、仕様書では、操作＞撮影のカテゴリの中にあるホワイトバランスやオートフォーカスは、機能一覧では設定＞撮影設定の一つとして整理しています。また、仕様書では操作＞再生という分類になっているものを、機能一覧では再生とデータに機能カテゴリを分けて、かつ機能項目としては再生にはサムネイル、一枚づつ再生、スライドショー再生とわけ、データのほうはファイルコピー、再生画像編集とわけました。

これは、2010年より前の当時、コンサルとして入っていた案件で実際にテスト分析をしたときのものをベースにしたサンプルですが、何か決まったルールに沿って分類したわけではなく、私のコンサルをベースにテスト対象のドメインを理解しているメンバーの方々が意見を出し合ってこのような分類になりました。

最近の開発の仕方で例えると、ユーザーストーリーとか、ストーリーチケットという形式でフィーチャーとしての機能が定義されますが、この単位でも実装する際にはフロントとサーバー側で別のタスクチケットにしたり、共通で使うバッチを別のチケットにするといったことがされると思います。テストする際には、単体であれば各タスクチケットごとで良いと思いますが、ユーザーからみた機能としてテストするのであれば、それらをまとめて実現できるものをテストしないといけません。これは機能一覧を作る考え方と一緒です。

機能一覧の作成

テスト対象の分析結果としては機能一覧表を作成します。下図でいうところの機能項目がメインの項目になり、上位階層に機能カテゴリ、下位階層にテストベース（下図の例では仕様書の章番号）を記載します。

表の階層化は、機能項目を見やすくするためにしています。現場でカスタマイズする際には、機能カテゴリやテストベースのところは現場で見やすいものにしても構いません。あくまで機能項目のリストだと考えてください。