どしろうと製作所:WebLog

どしろうと製作所のBlogバージョンです。
「どしろうと製作所」のHPの記載内容とはあまり関係無いです。
気が向いたときのみ更新します。
テストケースの表現と粒度
ソフトウェアのテストを行う際に「テストケース」というのは重要です。
何を、どのようにテストをするかを明らかにしますし、多人数でテストを行う場合には確実に実施する手順となる場合もあります。また、テストの進捗を見るなどの指標に使われるかもしれません。

しかし、このテストケース自体の「表現方法(粒度も含めて)」が議論や意識されることは案外少ないと感じました。
今回はこの「テストケースの表現と粒度」について簡単に考えたことをまとめてみます。

こちらの記事はちょいとマニアックなので、「テスト技法」の知見がある人くらいがターゲットとなります。

■さまざまなテストケースの表現と粒度

注:実際のテストケースには、目的での分類や事前条件、合否判定基準、手順なども記載しますのであしからず。

例えばですが、次の「Javaly Park」の購入計算機能でテストケースを考えてみましょう。
※券売機の画面というイメージです。クリックで拡大。
30億のフレンズが待ってる

こちらは、「おとな」「こども」を選択して「計算」ボタンを押すことで、時間と種別から導いた(単純な)計算結果を画面として表示するというものです。

こちらの機能に対して、次のような表現のテストケースがあるかもしれません。

テストケース1:「購入種別と時間から計算結果を確認する」

対して、次のような複数のテストケースをつくる場合もあるでしょう。

テストケース2-1:「購入種別:おとな、入場時間:09:59:59で購入不可」
テストケース2-2:「購入種別:おとな、入場時間:10:00:00で結果1000円」
テストケース2-3:「購入種別:こども、入場時間:10:00:00で結果500円」
…(他にもあるよ)

さらには、次のような「1つの」テストケースの場合もあるかもしれません。

テストケース3:※以下のような文書が並びます
--------------
・購入種別:おとな、入場時間:09:59:59で購入ができないことを確認する。
・購入種別:こども、入場時間:10:00:00で計算ボタンを押し、
 計算結果が500円であることを確認する。
・上記で計算ボタンを押してから結果が出るまでの時間が3秒以内であること。
--------------

現場では、すべてが「1つのテストケース」と言われます。
上記テストケース1の「1つの」テストケースは、テストケース2の表現方法では10個のテストケースとなることもあるでしょう。


■テストケースの表現パターン

上記から簡単に「パターン」で考えてみることにします。

・パターンA.抽象的表現(テストケース1が対象)
こちらは、具体的な値が表示されていない場合になります。(他にもテストすべきものがありそうなのに)代表値だけテストケースとして記述している場合も対象としてよいでしょう。
曖昧で何をテストすべきかわからないことも多々あります。

・パターンB.値それぞれを明確に表現(テストケース2-Xが対象)
テスト技法と呼ばれるものを使用してテストケースをつくる場合、こちらのようなテストケースとなることが多いです。
具体的な値を定めた1つ1つをテストケースと呼びます。

・パターンC.手順的で混ざった表現(テストケース3が対象)
実施時を考慮しているかと思われます。操作失敗のケースを実施した後に操作成功のケースを実施して、さらにはレスポンス時間も確認するような、1つの手順で複数の目的を達成するようなテストケースです。
実施時には良いかもしれませんが、確認項目の抜け探しやメンテナンスはむずかしいです。

これ以外に、上記パターンA〜Cの混在というパターンも…。抽象的な場合と、明確な値まで記載されているテストケースが混ざっているものです。派生開発で担当者が変わり続けて使われる場合に見られそうですね。

他にもあると思いますが、今回はこの3パターン(特にパターンAとパターンB)を議論対象とします。


■上記パターンのテストケースで発生すること

上記のような抽象的な場合や、表現がバラバラな場合に発生することを考えてみます。

・抽象的なテストケースを使う場合に発生すること
テストケース1(「購入種別と時間から計算結果を確認する」)を考えてみるとイメージできますが、具体的なテストで使用する値はわかりません。
とある担当者は、結果が500円、1000円、800円、1300円になる4つのケースを確認してくれるかもしれません。他の人は、結果が1000円となるケースだけ確認して作業完了とするかもしれません。

