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

　「その6」の続き、最終回です。

www.kzsuzuki.com

　標準ダッシュボードとカスタマイズについて言及できればと考えていたのですが、「それっぽいダッシュボード」の作りこみに時間がかかりそうなので、やめておきます！
　最終回は、偶然見つけたPractiTestのバグと、テスト管理ツールに対する考えをまとめておきます。後半、もはやPractiTest関係ない。

PractiTestの不思議なバグ

　端的に言うと、「テストケースをインポートすると、謎の文字列が付加される」というものです。漢字を含むテストケースであれば再現性は高いので、PractiTest社側でも既知の事象とは思います。
　インポートするテストケースはこんな感じ。ユースケース(笑)としては、これまでExcelで作っていたテストケースから、PractiTestにインポートしてみるというものです。つまりExcelファイルを自分で作っている（PractiTestからエクスポートしたものの再インポートではない）。

テストケース#2以降は適当

　まず、インポート自体はあっさり成功。インポート機能ってぶっちゃけ、「2～3回は特定困難なエラーが出て、原因追及しながらようやく成功する」というイメージなので、さくっと成功するのは本当に安心感があります。
　ですが、インポートした結果はこんな感じになります。

末尾に付加される謎の文字列

　カギツカカギア？？？ 何語だ？

　・・・よくよく見てみると、文字列の最後に漢字のフリガナが付加されているんですねえ。「鍵」「使」「鍵」「開」で「カギツカカギア」です。
　Excelファイルに記録されたフリガナの情報だと思いますので、インポートしたExcelを調べてみましょう。PHONETIC関数で、文字列からフリガナを抽出すると、こんな感じ。

PHONETIC関数でフリガナを取り出す

　漢字の上についたフリガナが、余計に付加されてしまっているようですね。試していませんが、ほかのインポートでも同じことが起こるのではないでしょうか。

　PractiTest社の方が読んでくれることを期待して、つたない英語で事象を残しておきます。

After importing tests from an xlsx file including Japanese "kanji" characters, unexpected strings are added after each text in imported tests.
These strings seem to be phonetic of the kanji characters.

　これがバグなのか、何か意図しての作りで回避できるものなのかはわかりません。まあバグだとしても、元の文字列は残っているの で、インポートしたものを使いながら直せばいいでしょう。悪用の可能性は・・・うーん、あるかなあ？ Excelの読み仮名は修正できるので、そこに長大な文字列を埋め込んでおくとか？

　ちょっと面白かったので、ご紹介でした。

テスト管理ツールにまだ足りなさそうなもの

　個人的には、テスト管理ツールがテストについて万能である必要はない、と考えています。
　たとえばイシューの作成はテストに関係する活動ですが、それを得意としているチケット管理ツールがすでに安定して運用されているのであれば、テスト管理ツールでがんばる必要はありません。両ツールで双方向の連携ができれば十分です。
　自動テストも同様で、テスト管理ツールが自動テストを駆動する必要は必ずしもなく、自動テストシステムから情報を抜いてこられればいいと思います。

　ソフトウェア開発ツール群において、わたしがテスト管理ツールに求める立ち位置は

1. テストに関するアクティビティのうち、他のツールでカバーできないものを機能としてサポートする。
2. 同、他のツールでカバーできるものは、APIなどを通じて情報を集めてこられる。
3. 他のツールから情報をとるためのインタフェースをもつ。

といったところです。

　b.は上で述べた通り。c.は、自分が他ツールからデータを集めるだけでなく、自分が他ツールに渡すこともできるべきということです。もちろんPractiTestは、両者をよく満たしていると思います。

　ではa.はどうでしょう。
　PractiTestに限らずテスト管理ツールがメインでサポートしているのは、「テスト実装」と「テスト実行」（イシュー管理を含む）です。逆に、JSTQBでいうところの「テスト分析」と「テスト設計」はカバーしているとは言いづらいでしょう。
　「要求」を管理することはできますが、それはあくまでテストケースの導出元として関連付けを行い、テストのカバレッジを測定することが目的です。要求間の構造があるわけではなく、あくまでもテストケースとの親子関係のみ。
　テスト観点の十分性や関連については別の何かで行うことが暗黙の前提であり、テスト管理ツールを適用する段階では、要求と観点がすでに十分に抽出・整理されていることを意図しているように思えます。

