Qaseで変わるテスト管理： Repository、TestPlan、TestRunの全貌

はじめに

ビットキーのSoftware QAチームでは、以前は主にGSS（Googleスプレッドシート）を使用してテスト管理を行なっていました。
2023年7月〜現在まで、Qaseというテスト管理ツールを導入し、テストケースの作成・実行を行っています。
Qaseを導入したことによって、テストケースの管理・整理が容易になったことや、テスト実行の全体の実施状況、機能毎の実施状況が視覚的に見やすくなるなど、以前より効率的にテスト管理が行えるようになりました。

そこで、テスト管理を行う中で使用頻度の高いQaseの3つの機能について、ビットキーでの使い方を交えて紹介していきたいと思います。

そもそもQaseとは

Qaseは、ソフトウェア開発プロジェクトにおける品質保証のためのテスト管理プラットフォームであり、手動および自動テストの管理、追跡、および報告を行うために設計されています。

以下のような機能を一元化して扱うことができます。

• テストケース管理：テストケースを作成し、整理し、蓄積することができます
• テストの実行：作成したテストケースを選択し、実行の結果を記録することができます
• 進捗管理：テスト実行の進捗状況を可視化し、管理することができます
• 不具合の報告起票：不具合を記録し、外部のシステムへ連携ができます

また、Jira、Slack、GitLab、GitHub、およびAsanaなど、多くの主要なイシュートラッキングやプロジェクト管理ツールとシームレスに統合できることが特徴的です。これにより、さまざまなツール間での作業の必要がなく、一つのプラットフォームで全てのテスト活動を管理できるようになるのです。
※ なお、ビットキーではJIRAと連携させています。

https://qase.io/

導入した当初の生の声

導入当初は使い慣れないのと、Qase自体の機能を知らないこともあり、今までできていたことができなくなったなどメンバーからは不満の声が相次いでいました。

例えば、「コピペで結果入力していたのを1ケースずつ結果を選択しないといけないのが面倒」など
※ 実際はチェックボタンでケースを選択することで複数のケースの結果を一度に入力することが可能でしたが、導入当初はまだ知りませんでした。

Qaseを使い続けていくうちに使いづらさは解消されていき、むしろGoogleドライブで管理していた頃より効率化できたこともあります。

そこでテスト管理を行う中で使用頻度の高いQaseの3つの機能（Repository, Test Plans, Test Runs）について、ビットキーでの使い方やQaseを導入して良かったことを交えながら紹介していきたいと思います。

Repository

Repositoryはテストケースを作成し、保管しておくメニューです。
Repository内は、”TestSuite”という大きい箱の中に、1項目ずつ”TestCase”を作成していきます。

ツリー構造になり、ドラッグアンドドロップなどで移動することができるので、テストケースの管理・整理が簡単にできます。

ビットキーでは以下のような構成でRepositoryを作成しています。

• マスターテストケース
  • リグレッションテスト（回帰テスト）
  • ユースケーステスト
• 新機能・機能変更
  • 確認テスト（リリースに含まれる修正の確認）
    • リリースバージョン（例：v1.0.0）
  • 改修テスト（不具合の改修確認ケース）
    • リリースバージョン（例：v1.0.0）

<Qaseにして変わったこと>

GSSで管理していたときに比べて、過去のテストケースへのアクセスが容易になりました。
過去のテストケースを確認したい場合、GSSの頃はフォルダを遡って探しに行く必要がありましたが、Qaseでは目当てのリリースバージョンの階層を開くだけでアクセスすることができます。

Test Plans

Test Plansはその名の通り、実施するテストケースをRepositoryから選び、実施予定のケースをPlan（計画）として一つにまとめておくメニューです。

ビットキーでは毎回のリリースごとに全てのテストケースを実施しているわけではなく、工数削減・効率化のためリグレッションテストは変更箇所の影響範囲にテストケースを絞って実施しています。

TestPlanで事前に実施するケースを選別し、一つにまとめておきます。

TestSuiteを選択することも、TestCase1つずつ選択することも可能です。

ビットキーではリリース毎に以下のTestPlanを作成しています。

• リグレッションテスト
• 確認テスト
• ユースケーステスト

テストの種類毎にプランを作っている理由は、後述のTest Runsを行う際にTestPlanからケースを生成しているため、一つのPlanにまとめてしまうと、全てのケースがまとまってしまい進捗管理がしづらいためです。

テストの種類毎に進捗状況を把握するためにPlanを分けて作成しています。

<Qaseにして変わったこと>

テストケースの選別をしやすくなりました。
特にリグレッションテストでは、リリース毎に不要なケース、必要なケースが変わってきます。
Repositoryのテストケースにチェックをつけるだけで実施するかしないかを選択できるので準備が簡単になりました。

Test Runs

Test Runsは、テストを実行するためのメニューです。
まず、「Start new test run」というボタンからTest Runを作成していきます。
実行するテストケースには、Repositoryから直接指定することもできますが、Test Planを選択することが可能です。

作成すると一覧画面に表示され、タイトルやステータスなどが表示されます。
テストの実行状況も”TEST RUN STATS”に表示され、実行結果毎のケース数などが表示され、進捗状況を確認することが可能です。

ビットキーでは、TestPlan毎にTestRunを作成しています。元々Test Planに含まれていなかったテストケース（改修テストや追加対応など）はRepositoryから直接ケースを指定して別途作成しています。

• 確認テスト
• 改修テスト
• リグレッションテスト
• 本番反映テスト（本番環境でのテスト）

TestRun内では、TestRun作成時に指定したテストケースが表示されます。1ケースずつテスターがケースの詳細を確認しながら実行していくことになります。
Testケースを開くと、前提条件、手順、期待値が表示され、実行結果を選択できるようになっています。
TestSuite毎に実行結果毎のケース数が表示されるため、機能毎の進捗状況なども確認できるようになっています。
また、テストケース実行にかかった時間が1ケースずつ自動で集計されるようになっています。ケースを開いてから実行結果を入力するまでにかかった時間が記録されていきます。

<Qaseにして変わったこと>

全体の進捗状況、機能毎の進捗状況が視覚的に見やすくなりました。
リグレッションテストなどの何度も実施するテストケースに関しては、RunHistoryというタブから過去の実行結果にすぐに遷移できるようになりました。
実施工数（実行時間）に関しては、テスターは手入力でかかった時間を入力していましたが、Qaseでのテスト実施に切り替えてからは自動で集計されるため、実施時間を気にする必要がなくなりました。

おわりに

Qase、使い慣れればとても良いツールだと思います！

• Repositoryにテストケースが蓄積されていきます。過去のテストケースへのアクセスが容易になりました。
• Test Plansで実施するテストケースを選択し、一つにまとめておくことができます。テストケースの選別が簡単になりました。
• Test Runsでテスト実施をしていきます。全体の実施状況、機能毎の実施状況が視覚的にわかりやすくなりました。

テスト管理ツールを検討中の方はフリーのトライアル版もあるそうなので、試してみてはいかがでしょう？