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

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

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

OnlineTestConf Japanの開催が発表されました。開催日は2019年12月7日です。

 主催元のPractiTest社は、テスト管理ソリューション「PractiTest」を提供するイスラエルの企業です。チーフソリューションアーキテクトのJoel Montveliskyさんは今年何度か来日し、国内のいくつかのイベントでセッションをもたれています。たとえばコレ。 connpass.com

 SQiPシンポジウム2019でもブース出展されており、その際にトライアルをご紹介いただきましたので、少し触ってみました。PractiTestの紹介っぽさを装いつつ、テスト管理ツールに対する自分の考え方アッピールの場とします。

テスト管理ツールとは

 ソースコード管理、ビルド、インシデント管理といった、ソフトウェア開発の様々なアクティビティが専用のWebアプリケーションで行われる中、いまいち泥臭い「管理」から抜けきれないのが、テスト。特に手動テストです。
 いわゆる「テスト管理ツール」と呼ばれるアプリケーション群は、テストケースそのものや、テストケース実行、それに紐づくインシデントの管理をサポートするためのツールです。

 PractiTestもテスト管理ツールの一つで、公式サイトでは、「テストプロセス全体を管理する事のできる、総合テスト管理ツール」とあります。 www.practitest.com

 わたしはこれまで、国内で比較的よく知られているTestLinkと、JaSST'17で適用事例の発表があった、フランス製のSquash TMの二つのテスト管理ツールを使ってきました。その経験も踏まえて、PractiTestを見ていきたいと思います。

 なお、テスト管理ツールに関するわたしの考えについては、こちらにまとめています。

www.kzsuzuki.com

トライアルアカウントの作成

 必要事項を送るとメールが送られてきて、トライアルアカウントの作成ができます。

f:id:kz_suzuki:20191122162551p:plain
電話番号は必須にしないで~
f:id:kz_suzuki:20191122162705p:plain
「QA または ITディレクター」・・・?

 届いたメールのリンクから、トライアルを開始できます。するとすぐに、簡単なチュートリアルが始まります。

f:id:kz_suzuki:20191122162754p:plain
1分間チュートリアル

 テスト管理ツールの一般的な構造を理解している人にとっては当たり前の内容なのですが、そうでなければ「初めに何をすればいいか」から迷うかもしれません。右下にはチャットボックスがあり、簡単に問い合わせが行えるもよう。YouTube動画も埋め込まれたりしており、とにかく「よくわからないから止めよう」とならないための工夫が随所に施されています。

 ログインすると、最初のダッシュボード。まだ何も登録していないので、真っ白です。後で戻ってきましょう。

f:id:kz_suzuki:20191122163149p:plain
ダッシュボード

テストケース作成

 一般的なテストケース管理ツールが想定する理想的な流れだと、まず要件があり、その要件に関連づいたテストケースがあり、そのテストケースを個々の開発に割り当てていくということになるのですが、一番わかりやすいテストケースの作成からやってみましょう。

 Test Library(テストライブラリ)の画面では、管理対象となるテストケースの一覧が表示されます。まだ何も登録されていません。
 なおPractiTestでは、「Test Case」という用語は使っておらず、「Test」で統一しているようです。が、この記事では「テストケース」と呼ぶことにします。

f:id:kz_suzuki:20191122163431p:plain
このシンプルな構成と色遣いはプロっぽくて好き

 左にはフィルタ。よく使いそうなフィルタ、たとえば「自分に割り当てられたテストケース」などが、はじめから用意されています。カスタムフィルタも作成可能です。

 それでは、「New Test」ボタンからテストケースの作成を始めます。全体画面はこんな感じ。

f:id:kz_suzuki:20191122163719p:plain

 テストケースの情報は、3つのタブに分かれています。

「一般」タブ

 「一般」には、テストケースの概要・属性を入力してきます。テストケースの名前、説明、作成ステータス、タグ、添付ファイルといったものです。
 作成ステータスは地味に大事な情報で、そのテストケースをすでに実行に割り当てていいなら「Ready」、まだ作成中なら「Draft」、修正待ちなら「To Repair」、すでに使わなくなったものであれば「Obsolete」としていきます。

 タグは、なぜ必要なのでしょうか。
 TestLinkでは、テストケースをツリー構造で管理します。ですが現実には、テストケースをツリー構造で管理するのは困難です。
 たとえば「機能」でツリーを作るとして、ルート直下に「機能A」「機能B」とぶら下げたとすると、「機能Aと機能Bの競合のテスト」はどこにおくんだ?という問題にすぐぶち当たります。
 解決策は、「ツリーじゃなくてタグを使う」です。「機能A」「機能B」というタグを付ければいいのです。機能Aと機能B、どちらでフィルタしても、そのテストケースはヒットします。

 このあたりの思いは、以下の資料のスライドP.28あたりにあります。