　テスト設計も同様です。
　「要求」と「テストケース」は関連づいていますが、その間をつなぐ「どのようにこのテストケースを導いたのか」「どのような網羅性があるのか」という情報をカバーできていないように思います。そこには、表だったり図だったりが入ってきがちなので、テキストだけだと心もとない部分ですよね*1。

　ということで、テスト分析やテスト設計を統一的に扱えるツール*2がテスト管理ツールはに統合されたら、最強だと思います。

おわりに

　以上、PractiTestという素晴らしいテスト管理ツールをネタに、テスト管理について自分の言いたいことを言うシリーズでした。無計画に始めたので構成も何もぐちゃぐちゃですが、直す気は特にありません。

　最後に突然のフォローのようですが・・・、
　PractiTestは、テスト管理ツールが標準的に備えている機能はもちろんのこと、現場で直面する課題を解決するための機能も含めて手堅く押さえた、充実したツールだと感じました。そもそも使い方に迷うことが少ない作りに仕上がっているのですが、公式Web、動画、オンラインヘルプデスクを整備して、「使うのを諦める」ことがないように工夫されています。おかげでこのシリーズも、だいぶ楽しむことができました。
　すでにメジャーなツールなのでわたしが言うのもおこがましいですが、テスト管理ツール導入の際は有力な選択肢の一つになることは間違いないです！

　 PractiTest社のみなさま、トライアルさせていただきありがとうございました。

*1:そもそテスト管理ツールが意図している管理対象は、パラメタの網羅性を気にするような単機能のテストではなく、UATのようなシナリオっぽいテストなのかもしれない。それより前のテストレベルのテストは自動化が前提で、手順や期待値を人間向けに書き下すような必要はないと。

*2:そもそもこれが存在するのか？という疑問はさておく。

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

　「その5」（イシュー作成）の続きで、インポート・エクスポートの話です。
　ただ「その5」でRedmine連携を試したので、先にSlack連携も試してみましょう。

www.kzsuzuki.com

　
　こちらもとても簡単です。すでにSlackにログイン中であれば、その中のチャネルから投稿先を選んで連携し、そのあと投稿内容を選択します。Slack側でも連携を承認する必要があります。

試用期間が残り9日に迫っている。

　この設定で、テストの開始→途中で失敗→イシュー作成 をやってみます。すると・・・、

すぐに投稿された。

　とても簡単ですね。まずはイシュー作成くらいを投稿させておくとよさそうです。*1

インポート・エクスポート

必要性と困難

　さて、テスト管理ツールがサポートしておくべき基本機能の一つが、「インポート・エクスポート」です。
　多くの組織ではすでに、テストケースという（場合によってはネガティブな）テスト資産をもっているはず。これを一括インポートできず、1件1件よなべして登録しなければいけないとしたら、テスト管理の移行などできるはずもありません。

　一方で、インポートの厄介さは想像に難くありません。
　テスト管理ツールでは、テストケースが0個以上のインスタンスに紐づき、インスタンスが0個以上のランに紐づくという、1:nの構造になっています。また、テストケースには1個以上のステップに紐づきますし、テストセットとテストケースはn:mで紐づいています。オブジェクト同士に複雑な関係があるということです。*2

　よって、Excelで扱おうとすると、データベースの「テーブル」に相当する表が何枚もできるうえに、それぞれの表がIDで関連づいていることになります。この関連付けを保ったまま編集するのはなかなか困難であり、人類ではなくツールにお任せする部分でしょう。

ほしい機能

　わたしがテスト管理ツールに最低限求めるのは以下の点です。

1. 一通りの情報が汎用的な形式でエクスポートできること
2. エクスポートしたファイルと完全に同形式でなくとも、インポートが可能であること
3. インポートエラー時に、どこに原因があるかをある程度特定できること

　順にみていきましょう。

一通りの情報が汎用的な形式でエクスポートできること

　PractiTestでは、イシュー・テストケース・テストステップ・要件の4つがインポート可能です。
　また、イシュー・テストケース（＋ステップ）・要件・実行・テストセットの5つと、添付ファイルがエクスポート可能です。*3

CSVの作成は2時間に一度まで。

　ここでは、一番利用するであろうテストケースを試してみましょう。「Export All Tests」で生成が始まります。
　生成されたファイルはこんな姿。

CSV形式で出力される。

