QA エンジニアの mikaty です。 テックタッチでは2023年7月からテスト管理ツールの Qase をスタートアッププランで利用しています。 Qase を利用するまで、スプレッドシートでテストケースの管理※1 を行っていました。 スプレッドシートと比較した時のテスト管理ツール全体のメリットは以下が挙げられます。 また、テストケースの件数が増加し、自動テストと手動テストを同じツールでモニタリングする必要性が高まりました。 ※1 ここで記載しているテストケースの管理とは、テストケースを作成し、テスト結果の入力と実施進捗をモニタリングすることです。 まず、社内のテストプロセスを俯瞰し、やりたいことを QA チーム内で話し合いました。 これまではスプレッドシートの関数や手動での記録を駆使して管理していたのですが、テスト管理ツールであれば、ある程度管理を自動化できることを期待しています。 今後の拡張性を見据えて、テストケースに属性を設定し、絞り込む機能が挙がりました。 これまでも、テスト対象の機能によって階層構造でテストケースを管理しており、スプレッドシートでの管理の際は機能ごとにシートで分割していました。 テックタッチは最新バージョン以前も保証対象となるため、どのバージョンに対するテストケースなのかを確認できる状態にしておく必要があります。 テックタッチのテスト自動化はまだまだ発展途上です。 特に重要視していたのが、変更履歴が確認できることと、Jira と連携ができることです。 前項で挙げた必要な機能を重視しつつ、候補として TestRail、PractiTest、QualityForward、Qase の4つのテスト管理ツールが挙がりました。 どのテスト管理ツールも甲乙つけ難かったですが、自動テストの連携がほとんど自動で行われ、圧倒的に操作が簡単だったことが決め手となり、Qase の採用に至りました。 テストケースの管理を Qase に移行してから1年経ちました。 Qase からはもちろん、プロジェクト管理ツールの Jira からもテストケースを関連付けすることができ、複雑な操作が不要だったことから情報の一元管理がしやすくなりました。 また、Qase 移行後にプロジェクト管理ツールを Jira から Linear に移行しました。 手動テストと自動テストの実行結果が同じツール上で管理されている状態になり、テストについて、プロダクトの開発を行うエンジニアとコミュニケーションが取りやすくなりました。 Qase では画面右上の吹き出しアイコンから問い合わせを行うことができます。 ここまでは Qase に移行して良かったことを記載しましたが、今後の課題と感じている点もあります。 テスト管理ツールの比較検討時に特に必要な機能として挙げたものの、最終的にできないことを許容した機能です。 これらの問題は運用でカバーできるよう模索中です。 Qase のキーワード検索は、Description（テストケースの概要説明欄）と Steps（テストの実行手順）を抽出することは可能なのですが、テストスイート名を抽出することはできませんでした。 テストケース名を簡潔に分かりやすくするため、同じテストスイート配下のテストケースからはテストスイート名で判別できる内容を省略したくなるのですが、省略するとキーワード検索で抽出することができなくなるというジレンマがあります。 Shared Steps は共通の手順を複数のテストケースで使いまわせる機能です。 残念ながら現状はあまり使えておらず、改善の余地がある状況です。 まだまだ課題もありますが、総合的に見ると、テスト管理ツールを Qase に移行して良かったと思います。 今回は QA チーム内からスプレッドシートでのテストケース管理について提案があり、Qase を採用しました。 テックタッチでは、今後もより良い開発者体験や品質向上のために挑戦していきます。
最近、キャベツの芯に砂糖水をあげていたら花が咲きました。
この記事では、テスト管理ツールを導入するにあたり検討したことと、Qase を選んだ理由と1年利用して分かったことについて紹介します。テスト管理ツール導入を検討するまでのテストケース管理
当初はスプレッドシートの自由度の高さがメリットとして大きく感じられていたのですが、プロダクトが成長するにつれて、テストを実行できる人員も増加したため、フォーマットやプロセスの型化が必要となりました。
これらの理由から、一元的な管理が可能なテスト管理ツールの導入を検討し始めました。
※2 テストを実行するためのテスト対象のテストケース一覧のことをテストランと呼んでいます。テスト管理ツールに必要な機能とは何か？を考えてみた
その結果をもとに、テストケース管理に特に必要な機能をピックアップしました。テストのモニタリングとコントロール
テスト実装
例えば、バージョン 3.7 で実装された機能の手動のテストケースのみを抽出したい場合は、事前にテストケースに「バージョン 3.7」と「手動」の属性を設定し、絞り込むことでテストランを作成します。
この階層構造を維持できるとテストスコープの選定やテストケースの修正時に情報が参照しやすいと考えています。
テスト実行
気軽にテストの PDCA サイクルを回すため、自動テストの実行結果を容易に確認できることは必須と考えていました。その他、プロセスを問わない機能
スプレッドシートでの管理の際は変更履歴や関連チケットとのトレーサビリティが取りづらい状況でした。
テスト管理ツールにあらかじめ機能として包含されていれば、運用時に必要なルールの設計もシンプルにできます。4つのテスト管理ツールを比較した
カタログスペックでの比較を行った後、実際にツールのトライアル期間を設けて使用感を比較しました。TestRail
PractiTest
QualityForward
Qase
Qase に移行して特に良かったこと
実際に移行してみて、良かったことを紹介します。チケットとテストケースの連携がスムーズだった
Linear に移行しても Jira と同じように、Qase の API 連携でスムーズに移行し不便なく使えています。
テスト自動化が進めやすくなった
元々別々の場所にあったテストケースが一箇所に集約されつつあり、より情報が俯瞰しやすい状態になっています。問い合わせ用のチャットが使いやすい
ヘルプページを見ても分からなかった不明点など、思い立った時に気軽に問い合わせすることができ、問い合わせに対する返信も早く、助かっています。Qase 移行後の課題
バージョンごとの管理ができない
バージョンごとの管理ができないと、テスト対象のバージョンが分かりません。これにより以下の問題が発生します。
現在は以下の運用ルールで管理しています。
キーワード検索でテストスイート名を抽出できない
階層構造のため、テストスイート名は対象のテストケースよりも抽象度の高い機能の名前や概要で作成されます。
テストケースの作り方次第で解決できる問題ですが、キーワード検索を有効に使うためには Description に抽出したい用語をあらかじめ記載しておくなど、工夫が必要です。Shared Steps を使いこなせていない
テストケース作成後に手順を修正したい時などに、Shared Steps で作成していると手順の修正が1回で済みます。
スプレッドシートからテスト管理ツールへの移行に際して、既存の共通手順を Shared Steps に登録することができませんでした。
また、Shared Steps を管理するための運用方法について、修正時の影響調査が煩雑そうであること、重複した Shared Steps が作成されてしまう懸念から運用ルール化に至っていません。
今後も引き続き、最適な使い方がないか模索していきたいと思っています。おわりに
何よりも、テストケースが客観的に参照しやすい資産となったことで、開発者と協業しやすくなり、プロダクトチーム全体で品質向上を目指せる環境が整ったことが大きな財産です。
本文でも触れましたが、テックタッチでは Jira にかわるプロジェクト管理ツールとして Linear を採用しました。この時も開発チームのメンバーが声を上げ、検討を経て導入に至っています。
志を共にできる仲間も募集中です。もし興味を持っていただけたら、ぜひ弊社の採用ページをご覧下さい。
