テストケースの形式性について

テストケースの形式性

テストケースの特性である「テストケースの形式性」について記載します。
形式性という言葉はあんまり適した言葉がないのですが、しいていえば「formality」となるかと思います。

「この言葉を流行らしたいという」意図はありませんが、組織のテストケース改善を行なうときに、これらの概念が必要でした。
そこで、本稿では「こういう見方もあるんだな」くらいに思ってもらえればいいと思っています。

多様なテストケース

テストケースにはさまざまなフォーマットがあります。

典型的なものではISTQBのテストケースの定義があります。
「入力値」「事前条件」「期待結果」「アクション」「事前条件」のセットですね。

それ以外にも、たとえば第三者検証会社が提供するテストケースのフォーマットにはさまざまあります。
また、人によってテストケースで「必要」だと思う情報はさまざまです。

テストケースの型には、スプレットシート型・チケット型など、が識別されています。
どちらであれ、カラムや項目という形で現れます。

「入力値」「期待結果」は典型的なテストケースの形式ですが、場合によっては「テスト環境」「テストアイテム」などを記述する場合もあります。

これらを組織の標準として、どれくらい扱うか、その度合いを私は「テストケースの形式性」と名つけています。

テストケースの形式性の概説

テストケースの形式性とは、ざっくり言えば、テストケースのテンプレートに記載してある「項目」や「カラム」の数です。
これらは「テスト設計したときに記載しておいて欲しいこと」や「テスト実行時に記載しておいて欲しいこと」などが表されています。

多くの場合、組織単位で統一されたテンプレートが使用されます。

形式性の高さは高ければいいというものではなく、それぞれメリットとデメリットが存在します。

形式性が高いテストケースは以下のメリットがあります。

• テスト設計成果物の質をある程度制御できる
• テスト実行時に確定しておいて欲しいことをテスト設計段階から検討できる
• 組織のテスト成果物のアウトプットを揃えることができる

形式性が高いテストケースは以下のデメリットがあります。

• 単純にテストケースの作成に時間がかかる
• たくさん項目があると見づらい
• テストアイテム1,2,3などの複数のカラムを運用をしていると形骸化してしまう
• 特定のドメインやテストタイプに特化しすぎていることに気がつけない

テストケースの形式性を操る

テストケースの形式性の高さにはメリット・デメリットがあるので、組織の特性によりテストケースの形式性はコントロールする必要があります。
簡単な言葉で言うと、「複数のテストケースのテンプレートを意識的に使い分ける」です。

これらは組織の文脈によって使い分けることがマストで必要となります。
典型的な場合はテスターの人数や、テスト実行のスキルなどです。

組織の文脈のほかテストタイプやテスト技法によっても使い分ける余地はあります。
たとえば、機能テストでPass/Failとして記載していたカラムに対して、性能テストでは計測した時間N秒などのカラムに変更するなどです。

機能テストと非機能テストではテストアイテムの識別にも違いがあるので、これらの形式を調整することも必要になるかもしれません。

私の場合は、機能テストはスプレッドシート、探索的テストはテキストファイルなどで使い分けています。
また、テストケースの形式として、スプレッドシート形式にこだわらなくても、フローチャートやシーケンス図などのモデルを使ってもいいかもしれません。

同一組織で形式性を変化させることの課題

「テストケースの形式性をコントロールする」を行なうと、課題も存在します。

• テスト実行における組織内で一貫したモニタリング＆コントロールの手法が確立できない
• 画一的なテスト設計手法が適用できない
• テストにおける意思決定が未熟な場合、有効に活用できない

おわりに

テストケースの形式性を検討するにあたって、「テストケースってなんなの？」について触れざるを得ません。
これについては後日言語化して公開しようと考えています。