　小さくてわかりづらいのですが、少し意外な姿でした。
　Squash TMでは、テストケースの大元が1枚のシート上にあり、テストステップは別のシートにあって、テストケースのIDで関連づける形で管理していました（記憶あいまい）。一方PractiTestでは、ステップも含めてテストケースを1枚のシート上で扱っています。このため、空白セルがたくさん現れる形です。
　後者の方が人間には扱いやすいのですが、取り込みの際のツール側のチェックがより大変な印象です。

　さて、エクスポートしたファイルはそのままインポートにも使いうるので、ファイル・表・列がそれぞれどんな意味・制約・関連を持っているかは、公式ドキュメントできちんと解説してもらいたいですね。これなしだと、試行錯誤でがんばるしかなくなります。
　たとえばSquash TMであれば、公式のWikiでかなり丁寧に書かれていまし、PractiTestでも丁寧なページがあります。

www.practitest.com

エクスポートしたファイルと完全に同形式でなくとも、インポートが可能であること

　エクスポートしたファイルをそのままインポートしてみましょう。
　インポート画面では、PractiTestにおけるフィールドと、CSVファイルの列の対応を決めたうえで、インポートします。つまり、PractiTestと関係ないオレオレxlsx形式でも、基本的にはインポートが可能なのです。ステキ。

列の対応付けを行う。

　なお上述の通り、エクスポート時にはテストケースとステップが一体化した1枚のシートなのですが、テストケースとステップを分離してのインポートも、「Importing Tests and Steps in two operations」という形でサポートされています。こういう「かゆいところに手が届く」のがPractiTestらしさですね。

インポートエラー時に、どこに原因があるかをある程度特定できること

　「インポートエラー！」とだけしか教えてくれないツールだと、テストケースが1,000個入ったファイルの後半500個を消して再インポートし、エラーが起きるかを確認・・・みたいな二分探索大会は始まってしまいます（そして原因が一か所とは限らない地獄）。エラー原因はちゃんと教えてほしい。

　ではさっきエクスポートしたファイルをそのままインポートしようとすると

・・・。

　するとエラーが出る。ですが、エラー内容はしっかり書かれており、切り分け可能です。
　まず1つ目のエラーは、Authorに相当する列に不正な値が入っているというもの。これは、インポートするExcelの1行目（ヘッダ）を無視するオプションにチェックを入れていなかったため、「Author」というAuthor IDでインポートしようとしたということです。ごめんなさい。ここには、eメールアドレスまたはスクリーンネームを入れる必要があります。
　2つ目のエラーは、ステップの名前が必須だということですね。PractiTest上では任意項目なので、エクスポート時に空だったのです。

　では修正してリトライ。

無事取りこめた。

　OKですね。

　ちと気になる点としては、手順付きテストとはフィールド構造の違う探索的テストをどう扱うかということなのですが・・。
　まずエクスポートした時点で、テストチャーターとガイドポイントの情報は失われているようです。そのままインポートしても、手順付きテストとして扱われました。まあ、「探索的テストを大量にインポートする」ことはあまりなさそうですし、実害は小さいでしょう。

インポートのもう一つの需要

　既存Excelからのテストケースインポートの他に、「テスト管理ツールで扱うたくさんのテストケースをいったんエクスポートし、Excelで一括編集したうえで、テスト管理ツールに戻したい」というものがあります。全体的な管理としては圧倒的に優れるテスト管理ツールでも、「1テストケースn画面」である以上、編集面ではExcelなどに劣ることもあるためです。

　ちゃんと調べ切れてはいないのですが、「PractiTest上にある既存のテストケースを、インポートするExcelで上書きする」ということはできなさそうです。とはいえこれは既存の情報を壊しうる危ない機能なので、なくていいかもしれません・・・。

　以上、インポート・エクスポートについても、手堅くまとまっていました。
　最後に「その7」で、ダッシュボードを見てみたいと思います。

*1:Redmineと一方向連携している場合、イシュー作成はSlack通知されませんでした。やはり双方向の設定が必要か。

*2:幸か不幸か、Excelの1行が1つのテストケースであり、そこに複数のランが含まれるようなExcel管理であれば、構造が単純になる。

*3:実行をインポートできないのは、Squash TMも同様だったように思います。

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

　「その4」（テスト実行）の続きです。*1

www.kzsuzuki.com

イシューの作成

　ステップで失敗した場合には、イシューを作成することができます。