www.slideshare.net

 タグは自由にいくつも付与することができるので便利ですが、いい加減に付けると検索の効果を発揮できなくなってしまいます。運用ルールをある程度決めておかないといけませんね。

 その右には、カスタムフィールドの追加ボタンがあります。組織それぞれでテストケースに付与したい属性があるので、これは嬉しい。
 たとえば、「品質特性」というフィールドを作って、値に「性能」を入れておけば、性能テストをさくっとフィルタできたりしますね(手動で性能テストをやるかは別として・・・)。
 ただこれも、「独自カスタマイズおじさん」が登場すると運用がぐちゃぐちゃになりかねないので、必要最低限のものに絞るのがいいと思います。

f:id:kz_suzuki:20191122164627p:plain

「ステップ」タブ

 次に「Steps」のタブです。名前の通り、テストのステップを入力していきます。

f:id:kz_suzuki:20191122164717p:plain

 ステップの概要、操作内容、期待値を書くことになります。
 操作内容がシンプルであれば、概要と操作内容が似たものになりますが、複雑になると違ってきます。記載の粒度をどのあたりにするかはチームで決めておくのがよいでしょう。
 たとえば、テスト対象ソフトウェア(SUT)への精通度合いをベースに考えるとわかりやすいです。

  • 概要だけ読めば、テストケースの全体の流れが理解できる
  • SUTをよく知っている人は、概要だけでテストケース実行ができる
  • SUTに不慣れな人でも、操作内容を読むことでテストケース実行ができる

という基準を満たしているかを考えながら書いていく、というのが一つの考え方になるでしょう。

 手順の並び替えはこのような画面で行います。

 

f:id:kz_suzuki:20191122165023p:plain
並び替えは別画面で行う

 ここに現れるのは概要の部分。よって、概要で「何をするのか」を必要十分に書いておかないと、並び順の妥当性がわからず、画面を行き来することになってしまいます。やはり、概要だけで流れが読み取れるかを意識するのがよいでしょう。

 もう一つの考え方として、キーワード駆動テストの実装の意識するというのもアリかもしれません。

  • 概要だけ読めば、テストケースの全体の流れが理解できる
  • 概要では、将来キーワードにできそうな一般的な表現で記載する。たとえば「画面Xを開く」はいろんな個所で使いそうです。
  • 操作内容では、キーワードを実装する際に必要になる細かい操作内容を書き下す。

 こうしておけば、キーワードの抽出と実装がやりやすくなります。

「トレーサビリティ」タブ

 次に、「トレーサビリティ」タブを見てみましょう。

f:id:kz_suzuki:20191122165339p:plain

 まず、わかりづらい「Instances」(インスタンス)から。
 「インスタンス」という言葉を使うかどうかは別にして、このような概念はテスト管理ツールに共通的なものです。PractiTestの考える論理関係は、以下のように示されています。

f:id:kz_suzuki:20191122165425p:plain
PractiTestの論理構造

 先ほど追加したテストケースは、「TEST X」と表現されています。そのテストケースを入れる箱がテストライブラリです。すべてのテストケースは、テストライブラリの中にあります
 ですが、そのすべてのテストケースを、毎回の開発で実行するわけではありませんよね。テストライブラリの中にあるテストケースを選択するわけです。実行対象として選択されたテストケースは、インスタンスと呼ばれますインスタンスの集まりがテストセットです

 上の図では、「TEST SET Y」の下に、二つのインスタンス「Y:1」と「Y:2」がぶら下がっています。インスタンスは、テストセットと、ライブラリ内のテストケース、それぞれに関連づいているため、トレースできることになります。

 あとの二つは特に難しくないですね。Linked Issuesは、そのテストケースに関連づいたイシュー。Linked Requirementは、そのテストケースの親となる要件です。
 テストケース作成直後は、まだテストセットへの割り当てもなく、実行もされていないため、トレースできる相手がいません。

 では、一通り入力したうえで登録してみます。

f:id:kz_suzuki:20191122165804p:plain

 ライブラリに戻ってきました。今登録されたテストケースが、一覧に表示されていることがわかります。  テストケースの再編集は、「Name」から行うことができます。テストケース自体のコピー・削除は、右のアイコンからです。

 すでに長くなってしまってので、「その2」に続きます・・・。 www.kzsuzuki.com