このように、具体的なテスト実施が現場の担当者に委ねられることが多いです。「優秀な」テスト実施者はこの部分をカバーしてくれるので、重宝されるということもありそうです。
なお、前者の4つのケースを確認しても「時間外で購入不可」のケースが抜けておりますね。

・テストケースの粒度がバラバラな場合に発生すること
組織が大きな所では、「テストケース数」が何らかの指標に使用されることは多々あります。
例えば、「開発想定規模[kLine]」に対する「推奨テストケース数[件数]」といったものです。また、不具合検出数とテストケース数の割合を見ることもあるかもしれません。

ここで、前述したテストケース1とテストケース2の表現の違いでテストケース数は10倍近く変わります。
さて、「テストケース数」を使用する数値指標はどうなるでしょうね…
※逆に活用すると組織のプロセス審査を簡単にクリアすることも…ゲフンゲフン

以上のように、テストケースの表現と粒度の考え方1つでいろいろなことが変わってきます。


■テストケースの粒度をコントロールしよう

テスト実施の担当者によって、実施するテストが変わってしまうという状況を考慮すると「テストケースは細かい粒度でそろえましょう」となります。その方が、担当者がテストで急に追加されたような場合にも対応できますし、確実にテストすることができるでしょう。

しかし、実際にはすべてを細かい粒度のテストケースとして記述するのは面倒で時間が足りないような場合が多いです。

そのため、本記事では「テストケースの粒度をコントロールする」ことを推奨として記述しておきます。
相対的に「抽象的(テストケース1)」「具体的(テストケース2)」なテストケースが存在すると考えます。

テストケース1:「購入種別と時間から計算結果を確認する」

テストケース2-1:「購入種別:おとな、入場時間:09:59:59で購入不可」
テストケース2-2:「購入種別:おとな、入場時間:10:00:00で結果1000円」


これらは階層的な関連性を持っているといえます。そうすると次の図のようなツリー構造で示すことができます。
階層構造

この関係性と「どの抽象度であるか」をまずは把握できることが重要です。この「感覚」は上記のようなツリー構造を描く回数を増やすことで鍛えられます。

この「抽象度」の感覚を得た上で、テスト実施者によってテストケースの粒度を変えるということは可能です。
例えば、次のようなやり方です。

・繰り返しのリリースで毎回テスト実行して不具合を見つけている担当Xさんには、テストケース1の抽象的なものを渡す
・緊急リリースであまりシステムを知らない担当者Yさんが入ってテストする場合には、テストケース2の具体的なものを使用する

…という感じで、「粒度をコントロール」して使い分けることが役に立ちそうだとわかるでしょう。

現場には「手順的で混ざった表現」のテストケースが存在しておりますので、もうひと手間必要ですが、この考え方を知っていると役立つことも多いです。
たまに耳にする「探索的テスト」と呼ばれるテストに対してはどの程度のテストケース粒度・表現がよいか、ということも考えるとおもしろいかもしれませんね。

また、組織指標やプロジェクトマネジメントにてテストケース数を適切に扱う場合には、できる限りテストケース粒度を揃えることが必要ということもわかるでしょう。大事なことは、現在のプロダクト・プロジェクトの状況が把握でき、適切な対策判断ができることですので、そのために数値を活用するようにしましょう。


以上、テストケースの表現と粒度についての簡単な考察と意見でした。
そういえば、テストケースの粒度は以前紹介した「テストカタマリー」を用いると実際に揃えやすいです。興味があればこちらもご確認ください。

・テストカタマリーの紹介
・テストカタマリーを活用したテスト設計プロセス
| 技術 | 14:06 | comments(0) | - |









   1234
567891011
12131415161718
19202122232425
2627282930  
<< November 2017 >>
+ SELECTED ENTRIES
+ RECENT COMMENTS
+ CATEGORIES
+ ARCHIVES
+ LINKS
+ PROFILE
+ OTHERS
このページの先頭へ