「Fail & Issue」から遷移できる

　イシュー作成画面に遷移すると、タイトルや概要が自動的に埋められています。

テストケースからステップを自動引用している

　作成時点では、Descriptionの他、PriorityとTagsあたりを入力しておけばよいでしょう。

　ただ、イシューまでPractiTestで管理するかどうかは考える必要があります。一つのシステム内で完結するのはメリットではありますが、すでに安定しているチケット運用を大きく変えることになるとしたら厳しいでしょう。PractiTestは、RedmineやJIRAなどのチケット管理システムとの連携が可能なので、運用の継続性を考えると、連携機能を使うのがよさそうです。

他のチケット管理システムとの連携

　PractiTestの大きな特徴の一つが、他のソフトウェア管理システムとのIntegration（以降はあえて「連携」と呼びます）でしょう。
　連携のページから選べるインシデント管理システム（ここではBugtracker）は、かなりの数にのぼります。

インシデント管理システムだけでもかなり多い

　この記事では、Redmineとの連携を試してみましょう。
　連携先として、Redmineのデモサイトを利用させていただきます。運営者である、ファーエンドテクノロジー株式会社さんに感謝。

一方向と双方向の連携

　公式サイトによると、Redmineへの連携は、One-way（一方向）とTwo-way（双方向）の二つがあります。
　ざっくりいうと、一方向では、Redmineチケットの情報をPractiTestに登録しておくことで、PractiTestからRedmineにたどることができます。逆に言うとそれだけです。
　双方向は、Redmineチケット側の変更（の一部）が、PractiTest側にも反映されます。また、イシューの集計などは、双方向でないと反映されません。一方向でもチケットはインスタンスに関連づいているのですが、一方向ではイシューの件数としてカウントされないということです。*2

　まずは一方向から確認してみましょう。これが設定画面です。

設定する項目はこれだけ。一方向では「PT Field id」も不要

　イシューの作成方法は変わりません。「Fail & Issue」のリンクをクリックすると、デフォルトではPractiTest組み込みのイシュー作成画面に行くところ、設定後はRedmineのチケット新規作成にリダイレクトされる感じです。使っているブラウザがRedmineのユーザアカウント/パスワードを記憶していれば、そのままチケット編集ができます。PractiTest自体に、Redmineの認証情報を教える必要はありません。

見慣れたRedmineの画面

「伊藤 健太」さんは、このデモ用Redmineのダミーユーザかな・・・。

　加えて、PractiTest→Redmineの紐付けも手動で行います。上の例だと、チケットIDは22241なので、「Link existing issue」から紐付けを設定します。*3

　これによって、インスタンスや、その元であるテストケースに対し、イシューが関連付けられます。

2件紐づいた様子

　ただ先に述べた通り、一方向連携の場合は、Redmineで作成したイシューの件数は、PractiTest側で集計されない。

イシューを集計してくれない・・・

　こうなってしまう。ダッシュボード上も、0件扱いになります。
　片方向は設定が楽な分、PractiTestとRedmineの機能をフルに生かせない感じですね。

　公式ヘルプによると、双方向では以下のように説明されています。

Two-Way integration – works like the one-way integration with Redmine and in addition, displays in PractiTest the bug’s subject and status as it appears in Redmine, and also allows Redmine to update PractiTest (via a dedicated plugin) whenever the subject or status are modified.
ーーー
一方向の連携に加えて、サブジェクトとステータスが、Redmineで表示されるのと同じようにPractiTest側でも表示される。さらに、サブジェクトとステータスが変更されたら、専用プラグインを通じてRedmineからPractiTestを更新する。

　一文目がちょっと不自然な訳なのですが、つまり「PractiTest側で定義していないようなステータスでも、Redmineで設定しているように表示するよ」ということなんでしょうね。
　でも何より重要なことって、上にも書いた通り、「PractiTestで集計は、一方向だとできない、双方向ならできる」ことだと思います。Redmineにいくら起票しても、テストを一元管理するためのPractiTestに反映できないのでは意味がない。やはり双方向を使うべきでしょう。

　しかし！ ぼくにはPractiTest専用プラグインを追加できるRedmineがない。きみに聴かせる腕もない。
　一応PractiTestヘルプに、「トライアルで使えるRedmine環境ありませんかね・・・？」ってダメ元で聞きましたが、「ごめんね、ないんだ。自社の人に聞いてくれないか？」と、至極当然のご回答をいただきました。

