ソフトウェアの品質を学びまくる2.0

旧ブログからゆっくり移行中です。http://blog.livedoor.jp/prjmng/

1枚の2次元表で管理するテストケースについて


スポンサードリンク

 先日、Twitter「テスト手順とは何?」というテーマで議論したり、テストの人たちとテストケースのあり方みたいな四方山話をしたこともあって、id:kokotatataさんの、「2次元の表によるテスト管理の限界」というエントリーを読んで脊髄反射してみます。きれいにまとまっていないことをご承知ください。

kokotatata.hatenablog.com

テストケースとテスト手順

 id:kokotatataさんのエントリーでは、2次元の表に詰め込まれている要素として、以下のようなものを挙げています。

  • テスト環境
  • テスト観点
  • テスト条件
  • テスト技法
  • テスト事前条件
  • 期待値
  • テスト手順

 「テーブルを非正規化してしまっている」という表現されているように、これらの要素をベタに2次元の表に詰め込むと冗長性が増し、保守性が悪くなってしまいます。
 たとえば「発注」という機能を確認する際、「発注」画面に至るまでに「ログイン」を経るとして、テストケースごとに

ログイン画面のURLをアドレスバーに入力してエンターキーを押下。ログイン画面に遷移したら、[ユーザ名]テキストボックスに「user01」、[パスワード]テキストボックスに・・・

などといちいち書いていたら、発狂してしまいます。「ログイン」機能自体を検証したい場合でもない限り、ここは「ログインする」でいいでしょうし、画面遷移を気にしていないならそれすら書かないでしょう。
 もしこの粒度で手順を明示しておく必要があるならせめて、この手順は外出しにして、テストケースには「ログインする」という記述したうえで、外出しした手順を参照するようにする方がマシです。

 ただし、この「手順」の理想的な粒度は一概には決められず、画面操作自体を検証したいのか、機能を検証したいかによって変わってくるものと思います。*1

テストケースとテスト設計

 テストケースは、テスト実装の段階の成果物です。なのでテスト設計も、この2次元表に押し込めるべきではないですよね。

 単純な例ですが、「フィールドAとフィールドBで選択された文字列を結合して、1つの文字列として出力する」という機能があったとして。
 フィールドAの取りうる値がa1とa2、フィールドBの取りうる値がb1とb2だとして、AとBの全組み合わせをやろうとすると、こんなテストケースになるでしょう。

①A=a1, B=b1 → a1b1
②A=a1, B=b2 → a1b2
③A=a2, B=b1 → a2b1
④A=a2, B=b2 → a2b2

 でもこの4つを2次元表に4行分ベタ書きされても、「AやBの取りうる値は網羅されているのか」「AとBの組み合わせはどのような網羅になっているのか」は全然わかりませんので、レビュー不可能です。
 なのでこの実装に落とし込む前に、

Aの取りうる値はa1とa2であること Bの取りうる値はb1とb2であること

という事実・仕様と、

AとBが取りうる値のすべての組み合わせを網羅しようとしていること

というテスト設計の意図を、テストケースとは別に明示しておいて、それをレビューするべきなのだと思います。仕様変更があった場合は、このテスト設計に遡って修正する必要があります。

 ではこの設計の結果を、テストケースの表にどう反映するかということになりますが、個人的には、やっぱりこの「a1」とか「b1」とかいう具体的な値はテストケースに書きたくないです。テスト設計の方に、選ぶべき値と期待結果が整理されているのですから、二度同じことは書きたくない。ですから、テストケースにはテストの内容だけ書いておいて、具体的な値は「テスト設計のパターン♯1参照」などとするのがよいのでは、というのがわたしの意見です。

 先日テストの人たちとお話ししたとき、「テストケースの実装には、テストの意図は残っていなくてもいい。それはテスト設計に全部書いてあるから」という意見を聞きました。それを聞いたときは、ちょっと極端な気もしましたが、今では割とその意見に近い立場です。

テスト実装とテスト実行

 ところで、id:kokotatataさんのエントリーにある「2次元の表で管理されている属性」には、実は1つの共通点があります。それは、「テストケースそのものに関する情報である」ということ。
 一方、「テストケース フォーマット」でググってみれば、ここにさらに「テスト実行」の情報まで含めたものが出てくると思います。

 テストの実装とテスト実行が1行に詰め込まれているということは、極端にいうとそれぞれのテストが1回だけしか実行されないということになる。そうでないなら、1行に複数回の実行結果を記入することになります。実行結果も、実行日時も、対象のソフトウェアのバージョンも違うであろう情報を、1行に・・・。

 テストケースの実装と実行は、一対多の関係ですよね。本来はここも正規化する必要がある。
 しかしスプレッドシート、まあもっというとMicrosoft Excelでそれをやるのは相当なハイスキルExcel職人n人月が必要になるので、Excel管理学派はやむなく「非正規化」することで対処することになっていると思います。「やむなく」と言いつつ、すべての情報が1つの2次元表に収まっていることによるExcel集計のパワフルさとフレキシビリティから離れることは、なかなか勇気がいるのです。

 そこでテスト管理ツールExcelの共存共栄ですよ!
 わたしが求めているのは、TestLinkへのExcelインポート/エクスポート! TestLinkが吐いたXMLExcelで開くと、テーブル結合されて元の姿には戻せない・・・。よってインポートできない・・・。
 いろいろ探しても「無理だよ」「昔のマクロはもう使えない」情報ばかり。そんな悩みを解決してくれるTestLink学派の方からのお便り、お待ちしています! あるいはhpのQuality Center Enterprise試用版学派の方!?

www8.hp.com

*1:JaSST'13 Tokyoでの湯本剛さんの資料を見ると、ISO/IEC/IEEE 29119では「テストケース」の要素に「入力」があり、「入力」の要素に「アクション」があります。この「アクション」が先の「手順」に対応します。なお、ISO/IEC/IEEE 29119でいう「テスト手順」は、1つのテストケースの中での「アクション」とは違います。複数のテストケースの集まりである「テストセット」の中で、どの順番で実行するかを表したものなので、注意が必要ですね。