(2021年版) ソフトウェアテストの上流設計-4 テスト分析と論理的機能構造

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

今回はテスト分析の概要説明と、テスト対象を分析するための前提知識として論理的機能構造について説明します。カバー画像のモデル作成の矢羽のところまでの説明になります。

テスト分析の必要性

テストの仕事を行うときに、まず最初にやることはどのようなことですか？大抵の人は、まずテスト対象となるシステム／ソフトウェアについて情報収集をして、テスト対象を理解するところから始めるはずです。

ただ、noteでの連載の第一回目にて、テストが注目される背景として触れたように、ソフトウェアの大規模化や複雑化に伴うテスト量の増大や、開発期間の短縮化によるテスト工数不足が起きている現状では、テスト対象を理解する時間が足りなくなることが多くあります。筆者はテストコンサルという仕事をしていましたが、そのころ、現場で聞く最も驚くべき事態のひとつとして、自分が担当する「部分」以外のことを理解していない、つまりそのシステム／ソフトウェアの全体を理解しないままテストをしている人が多いということでした。理解しておかなければならないことの多さと、知るための時間の足りなさがそうさせているのですが、テスト対象を理解することが明示的な活動として定義されていないことも理由の一つとして考えられます。

テスト分析とは？

まず、分析とはどのようなことをすることだと思いますか？Wikipediaで分析を調べてみると以下のように書いてあります。 

・ある物事を分解して、それらを成立している成分・要素・側面を明らかにすること。
・物質の鑑識・検出、また化学的組成を定性的・定量的に鑑別すること。記事 分析化学に詳しい。
・概念の内容を構成する諸徴表を各個別に分けて明らかにすること。
・証明するべき命題から、それを成立させる条件へ次々に遡っていくやり方。

分析とは、理解したい対象を分解することでより理解を深めていくことだと言えそうです。ということは、テスト分析は、テストしたい対象を分解することでより理解を深めて行く行為と言えるでしょう。的になるものがテストの目的やテスト対象アイテムであり、その的を分解して理解を深めていくことで、無駄にテストケースが多くならず、狙いに対して的確になります（初回にも書いたことですが大事なことなので再掲します）。

そして、「テスト分析」という活動をおこなうということは明示的にテスト対象を理解するアクティビティを定義し、工数を確保するということになりそうです。

テスト分析の流れ
テスト分析では、最終的に仕様項目をピックアップまで行います。そこまでの流れは図のようになります。

まず、テスト対象の理解をするためにテストベース の内容を分解し整理しなおします。整理した一覧がテスト対象の全体像を表すため、一覧を元にテストを進めることでテスト対象の網羅性の確保ができます。

次にテストの目的を分析します。テストの目的の分析では、テストタイプを特定し、テストタイプごとのテストカテゴリを作成します。テストカテゴリを使い、テスト対象のテストベースから仕様項目を識別するための視点を明らかにします。

その後、テストカテゴリを使い、整理した機能（ゆもつよメソッドではフィーチャーのことを指すが、この中では機能と呼んでます）単位で、何をテストするのかを明確にしていきます。つまり、仕様項目のピックアップです。

テスト分析をどの単位で行うか

テスト分析をどの単位でやるか？と言うことに関してあきやまさんから以下のような質問をもらっています。

「それぞれのテストの中でどのようなことを確認していけばよいのか決めることが、テスト目的の設定」のところで、合っていますでしょうか？
としますと、「それぞれのテスト」（細かそう）の中で「テスト目的」→「テスト分析」を行うのでしょうか？（一つのプロダクトのテストの中で何度も？）

— あきやま👾 (@akiyama924) May 5, 2021

モデル作成をどの単位で行うか
これはテスト対象の全てに対しておこないます。最初に全体像を理解すると、自分がテストするものは全体の中のどこなのかといったことがわかるようになるからです。

機能一覧作成／テストカテゴリ作成をどの単位で行うか
これもテスト対象の全てに対しておこないます。しかし、少しずつやるのか、まとめていっぺんにやるのかは、開発対象の大きさ（新規開発なのか、機能拡張や機能改善の開発なのかといったこと）／開発の進め方（ウオーターフォール開発なのか、インクリメンタル開発なのかといったこと）でも異なります。

機能拡張や機能改善の開発でウオーターフォール開発であれば、テストの目的を複数設定したとしても、その複数設定したテストの目的をまとめていっぺんに分析できます。

新規開発だと規模が大きくなるのでウオーターフォール開発だとしてもまとめていっぺんにはできないので何度かに分けてやったほうがよいです。

スクラムなどで行うインクリメンタルな開発であれば、イテレーションごとにできることをやっていくのがよいです。

