はじめに
(宇宙単位では)先日、JaSST nano vol.1に発表させていただきました。
「テストケースってなんなの？」というタイトルです。
この記事は上記の内容を文書化したものです。
導入：「テストケース」に対して自信を持てなくなった経緯
"テストケース"へのゆさぶり
「私は本当にテストケースを理解しているのだろうか？」
そう思ったきっかけは「2テスト設計コンテストU-30チュートリアル」です。
上記のイベントにて、マイヤーズの三角形問題が出されました。
その時の回答として例示されたテストケースに違和感を持ったからでした。
以下のような内容です。
- 有効な不等辺三角形
- 有効な正三角形
- 有効な二等辺三角形テストケースじゃないテストケース
これを見て、当時の私は「そんなの…テストケースなんかじゃないッ！！テストケースじゃ…！」と思ったのでした。
その時想起していたテストケースとしては、ISTQBが定義はしていた以下のようなものです。
テストケース（test Case）
入力値、実行事前条件、期待結果、そして、実行事後条件のセットで、特定のプログラムパスを用いることや特定の要件が満たされていることを検証することのような、特定の目的またはテスト条件のために開発されたもの。
マイヤーズ問題の回答のテストケースはこの定義に明らかに当てはまっていません。
また、なお原著にはテストケースの定義はありませんでした。
テストケースにはどんなのがあるの？
しかし、よく考えると実際の現場には様々な定義があることに気がつきました。
- 😊「テストケースはExcelの一行なの！」
- 😌「テストケースは手順なの！」
- 😁「テストケースは組み合わせパターンなの！」
- 😺「テストケースはテストの1単位なの！」
また、テストケースの使われ方も色々あることに気がつきました。
- 😊 「1日200件テストケースを実施しているの」
- 😌 「1日1.5件でテスト実行見積しているの」
- 😁 「今日はテストケース10万件を作るの！」
- 😺 「テストケースは10時間やるの！」
実はいろんな表現があるテストケース
そうして過去の文献を探ってみました。
実は、"テストケース"というものは本によって色々な表現がされていることに気がつきました。
ソフトウェアテストの技法 第2版の場合
1.空の入力ファイル
2.題名レコードがない
3.1字の題名
4.80字の題名
5.質問が1つの試験『ソフトウェア・テストの技法 第2版』p63
この場合は期待結果なのか、入力値の性質なのかがわかりませんが、古いテストの書籍ではこのように記述されています。
体系的ソフトウェアテスト入門の場合
TC-01 残高が300ドルある有効な口座から20ドルを引き出す。
TC-02 残高が300ドルある有効な口座から25ドルを引き出す。注：これは無効値をテストするものであり、エラーメッセージが返されるべきである。
『体系的ソフトウェアテスト入門』p177
これについては入力する値や手順などが記載されていますが、期待結果等は記載されていませんね。
テストケースの構成要素
上記は比較的シンプルな例ですが、カラムとして様々なものを使っているテストケースもあります。
例えば以下です。
- テスト観点
- テスト条件
- テストアイテム
- テストカバレッジ
- テスト環境
- テストデータ
- 優先度
- 担当者
- テストの目的
- 要素
- 水準
- heading
- sub-heading
- sub-sub-heading
- sub-sub-sub-heading
テストケースには”意味”がある
そうして考えていくと、テストケースにはテスト実行における関心毎が表現されているのではないか？と思うようになりました。
2021年の私は以下のように整理しました。
- テストマネージャがテスト計画書で考えたこととのトレースしておきたい
- テスト観点
- テスト条件
- テストアイテム
- テストカバレッジテスト環境作る人がテスト実行のために準備すべきことを書いておきたい
- テスト環境
- テストデータテスト実行管理する人が管理のしやすいようにしたい
- 優先度
- 担当者気遣い
ちなみにテストケースの意図についてはWACATEでも取り上げていますね。
テストの目的テストケースを語ることでそのチームのテストが見えてくる
"テストケース"という言葉は、結構いろんな現場で見られます。
ところが、テストケースの位置付けやテストケースのポリシーはチームによって異なるのではないか？と考えるようになりました。
例えば以下の切り口で考えられるのではないかと考えています。
- 用途
- 嬉しさ
- 構成要素
- 表現方法
- 粒度/抽象度
- テスト技法との関わり
- テストプロセスとの関わり
- テスト開発プロセスとの関わり
- さまざまなしがらみ
- テストケースの品質
- それっていいテストケースなの？
- そんなの…そんなのテストケースじゃないよッッ！！
結局やまずんはテストケースをなんだと思っているの？
ここからはJaSST nanoではお話ししていなかった部分です。
私にとって、テストケースの定義は「ソフトウェアの動作を一意に識別できる"こう動くだろう"と想定し、固有の価値があると思った仮説」です。
テストケースの構成要素については、なんでもいいと思っています。
ただ、テストケースは「そのテストを実行したら同じ結果が得られる」ことであることが合意できていないといけないと考えています。
そのため、ハイレベルテストケースもローレベルテストケースも同じ結果が得られるべきだと考えており、人によって動作が変わるということは許容しません。
人によって動作が変わってしまうリスクがあるならば、ローレベルテストケースを記載すべきだと考えています。
"固有の価値がある"とは、そのテストケース自体が実行されるべきモチベーションを持つことが必要になります。なんらかのテスト条件やテストの目的を持ち、なんらかをカバレッジしていることです。
テスト条件とハイレベルテストケースの違いは、「テストを実行するかどうか」と「実際の動作が定まっているかどうか」の違いであり、日本語の抽象度や粒度の話ではないと考えています。
なので、テスト条件はなんらかの手続きによってテスト値をカバレッジしたテストケースとしてお化粧され、テスト実行に活用されるべきだと考えています。
おわりに
本記事は基本的には推敲しません。
気が向いたらPart2を書きます。品質特性、テストレベル、承認プロセス、開発プロセスにおけるテストケース表現の使い分けについてです。
また、普遍的なテストケースに対する価値観については別の媒体で話せればいいと思っています。
このツイートは今でも心の支えです。
これはホントにマジでよい考察。 #jasstnano
— Yasuharu NISHI (@YasuharuNishi) 2021年6月15日
