どしろうと製作所:WebLog

どしろうと製作所のBlogバージョンです。
「どしろうと製作所」のHPの記載内容とはあまり関係無いです。
気が向いたときのみ更新します。
テストカタマリーを活用したテスト設計プロセス案6:テスト詳細設計を行い、テストケースを完成させる
以前紹介した「テストカタマリー」と呼ぶ謎の記法を活用したテスト設計を行うためのプロセス案を紹介します。
ハイレベルテストケースまで特定された後は、テスト詳細設計で具体的なテストケースを作成します。
ここにきてようやくテスト技法が活躍するようになります^^

注:こちらのシリーズは以前のテストカタマリーの記事を読んでいることを前提としており、テストカタマリー自体の説明は本シリーズでは省略します。

記事のまとめはこちら。


今回もそこそこ長めです。

■ハイレベルテストケースで不足していること

前回作成した抽象的なハイレベルテストケースだけでテストをできなくもないですが、具体的なパラメータやその組合せは曖昧な状況です。
この状況でテスト実施する場合には長所・短所が存在します。

★長所
・スキルの高いエンジニアがテストする場合に、高速にテストを行い、気になる部分を確認することができる。

★短所
・スキルやドメイン知見の比較的乏しいエンジニアがどのようにテストすべきか分からない。
・テストのパラメータもしくはその組合せの抜けが発生する可能性がある。

ただ、スキルの高い(もしくはドメインに詳しい)エンジニアがテストを考えて実行するにしろ、具体的なパラメータを明確化したテストケースをつくることは、抜けの少ないテストを行うために重要となります。
そのため、ハイレベルテストケースから具体的なテストケースに落とし込むための作業を実施します。


■各ハイレベルテストケース単位でパラメータをマインドマップで整理

以下の作業は、各ハイレベルテストケース単位で実施します。
粒度の目安

1つのハイレベルテストケースからは1つもしくは少数のデシジョンテーブルが作成されると考えておいてください。
ここで、1つのハイレベルテストケースで考えるべき内容が多すぎるような場合には、複数のハイレベルテストケースへまずは分割を考えましょう。
パラメータが多すぎる状況では、整理やトレーサビリティの確認が困難になりやすいためです。
分割の目安

ハイレベルテストケースから、テストで確認する対象となるテストのパラメータを出していきます。ここでのテストのパラメータは、入力パラメータ、テストの事前条件、テストの結果のふるまい、出力の値…といったものを出していきます。
例えば、「予約をする」のハイレベルテストケースの1つである「曲Noで予約登録をする」に対するテストパラメータを整理した例を紹介します。
パラメータを整理

この検討は、階層構造的に整理するとやりやすいですので、マインドマップで検討をするとやりやすいです。
マインドマップの代わりにテスト技法「クラシフィケーションツリー法」を使っても良いでしょう。

パラメータの整理の段階で情報が少ない場合、複雑である場合などは前回紹介したような「参照モデル」を活用すると検討がやりやすくなります。
参照モデル活用

このパラメータ導出の段階ではテスト技法である「同値分割」を駆使してテストを整理することで、抜けの少ない内容とすることができます。同値分割を詳しく知りたい場合には秋山さん著の「ソフトウェアテスト技法ドリル―テスト設計の考え方と実際」がお勧めです。


■パラメータに論理性(有則)がある場合には、CFDでロジックを整理

導出した複数のパラメータ間には関連性が存在していることがあります。このように「有則」である場合には、パラメータの関連性を明確にするテスト技法を用いると効果的です。
ここで使用できるものは、CFD(Cause Flow Diagram)やCEG(Cause-Effect Graph)があるのですが、個人的に使いやすいことからCFDでの整理方法で説明します。

例えば、先ほどパラメータを整理した「曲Noで予約登録をする」においてロジックの組合せをCFDで表すと次の図のようになります。
パラメータからCFD

CFDの説明は行いませんが、パラメータの組合せのロジックは図を見ることで判断することができるはずです。

なお、CFDでのパラメータ整理結果はデシジョンテーブルで表現することで明確なテストケースとすることができます。
CFDとデシジョンテーブル

正確には上記のデシジョンテーブルからさらに次のような具体的な値を複数決めることもできますが、今回は省略しております。

★具体的な値の例(テスト技法「境界値分析」を考慮しております)
・再生可能期間内->再生可能開始の時分秒(2/28 10:00:00から再生可能で、その時間)
・再生可能期間内->再生可能終了の時分秒(3/10 23:59:59まで再生可能で、その時間)


■パラメータが無則の場合にはPairwiseでパラメータ組合せを整理

