テスト管理ツール「Qase」を導入して脱Excelを図ってみた

参考になった

レビュー投稿日の情報になります

株式会社みらい翻訳 / yabo

チームリーダー / QAエンジニア / 従業員規模: 51名〜100名 / エンジニア組織: 11名〜50名

最終更新日2024/08/22投稿日2024/08/22

利用プラン

ツールの利用規模

ツールの利用開始時期

事業形態

StartUp

11名〜50名

2023年9月

B to B

B to C

導入の背景・解決したかった問題

導入背景

ツール導入前の課題

Qase導入前はExcelを使って、プロダクトごとにテストを設計・結果を記載していました。 QAチームから俯瞰して見た際に、以下のような課題が散見されました。

ファイルが無数に存在していて、かつ保管場所が点在しており、すぐに参照できない
プロダクトごと・テスト実施ごとに独自にフォーマットが発展しており、記載内容を標準化できていない
特にリグレッションテストのExcelファイルが肥大化し、作業効率が著しく悪い

どのような状態を目指していたか

Qaseのようなテスト管理ツールを導入することで、以下の効果を期待していました。

複数のプロダクトのテスト結果を一元管理し、テストに関する情報を集約・分析・他プロダクトに容易に展開可能な状態にする
ツール導入を契機にQA・テストのプロセスや成果物フォーマットを統一し、最適化された状態に近づける
Excelに起因する作業効率の悪さが改善し、エンジニアの作業モチベーションが上げる

比較検討したサービス

Excel (従来利用)
TestRail
QualityForward

比較した軸

1. 低コストであること

もともと使っていたExcelが実質無償のため、有償ツールでも高額でないことを最低条件としました。

2. UIを含めた利便性に優れ、開発チームにも受け入れられること

将来QAチームだけでなく開発チームにも使ってもらうことを視野に、開発エンジニアにも馴染みやすいUI・利便性であることを重視しました。テスト管理ツールはスプレッドシート型とチケット型に大別されますが、開発チームはJiraをベースとしたチケット駆動開発を実践しているため、テスト管理ツールもチケット型に揃えることにしました。

3. 他ツールとの連携など、拡張性に優れること

自動テストツールやチケット管理ツールなど、社で採用している他のツールとの連携を取りやすいことを希望していました。 APIが公開されており、ビルトインのインテグレーションが豊富なツールの評価を高くしました。

選定理由

比較的安価なプランが存在していたこと
チケット型の管理ツールの中でも、モダンなUIを採用していたこと
ビルトインのインテグレーションが豊富で、新機能開発も盛んなこと

導入の成果

ツール自体に期待するところとしてはおおむね達成・改善されたものと考えています。

複数のプロダクトのテストケース・実行結果をQase上に一元管理できた
Qaseを採用しているチームで一定のプロセス・フォーマットに従った運用を始められた
Excelに起因する作業効率の悪さが改善された (QAエンジニアからは「もうExcelには戻りたくない」というフィードバックも！)

残課題は後述しますが、ツール自体の問題というより自社の組織構造などに紐づくものが多いように感じています。

導入時の苦労・悩み

独立して利用できるツールのため、導入自体には苦労しませんでした。どちらかというと、レビュープロセスの整備やテストケースのメンテナンスなど、導入後に発生する運用上の課題の方が多いと思います。

導入に向けた社内への説明

上長・チームへの説明

上長・QAチーム向けの説明

現状のテスト管理における課題の整理
解決案としてのQaseの優位性
期待される費用対効果
- 「月単価が◯◯万くらいのQAメンバがいると仮定して、テスト設計・実行時に費やしている時間を仮に◯◯%削減できたら導入した方が得になる」という筋立てで話を進めました。
社内への展開方法
- まずはQAチーム内で運用を開始し効果を確認、次に開発チームも含めたパイロットプロジェクトへ展開、最後に組織全体としての導入を目指すという、段階的導入を試みることを説明しました。

開発チーム向けの説明

開発チームには導入が決まったあとにガイダンス的に説明をしています。

現状のテスト管理における課題の整理
Qaseというツールを導入することの報告
Qaseのハンズオン
Qase利用にあたってのディスカッション

活用方法

現在はQAチームメンバと一部のパイロットプロジェクトの開発チームメンバが、受け入れテストとリグレッションテストの設計・実行時に利用しています。

受け入れテスト(新機能周辺に対するテスト)

受け入れテスト駆動開発をベースとしたQAプロセスを採用しています。

比較的大きな機能の開発時には開発チームとQAが一緒に、小さめの機能開発時には開発チーム単独で、バックログの受け入れ基準(≒受け入れテストケース)をJira・Miro上で初期検討
開発チームまたはQAが受け入れテストケースをQase上に整理
QAがQase上で受け入れテストケースのレビュー
バックログが実装され次第、開発チームまたはQAが受け入れテストを実施してQase上に結果記録

リグレッションテスト(既存機能の変更がないことを確認するテスト)

QAが受け入れテストケースから重要なシナリオをピックアップし、リグレッションテストスイートにコピー
手動リグレッションテストの要求があるたび、開発チームまたはQAが受け入れテストを実施してQase上に結果記録

よく使う機能

テストスイート管理機能
テスト実行管理機能

ツールの良い点

複数のプロジェクトのテストを一元管理できる
フォルダ形式でテストケースを階層的に管理できる
フォルダ・ツリービューでテストスイートが見やすい
テストケースのフォーマットの設定自由度が高い

ツールの課題点

ユーザ単位の課金であり組織展開にコストがかかる
Jira連携による不具合管理はツールの完成度の問題で難しい
テスト結果のダッシュボードウィジェットの分析対象の設定自由度が低い

ツールを検討されている方へ

組織構造に応じて、テスト管理ツールをQAチーム内のみで運用する場合と、開発チームも巻き込んで運用する場合の2つのパターンがあるかと思います。私たちは段階的導入をしてその両方を経験したので、それぞれについての感想をまとめました。

QAチーム内のみで運用する場合

QAチーム内のみでの展開でよい場合には、Qaseのようなテスト管理ツールを早期に採用することをオススメします。多くの場合Excelより管理が楽になり、費用も試算をするとそこまでハードルの高いものではないためです。成果物の標準化もなされ、チーム全体の生産性向上・スキルアップにもつながるため、導入をするメリットのほうが多いように感じています。

開発チームも巻き込んで運用する場合

他方で開発チームへの展開をしようとすると、単にツールを入れただけでは解決しない障壁が数多くあることに気付きました。例えば、私たちは今も以下のような課題にぶつかっています。

【コスト面】テスト管理ツールはユーザ単位の課金形態が多く、利用人数が増えると比例して支出が増加する
【モチベーション面】開発エンジニアの負担が増える一方、QAに関する業務が開発エンジニアの成果と見做されにくい
【技術面】 QAのテストに関する知見が言語化できないと開発チームが再現できないため、QA側にスキルが要求される

ここに挙げたものはあくまで一例ですが、どの課題においても画一的な解決方法があるものではないように思います。開発チームの考えも伺いながら、より良い落とし所を探れるよう協力していくことが大事だと考えます。（弊社でも絶賛模索を続けている最中です！）

今後の展望

現在は一部のマイクロサービスチームでの運用が開始した状況のため、他のマイクロサービスチームにもツールを使ってもらい、運用に熟れていくことを当面の目標としています。将来的には、自動テストツールとのテスト結果統合や、集積されたテスト結果の分析、およびテスト設計へのフィードバックも進めたいと考えています。