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

ソフトウェアの品質、ソフトウェアテストなどについて学んだことを記録するブログです。

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つのテストケースの中での「アクション」とは違います。複数のテストケースの集まりである「テストセット」の中で、どの順番で実行するかを表したものなので、注意が必要ですね。