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

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

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

 「その3」の続きです。

www.kzsuzuki.com

 テストケースの作成、テストセットへの割り当てと進んで、次は「実行」です。

テストの開始方法

 テストセットの画面右上の「Run Now」から、テストセット内のインスタンスを実行していくことができます。この場合は、並んだテストケース(のインスタンス)を上から実行していくことになります。また、一覧にあるそれぞれのインスタンスから「Run」で実行開始することもできます。
 TestLinkやSquash TMでは、テストセット内のインスタンスごとに担当者を割り当てるのですが、PractiTestではテストセット自体に担当者を割り当てるという考え方ですね。

f:id:kz_suzuki:20191122191756p:plain

 ふと思ったのですが、「インスタンスの順番を並び替える」機能はないのかしら。重要度やリスク、効率を考えて、並び替えられるとよいのですが。

「インスタンス」と「ラン」

 ここで、PractiTestにおける各概念の関係を理解するため、先の図を振り返ってみましょう。

f:id:kz_suzuki:20191123065159p:plain
インスタンス画面で表示される図

 インスタンスの下に、「RUN」(ラン)が2つずつぶら下がっています。これが意味しているのは、「テストセットの中で、同じテストケース(正確にはインスタンス)を2回以上実行することがある」ということです。実行前はもちろんランの数は0。初回実行でうまくいって、その後何もなければ、ランの数は1です。ですが、そのランがバグにより失敗した場合、修正後の再実行により2になるでしょう。  このように、PractiTestに限らずテスト管理ツールでは、「テストケース」「インスタンス」「ラン」を別のモノとして管理しています。

 ある意味当たり前のことですが、Excelによるテスト管理はこのあたりで山場を迎えてしまいます。Excelによる管理だと、インスタンスとランを区別しないことが多いため、「テスト結果欄」に再実行結果として「×→〇」なんて書かれちゃったりします。これでは集計もままなりません。

 インスタンスは、「テストインスタンス」という言葉の方がわかりやすいでしょう。テスト管理ツール「Quality Center」での定義が、湯本剛さんのブログで紹介されています。

note.mu

テスト実行の入力値、操作、期待値の比較結果(合格したかどうか)などの実績が入ったテストケースが、インスタンスです。

 PractiTestでは、これらの実績は「ラン」として管理される(はずな)ので、Quality Centerでいうテストインスタンスと、PractiTestでいうインスタンスは、厳密には少し違うかもしれませんね。

テストの実行

 さて、実行画面は以下のようになっています。  テストケースの情報とともに、Actual Result(実行結果)の入力欄と、各ステップの判定ボタンがあります。

f:id:kz_suzuki:20191123070241p:plain

 すべてのステップがPassed(パス)になればインスタンスとしてもパス。途中ならNOT COMPELETED。どこかで失敗したならFAILEDとマークされます。

 なお、実行開始した瞬間から、経過時間が測定されます。よって、回数を重ねるごとに、当該テストケースを実行するのにかかる見込み時間がクリアになってきます。これは地味ながら、テスト工程の工数見積もりに有効な情報になりそうです。

テストの編集

 気の利いた機能として、インスタンス実行中のステップ編集があります。
 テスト開始前に、完全に操作手順を書き下しておくことは難しいですし、無意識のうちに記述を飛ばしてしまったステップもあるかもしれません。テスト実行中に修正すべき点に気づいたら、その場で直すことができます。

f:id:kz_suzuki:20191123185211p:plain
ステップを編集・追加・削除できる

 この操作によって、PractiTestの各オブジェクトに何が起きているかを理解するため、上の図を振り返ってみましょう。

f:id:kz_suzuki:20191123065159p:plain

 ここで編集しているのは、あくまで「実行」(RUN)のみです。元のテストケースを直接修正しているわけではありませんし、過去の実行にも影響を与えません
 n回目の実行中に行ったステップ追加・修正が、n-1回目以前の実行にまでさかのぼって勝手に反映されると、履歴を壊すことにつながりかねません。n回目だけ「あえて」他の手順をとってみたといった際に、その記録が過去に影響を及ぼすのも困るでしょう。他の実行を修正したければ、それぞれの実行画面で行うのが妥当です。

 この機能によって編集した内容を、n回目以降の正しい手順としたければ、「Update Original Test」を実行すればよいです。元のテストケース自体に反映できます。
 ユーザとして理解しておくべきことは、「同じテストケースのように見えても、インスタンスレベルでは手順が異なっていることがある」という点です。

進捗の把握

 ここからテストセットに戻ると、以下のように円グラフが更新されています。

f:id:kz_suzuki:20191123070647p:plain

これじゃあっさりし過ぎなので、ダッシュボードなどはまた別に言及したいと思います。  「その5」では、イシューの発行を見ていきましょう。

www.kzsuzuki.com