見出し画像

テストケースってなんなの?

はじめに

(宇宙単位では)先日、JaSST nano vol.1に発表させていただきました。
テストケースってなんなの?」というタイトルです。
この記事は補足でもないですが、この記事の結果、つよつよQAにブチ叩かれてボコボコにされてもへこたれない自信が出てきたので改めて書いてみようと思います。

テストケースに対して自信を持てなくなった

"テストケース"へのゆさぶり

きっかけはテスト設計コンテストU-30チュートリアルでした。
マイヤーズの三角形問題の回答として例示されたテストケースに違和感を持ったからでした。

1. 有効な不等辺三角形
2. 有効な正三角形
3. 有効な二等辺三角形

テストケースじゃないテストケース

私は「そんなの…テストケースなんかじゃないッ!!テストケースじゃ…!」って思いました。
参考までにISTQBの定義は以下です。

テストケース(test Case)
入力値、実行事前条件、期待結果、そして、実行事後条件のセットで、特定のプログラムパスを用いることや特定の要件が満たされていることを検証することのような、特定の目的またはテスト条件のために開発されたもの。

明らかにマイヤーズ問題の回答のテストケースはこの定義に当てはまりませんでした。なお原著にはテストケースの定義はありません。

テストケースにはどんなのがあるの?

しかし、よく考えると実際の現場には様々な定義があることに気がつきました。
😊「テストケースはExcelの一行なの!」
😌「テストケースは手順なの!」
😁「テストケースは組み合わせパターンなの!」
😺「テストケースはテストの1単位なの!」

また、テストケースの使われ方も色々あることに気がつきました。
😊 「1日200件テストケースを実施しているの」
😌 「1日1.5件でテスト実行見積しているの」
😁 「今日はテストケース10万件を作るの!」
😺 「テストケースは10時間やるの!」

実はいろんな表現があるテストケース

そうして過去の文献を探ってみました。
実は、"テストケース"というものは本によって色々な表現がされていることに気がつきました。

1.空の入力ファイル
2.題名レコードがない
3.1字の題名
4.80字の題名
5.質問が1つの試験

『ソフトウェア・テストの技法 第2版』p63  
『体系的ソフトウェアテスト入門』p177
とあるチームのテストケース
とあるテンプレートに沿ったテストケース

上記は比較的シンプルな例ですが、カラムとして様々なものを使っているテストケースもあります。例えば以下です。

  • テスト観点

  • テスト条件

  • テストアイテム

  • テストカバレッジ

  • テスト環境

  • テストデータ

  • 優先度

  • 担当者

  • テストの目的

  • 要素

  • 水準

  • heading

  • sub-heading

  • sub-sub-heading

  • sub-sub-sub-heading

テストケースには”意味”がある

そうして考えていくと、テストケースにはテスト実行における関心毎が表現されているのではないか?と思うようになりました。
2021年の私は以下のように整理しました。

  • テストマネージャがテスト計画書で考えたこととのトレースしておきたい

    • テスト観点

    • テスト条件

    • テストアイテム

    • テストカバレッジ

  • テスト環境作る人がテスト実行のために準備すべきことを書いておきたい

    • テスト環境

    • テストデータ

  • テスト実行管理する人が管理のしやすいようにしたい

    • 優先度

    • 担当者

  • 気遣い

    • テストの目的

テストケースを語ることでそのチームのテストが見えてくる

"テストケース"という言葉は、結構いろんな現場で見られます。ところが、テストケースの位置付けやテストケースのポリシーはチームによって異なるのではないか?と考えるようになりました。
例えば以下の切り口で考えられるのではないかと考えています。

  • 用途

  • 嬉しさ

  • 構成要素

  • 表現方法

  • 粒度/抽象度

  • テスト技法との関わり

  • テストプロセスとの関わり

  • テスト開発プロセスとの関わり

  • さまざまなしがらみ

  • テストケースの品質

  • それっていいテストケースなの?

  • そんなの…そんなのテストケースじゃないよッッ!!

結局やまずんはテストケースをなんだと思っているの?

ここからはJaSST nanoではお話ししていなかった部分です。
私にとって、テストケースの定義は「ソフトウェアの動作を一意に識別できる"こう動くだろう"と想定し、固有の価値があると思った仮説」です。
テストケースの構成要素については、なんでもいいと思っています。
ただ、テストケースは「そのテストを実行したら同じ結果が得られる」ことであることが合意できていないといけないと考えています。
そのため、ハイレベルテストケースもローレベルテストケースも同じ結果が得られるべきだと考えており、人によって動作が変わるということは許容しません。
人によって動作が変わってしまうリスクがあるならば、ローレベルテストケースを記載すべきだと考えています。

"固有の価値がある"とは、そのテストケース自体が実行されるべきモチベーションを持つことが必要になります。なんらかのテスト条件やテストの目的を持ち、なんらかをカバレッジしていることです。

テスト条件とハイレベルテストケースの違いは、「テストを実行するかどうか」と「実際の動作が定まっているかどうか」の違いであり、日本語の抽象度や粒度の話ではないと考えています。
なので、テスト条件はなんらかの手続きによってテスト値をカバレッジしたテストケースとしてお化粧され、テスト実行に活用されるべきだと考えています。

おわりに

気が向いたら推敲します。
また、もっと気が向いたらPart2を書きます。品質特性、テストレベル、承認プロセス、開発プロセスにおけるテストケース表現の使い分けについてです。

このツイートは今でも心の支えです。


この記事が気に入ったらサポートをしてみませんか?