ただし、少しずつ分析する場合でも、機能一覧やテストカテゴリは一つなので、最初に作ったものを分析するたびに改版して成長させていくことになります。（ここからすごく重要）機能一覧やテストカテゴリの構造を定義し、合意をしておくことと、記載ルールを決めることで、機能一覧やテストカテゴリを成長させながら改版していくことができます。

仕様項目のピックアップをどの単位で行うか
これはテスト対象の大きさや開発スタイルがどうであれ、テスト目的／テスト対象アイテムの単位ごとに行うのがよいです。ですので、何度も行うことになります。同時にやるにしても複数人で作業分担したほうが効率良いです。スクラムでやれば一度にテスト分析する量はそれほど多くならないはずですので、1人でもできると思います。ひとつのスプリントで開発する対象になるものの量がそれほど多くはならないからです。しかし毎週少しずつテスト分析していくので、何度も行うことになります。

細かく分けて何度も行うことになったとしてもとっちらかって何がどこにあるかわからなくならないためにも、機能一覧とテストカテゴリという構造を定義していることが大事です。

テスト対象の分析

テスト分析は、まず、テスト対象の分析から始めます。実は、テスト目的を設定する前からテスト対象の分析は始まっています。テスト対象に関する情報収集を行い、仕様書があれば読み込んで理解をしておくといったことはテストの目的を設定する前にやっていることです。まったくやっていなければテストの目的は設定できません。

テストの目的を設定する前にどこまでしっかり理解できるかは、プロジェクトにどのタイミングで参画しているかによって異なります。要求や仕様をしっかり理解する前、もしくは仕様や設計が出来る前にテストの目的を設定し、テスト対象アイテムを特定しなければならない場合のほうが多いのです。なので、テスト対象の分析は、テストの目的を設定したところでは終わらず、テスト対象アイテムを特定した後にも開発が進む中で明らかになってくるさまざまなことを理解するなかで続いていきます。

理解するために最初に全体像を把握する

テスト対象の理解は、いきなり仕様や設計の具体的なことを調べていくよりも、テスト対象がどのような機能（フィーチャー）でユーザーへのサービスを実現しているかを大まかに把握することから始めるのがよいです。ゆもつよメソッドでは大まかに理解するところから論理的機能構造を使います。

まずは機能（フィーチャー）と論理的機能構造、そして仕様項目について説明します。

機能（フィーチャー）とは？
ゆもつよメソッドでは、テスト対象をフィーチャーに分割して整理します。例えば、デジタルカメラには、「写真を撮影する」というフィーチャーがあります。このフィーチャーは、シャッターを押したことを受け付ける処理、撮影対象をキャプチャーする処理、撮影した画像を保存する処理などが連動して、写真撮影を実現しています。このような処理が集まってテスト対象の特徴として説明できるものがフィーチャーだと思ってください。言い換えれば、ユーザーが使う際にユーザー自身で認識できる機能がフィーチャーです。

論理的機能構造とは？
大村朔平さんの書籍「一般システムの現象学」で解説されている人工のシステムが持つ論理的な構造の説明を、ゆもつよメソッドのテスト分析のモデルとして使いやすく改変したものです。論理的機能構造はテスト対象となるシステムを入力調整、出力調整、変換、貯蔵、サポート、相互作用、外部マネジメントといった要素で分解したものです。

機能（フィーチャー）がユーザーへ提供するサービスとしているのに対して、論理的機能構造はフィーチャーを実現するためにテスト対象の中で何をしているか想定してテストするための参照モデルであり、各要素（図の「入力調整」など）はテストすべき仕様項目をピックアップしていくためのガイドになります。論理的機能構造はこの後のテスト分析のアクティビティでも使うので、その都度どう使っていくかを説明していきます。

仕様項目とは？
フィーチャーを実現するためにテスト対象の中でしていることを綿密に定義したものです。例えば、音楽プレーヤーのサウンド設定にて「ボリュームは１から10の間で設定できる。１は消音であり、10は100デシベルであり、10デシベルずつ大きくできる」と定義したものが仕様項目です。仕様項目は、JSTQBにてテスト条件と呼ぶものの一部です。ゆもつよメソッドでは、仕様項目と期待結果をテスト条件と呼んでいます。以降、テスト条件のことは仕様項目と記すことが多くなりますが、同義だと思ってもらえればと思います。仕様項目のピックアップはテスト分析の最終ゴールなので、その説明の時にまた詳しく説明します。

テスト対象を理解しながらざっくりとした絵（モデル）を描く
全体像を把握するには、仕様を確認しながら、ユーザーが使う際に判断できる機能を論理的機能構造で配置していきます。