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

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

テスト管理ツール「PractiTest」を触りながら勝手にテスト管理を語る - その2

 「その1」の続きで、PractiTestによるテストケース作成の話を書いていきます。この感じだと、テストケース作成・管理とテスト実行の話だけで力尽きる予定です。PractiTestの真価はそこじゃないとは思うんだけれど・・・。

www.kzsuzuki.com

探索的テストのサポート

 PractiTestの1つの特徴として、探索的テストをサポートしている点があります。
 サポートといっても特別な機能があるわけではなさそうなのですが、手順付きテストと違う構成になっています。
 入力するのは、「テストチャーター」「ガイドポイント」の2つ。「探索的テスト研究会」のFAQでは、チャーターは以下のように説明されています。

チャーター(またはテストチャーター)とは探索的テストを実施する上での指針となる情報を記したものです。チャーターに記述される項目や情報の粒度は様々で、なにがしかの決まりがあるわけではありません。単に探索する範囲として機能を示した一言程度の非常にシンプルなものもあります。一方、テーマ、目的、優先度、データなど多様な項目をもつかなりボリュームのあるものもあります。

 下の入力例はチャーターとして適切かどうかわかりませんが、「こういうことやっておかしな挙動にならないか確認して」みたいなざっくりとした方針を示すものです。

f:id:kz_suzuki:20191122172656p:plain

 PractiTestではテスト実行時間が計測されていますし、また関連づくイシューにもトレーサビリティがあるので、「時間当たりのイシュー数」といった効率の測定も簡単にできそうです。

テストケースの「呼び出し」

 手順ありのテストケースの方に戻りましょう。ステップ追加のリンクの横に、「他のテストケースを呼び出す」という機能があります。

f:id:kz_suzuki:20191122172833p:plain
他のテストケースを呼び出せる

 テストケース#2のステップとして、テストケース#1を呼んでみると、こう。

f:id:kz_suzuki:20191122173343p:plain
呼び出した結果

 何が起きたかというと、テストケース#2のステップ#1に、テストケース#1がまるごと埋め込まれたということです。
 テストケース#1に書いたことを書き直さなくても、テストケース#2で流用できるのですね。

 これはとても便利そうですが、なかなか使いこなしが難しそうな機能です。テストケース間で呼び出し合うと、テストケース同士の依存性が強くなりすぎて、個々のテストケースの修正がとても難しくなりそうです。
 実際に実行するテストケース自体を直接呼び出すのではなく、「よくある手順」をテストケースの形で部品としてまとめておき、それをテストケースから呼び出すという使い方になるのではないでしょうか。これも明確な運用指針が必要な機能だと感じました。

 さて、こういう呼び出し機能を見たら、やりたくなるのはもちろん、「自分自身を再帰的に呼び出す」ですよね?
 テストケース#2から、テストケース#2を呼び出せるでしょうか? 呼び出せたとすると、テストステップ数は無限大になります。ワクワク。

f:id:kz_suzuki:20191122173009p:plain
ちっ・・・

 Test to call cannont call itself。だよねえ。

テストケースの「データ駆動化」

 もう一つ、細かい話。
 PractiTestは、テストケースのデータ駆動化をサポートしていないようです。*1

 データ駆動化のイメージを説明しておきましょう。
 まずテストケースは、以下のように一部の値をパラメタにしておきます。

ログイン画面で、ユーザ名に「<username>」、パスワードに「<password>」を入力して、「<button>」をクリックする。

 で、これとは別に「データテーブル」として、以下のようにパラメタと値のセットを管理します。

usernamepasswordbutton
空条承太郎oraoraoraログイン
ナランチャ・ギルガboraboraboraリセット

 操作手順と具体的な値を分離しているということです。「手順は同じなんだけれど、いろんな値を試したい」という用途で重宝する機能ですよね。自動テストの文脈ではData Driven Testingと呼ばれるものですが、手動テストでも成立する概念です。

 Squash TMでは、データ駆動化しておいたテストケースを実行に割り当てると、データテーブルの値が操作手順のパラメタに埋め込まれて、複数の具体的なインスタンスとして以下の二つのテストケースに展開されるという仕組みになっています。

  • ログイン画面で、ユーザ名に「空条承太郎」、パスワードに「oraoraora」を入力して、「ログイン」をクリックする。
  • ログイン画面で、ユーザ名に「ナランチャ・ギルガ」、パスワードに「boraborabora」を入力して、「リセット」をクリックする。

 なおPractiTestにも、似て非なる機能があります。データ駆動ではなく、単純なパラメタライズです。
 テストケース時点では以下のように、値を未確定にしておいて、

f:id:kz_suzuki:20191122174932p:plain
2つの中カッコで囲ってパラメタとする。

インスタンスとしてテストセットに割り当てた時点(あるいは実行直前)で、具体的な値を決定するという機能です。二つ以上のパラメタセットを持てるわけではなさそうです。

f:id:kz_suzuki:20191122175123p:plain
具体化しないと、実行時に怒られる

 もちろんこの機能も、直前までパラメタを決められないケースを考慮した、心憎い機能だと思います。
 データ駆動化も仕組み自体は似ているから、拡張してくれないかな・・・。

 テストケース作成はここまで。「その3」に続きます。

www.kzsuzuki.com

*1:もしかすると、Squash TMくらいでしかサポートしていない特殊な機能なのかもしれませんが・・・。