以下の条件に合致するような場合にはテスト技法「Pairwise(All Pair)」による2因子間の組合せ確認(2ワイズ)を使うと効果的です。
ここで「因子」という表現をしておりますが、「パラメータ」と置き換えた表現で理解して頂いて問題ありません。
Pairwiseでは「無関係だと思うパラメータの組合せ」を2パラメータ間という関係に絞り込んで網羅することができます。

★Pairwiseでの2因子組合せを使用する条件
※次のような条件が限られることを理解して使用することを推奨します。
・既に有則の組合せの確認を済ませている
・対象のテストカタマリーの範囲(例:予約をする)において多数のパラメータが存在している
・任意のパラメータ組合せが使用される可能性が有り、不安がある

「単にパラメータが沢山あるのでPairwiseの2因子組合せの確認を行う」は悪手となることが多いです。1つ1つのパラメータの不具合や、有則のパラメータの不具合の検出時に原因を発見することが困難となるためです。
不具合の可能性・リスクが低い時は「1ワイズ」での確認、リスクが高い時にはパラメータを1つ確認⇒有則のパラメータを確認…という方が効果的です。

さて、Pairwiseを用いた検討の例を紹介します。
「予約をする」における予約登録時のパラメータ関して整理を行います。これらを「PictMaster」というツールを活用してパラメータの組合せを導出します。
※PictMasterはPairwise(All Pair)を非常に使用しやすくするツールです。
無則のテストの検討例

ツールを用いて出てきた結果をテストケースとします。


■テストケースへの展開とテストケースの粒度

これまでで検討してきた結果をテストケースへ展開します。
テストケースへの展開においても「粒度」が存在しますので多少は意識してみると良いかもしれません。

例におけるテストケースのひな型では、テストカタマリー->サブテストカタマリー->ハイレベルテストケースという階層構造でまとめるようにしております。テストケースのひな型は以下を参考。
テストケースひな型と構造

テストケースへの展開例としては、以下のようにしております。
.妊轡献腑鵐董璽屮襦DT)と関連するテストケースはDTを参照として1つのテストケースに配置
 ※Pairwiseでのパラメータ組合せ表も参照として1つのテストケースとして配置しています。
▲魯ぅ譽戰襯謄好肇院璽垢ら表の作成無しに個々のテストケースをつくった場合はその内容を下階層に配置

…というようにテストケースを表形式としてまとめることができます。
テストケースへの展開例

既に述べたように、具体的な値(例:再生可能期間内->再生可能開始の時分秒)を設定したテストケースを最終成果物にすることもできます。テスト技法の「境界値分析」を行ってテストケースを決めると効果的です。
この場合、同一の同値クラス内で複数のパラメータ確認を行うため、テストケースが増える場合もあります。
パラメータ表現でのテストケース分割

「テストケースの粒度」は何となく決まっている場合が多いですが、テストケース数を大きく変化させる要素となります。そのため、具体的なテストケースの粒度に対しては確認しておいた方が良い場合が多いです。
(テストケース数の想定が数倍変わり、見積りが想定外となる可能性もありますから…)

なお、本シリーズのテストプロセスを行った場合にはテストケースまでの構造化は今までの進め方でそれなりに出来ておりますので、テストマネジメントツール(HP Quality CenterTestLinkなど)へ展開して管理することは比較的簡単にできるはずです。


■(参考)DFDとCFDの関連性

本シリーズでは「DFD(Data Flow Diagram)」と「CFD(Cause Flow Diagram)」という記法を用いての検討を活用しておりました。この場合、DFDで入出力と処理を詳細まで表現し、そこからCFDにてパラメータの組合せを表現する…ということも可能です。
DFDとCFDの関連

このような関連性をイメージして頂けると、今回の例で紹介したテスト設計も進めやすくなるはずです。


■まとめ

本記事ではハイレベルテストケースから具体的なテストケースに落とし込むテスト詳細設計の手順について紹介を行いました。
このような検討を経てテストケースは作られるものですので、単純にハイレベルテストケース相当の内容だけ定義を行い「探索的テスト」という表現でテストを進めたとしても、テストのスキルが無いと抜けが発生する…というのはイメージできるのではないでしょうか。

一連のプロセスに対する手順紹介は以上となります。
最後として、紹介した成果物の関連性とテストカタマリーの記法を活用するためのひな型を次回に紹介します。
| 技術 | 13:08 | comments(0) | - |









     12
3456789
10111213141516
17181920212223
24252627282930
<< September 2017 >>
+ SELECTED ENTRIES
+ RECENT COMMENTS
+ CATEGORIES
+ ARCHIVES
+ LINKS
+ PROFILE
+ OTHERS
このページの先頭へ