どしろうと製作所：WebLog

記事のまとめはこちら。


■テスト要求の全体像を明確化する理由

まずは「テストが終わったと思った後」で発生する問題事象について思い浮かべてみましょう。テストで検出できなかった不具合が発覚して、ステークホルダから怒られながら修正する…という状況がありますねぇ（遠い目
このような事態が発生しないように、事前にテストのスコープを明確化して、抜けを確認しながらステークホルダと合意して進めたいと思うでしょう。

その際に、テスト要求の全体像を整理して明確化することが効果的です。ここで「テストカタマリー」の記法を用いて、テスト要求の全体像を作り出す作業を行います。


■参照モデル（DFD）から機能に対するテスト要求の全体像へ

ここでは、特定のインプットからの手順に絞られてしまいますがご了承ください。
前回紹介した参照モデルのDFDから機能に対するテスト要求の全体像を作る例となります。


テストカタマリーの記法では、一連のテストケースの塊を用いてテストをまとめた表現ができます。
ここでDFDでの丸部分（機能/処理）には、一連の入出力と処理が表現されております。それぞれの丸に対応する入出力に対応するテストケースが多数存在するとも言えます。


そのため、DFDを上手に表現することができた場合には、それぞれのDFDの丸部分（機能/処理）に対してテストカタマリーを対応付けることもできます。


DFDの第一階層と機能に対するテスト要求の全体像を対応づける場合には、トレーサビリティを確保しながら全体像を整理することができるのが特徴です。

なお、当然ですが、テストの検討は機能以外に対しても必要です。ここでは機能以外の検討は行うことができておりません。
機能以外のテスト検討の方法と表現に関しましては、次回の記事にて紹介します。


■DFD以外の整理方法に対するテスト全体像

★DFD以外で機能の全体像をモデル化している場合
上記したDFDからのテスト以外においても、機能の全体像を何らかの形式で整理（モデル化）しているような場合には、対象のモデルとテスト要求の全体像を対比して表現することは可能と考えております。
ただし、どんなモデルにも言えますが、テストに向いてないモデルの場合にはテストが困難となります。

★ユースケースや画面仕様をインプットとする場合
ユースケースや画面仕様をインプットとしてテストを検討する場合もあるはずです。これらの場合にも、最終的には「一連のテストケースの塊を活用して全体を表現する」ことを考えた整理を行っていただければ、テストカタマリーの記法を用いて全体像を示すことは可能です。

★何らかの階層的な整理が行われている場合
また、実際にある程度の規模のソフトウェアにおいてテストを検討する場合においては、階層的なグルーピングを行っている場合もあります。（極端な例は「大・中・小」で分ける）
この場合においても、テストカタマリーで表現できますが、テストの重複や抜けを判断することが困難になったり、詳細を検討する際に苦労する可能性が有ります。

結局はモデル化の上手さに依存する…ということになりますね。


■不十分な検討部分

今回の記事に記載した内容では、「機能」のみに絞られた部分だけが検討されたことになります。当然テストでは機能以外に必要な検討は多数あります。
これらの機能以外の検討も行い、テスト要求の全体像を表現する方法について次回の記事で紹介します。