　非常に中途半端な内容ですが、イシュー作成については以上です。
　「その6」のインポート・エクスポートに続きます。

www.kzsuzuki.com

*1:＜メモ＞「イシュー」と「チケット」をきれいに使い分けていないので見直す。

*2:PractiTestのJoelさんが直接ヘルプしてくださいました。感謝。

*3:逆に言うと、PractiTestを通じて作成したチケットでなくても、関連付けることができるようです。

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

　「その3」の続きです。

www.kzsuzuki.com

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

テストの開始方法

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

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

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

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

インスタンス画面で表示される図

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

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

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

note.mu

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

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

テストの実行

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

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

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

テストの編集

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

ステップを編集・追加・削除できる

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

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

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

進捗の把握

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

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

www.kzsuzuki.com

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

　「その2」の続きです。作成したテストケースを、実行に移していきましょう。

www.kzsuzuki.com

テストセットの作成

　テストセットについては、「その1」で説明しました。

www.kzsuzuki.com

　PractiTestにおけるテストセットとは、インスタンスの集合です。インスタンスとは、「テストライブラリに登録されたテストケースを選択し、実行対象として割り当てたもの」です。
　まあ、「実行するために選んだテストケースをまとめたもの」がテストセットですね。
　このテストセットは、用語はともかく、テスト管理ツールに共通的な概念です。一方、これを開発とどう関連付けるかは、テスト管理ツールによって色合いが出るようです。

　TestLinkでは、開発に関連づく「テスト計画」があって、そこにテストケースを割り当てていきます。 　Squash TMでは、開発に関連づく「キャンペーン」とそれを構成する「イテレーション」があって、テストケースはその両者に割り当てます。
　どちらにしても、まず「開発」というオブジェクトがあって、そこにテストケースを割り当てていくイメージです。

　PractiTestは少し違います。テストセットを作成する時点では、「どのバージョンのためのテストなのか」という情報はありません（たぶん）。

　テストセットを作成してみましょう。

　このように、「誰が」「いつから」「どのテストケースを」実行するのかといった情報のみです。 このテストセットをどのように個々の開発に関連付けるかがまだよくわかりません。そういう発想自体がないのかもしれませんが。

　事前に作成した3件のテストケースから2件選んで、インスタンスとして登録してみましょう。

「選択したテストを追加する」は左上でなく右下にあってほしい

　特に難しい画面ではなく、直観的に操作できそうです。
　ですが、それは現時点でテストケースが3件しかないからです。テストケース数が膨大になると、絞り込みのためには以下の二つのことが重要になってきます。

　一つ目。フィルタ・検索するための情報が、テストケースに適切に設定されていること。
　これは「その1」で少し触れました。タグやカスタムフィールドを使ってフレキシブルに情報を付与できる分、自由度を適度にコントロールした運用が必須です。検索精度を高めるためのルールを決めましょう。

　二つ目。フィルタ・検索を効率的に行う機能が管理ツールにあること。
　この選択画面でテストケースを絞り込めないと、膨大なテストケースを上から一つずつ見ていくことになるわけで、強力な検索機能が必要になります。
　しかし・・・残念ながらこの画面ではフィルタしかできない。PractiTestにおけるフィルタとは、「よく使う検索条件を保存しておいて、いつでも呼び出せるようにしたもの」です。逆にいうと、フィルタとして登録されていない検索条件を使うことはできない。たとえば先ほどテストケースに「ド正常」というタグをつけたのですが、そのタグで絞り込むことができません。
　もしかするとやり方があるのかもしれませんが、まだ見つけられていません。

　もう1点。
　「テストセットからテストケース選択」という動線だけでなく、「テストライブラリで選んだテストケースをテストセットへ追加」という動線もほしいのですが、テストライブラリからは「新しいテストセットの追加」しかできないように見えます。これもやり方があるのかもしれませんが。

　さて、テストケース2件をインスタンスとしてテストセットに追加すると、以下のようになります。

「スプリント1」という名前は、後から考えると適切ではなかった。

　画面の下部に、テストセットに割り当てたテストケース（＝インスタンス）が表示されています。また左上には、テストセットの実行ステータスを表す円グラフも見えます。現時点ではすべて未実行ということになります。

　これでテストセットの作成は終わりです。「その4」に続きます。

www.kzsuzuki.com