テスト管理ツールの導入を検討するうちに、自分たちの抱える負債に気が付かされた話


with Advent Calendar 2024 10日目は、QAチームから杞憂([@kiyou77](https://x.com/kiyou77))がお送りします。

当記事では、現在with QAチームで導入を検討しているテスト管理ツールについて、導入後の運用を想像する中で考えたこと、学んだことについて書こうと思います。

導入自体はまだ決まっておらず、絶賛検討中といったところではあります。それでもツールを使うことを想像するだけで色々と思索が巡り、多くを学ぶことができました。その一端をシェアできればと思います。


### テスト管理ツールとは？

前提として、テスト管理ツールの説明を少しだけ書いておこうかと思います。そもそもテスト管理ツールというものを皆さんはご存じですか？

テスト管理ツールとは、テスト活動の全般を広くサポートしてくれるツールで、以下のような機能を持っています。

- テストケース管理
- テストバージョン管理
- テスト実行進捗管理
- 不具合記録・追跡
- テストレポート作成

「テスト活動のためのGitHubみたいなもの」と端的に説明されたりもしますね。

今日ではテスト管理ツール導入記事なども多く見かけるようになり、少しずつテスト管理ツールを利用する企業が増えつつある印象があります。

しかし、それでもまだまだ浸透しているとは言い難く、テストに関わる人間でもテスト管理ツールのことを聞いたこともない、という人は少なくないのではないかと思われます。

実際、GitHubがどの現場でも当たり前に使われているようには、テスト管理ツールはテストの現場で浸透しておらず、Excelやスプレッドシートのような表計算ソフトによって設計・管理されるのが主流です。

例にもれず、withQAチームにおいてもテスト設計はスプレッドシート上で行われてきました。しかし、ここに課題を感じており、テスト管理ツールの導入を検討しているところです。

### テストケースの再利用に対する課題感

我々の抱える課題感とは **「テストケースの再利用が上手くできていない」** ということです。

先述のとおり、私たちはテストをスプレッドシート上で設計し、書き残してきました。しかし、わりあい詳細にテストケースを書き残しておきながら、そのテストケースを再利用することはほとんどありませんでした。 [^1]

[^1]:テストの再利用性が低いことの要因は様々ありますが、根本的にはスプレッドシートの「ファイルを開いてみないとどんなテストケースがあるのか分からない」という参照性の低さが原因と思われます。
それに続く形で、参照しづらいので参照されず、参照されないので再利用性を意識したテスト設計やファイル整理のモチベーションが生まれず、より参照しづらいテストケースになる悪循環がありました。


現在のwithの開発プロセスでは、テスト設計者がそのまま実行までを担当することがほとんどのため、必ずしも詳細にテストケースを書く必要はありません。使い捨てる前提ならば、詳細に書かず、抽象度の高いテストケースにしたほうが、設計にかかるコストを抑えることもできますし、テストの柔軟性を高く保つことにも繋がります。[^2]

[^2]:「詳細なテストケース」「抽象度の高いテストケース」と書いているものはハイレベルテストケース・ローレベルテストケースのことを想定しています。ハイレベルテストケースとローレベルテストケースにはそれぞれ長所・短所があります。詳しくは[Test Analyst Syllabus](https://jstqb.jp/dl/jstqb.jpdlJSTQB-SyllabusALTA_V311.J03.pdf)を参照ください。
ここでは簡単に「ローレベルテストケースで使いまわす」「ハイレベルテストケースで使い捨てる」という2項対立のように説明していますが、必ずしもそうではなく「ハイレベルテストケースで使い回す」という選択肢もあり得るかと思います。むしろそちらのほうが、これからのwithQAチームの目指すべき形のようにも思われます。ただ少なくとも、スプレッドシートはそれを実現するためのツールとして適切であるとは思えません。この辺りは、もし上手く実現するやり方があれば是非教えていただきたいです。



そうした選択肢を取っている現場もありましょうが、withQAチームではあくまで再利用性を念頭に置いてテスト設計を行う方向性が良いと判断しました。その理由は、withというプロダクトが来年で10周年を迎えるほどの、歴史の長いプロダクトとなっていることにあります。

長い歴史の中でプロダクトの複雑性は既に高まっており、そして今後も成長に伴い高まっていくことになります。QAチームとしては、この複雑性の増大に対処するための体制を作る必要があります。

そこで、これまでリリース前に行ってきたリグレッションテストを、的を絞ることでより早く、実装完了後のフィーチャーの検証タイミングにシフトさせる戦略を取ろうとしています。そうした背景からも、既存のテストの再利用性を高めることが重要と考えました。




### チケット型とスプレッドシート型の比較

テスト管理ツールにおけるテストケース管理モデルは、大きく2つの方向性があります。ひとつはチケット型、もうひとつはスプレッドシート型です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3551524/05207fd9-a288-aa93-8bf2-2f17628bc22c.png)
[^3]

[^3]:画像は[「テスト管理ツール、提供者目線でのアプローチを語る」](https://speakerdeck.com/kjstylepp/tesutoguan-li-turu-ti-gong-zhe-mu-xian-denoapurotiwoyu-ru)から引用させていただきました。

それぞれのタイプからひとつずつ候補となるツールを選出し、実際にテスト設計を行ってみる形で検証を行っています。具体的にはQualityForward（スプレッドシート型）とQase（チケット型）を候補としています。

今現在スプレッドシートでテスト設計を行っているという点で、QualityForwardのほうがスムーズに移行できるという予想がありました。しかし、実際に触ってみると、QualityForwardでのテストの再利用はテストスイート単位となっており、テストケース単位で再利用ができるわけでないことに気が付きました。

アジリティを目指し的を絞ってテストを行うためにも、テストケース単位で再利用できるツールが望ましく、目的ベースで選ぶならQaseのほうが適切であると思われました。

### 実運用を想像することで見えてきた私たちの負債

一方で、Qaseを使うことを現実的に考え始めることで、新たに見えてきた課題もあります。それは**テストケースをどう構造化するか**というものです。

Qaseでは、テストスイートに自由に階層を付けて管理することができます。どのような形で階層付けるかによってテストケースの再利用性が変わってきます。ただ何も考えずにスプレッドシートのテスト設計書をインポートしていくのでは、期待するほど再利用性は高まりそうにありません。

私たちはテスト設計書のフォルダ分けなどしてこず、実行が終わったものから「済」という名前のフォルダに押し込め、管理することを考えないできました。テスト設計書自体も、異なる詳細度、異なるテスト観点を大項目・中項目・小項目の3つの列にはめ込んだ、いびつなテストを作ってきました。[^4]

[^4]:大項目・中項目・小項目の3つのレイヤーでテストケースを書く方法は「固定3レイヤー法」と呼ばれており、問題のある方法として批判があります。詳しくは次のスライドを参照ください。[「ちょっと明日のテストの話をしよう」](https://www.jasst.jp/symposium/jasst13kyushu/pdf/S5.pdf)
withQAチームのテストケースの作り方がまさにこの「固定3レイヤー法」の問題点を抱えていることは理解していましたが、具体的な支障は出てこなかったために許容してきました。しかし今回、再利用性を高めることを本気で考えたとき、ここが課題になってくるのを改めて感じました。


テスト管理ツールはテストケースの管理をサポートしてくれますが、管理自体を代わりに行ってくれるわけではありません。そしてテストケースの管理を、私たちはこれまでほとんど行ってきてきませんでした。ここの仕組みをちゃんと考えることは、いちから自分たちの頭でやらないといけません。

私たちが本当に必要だったものは、管理ツールではなく管理そのものだったのです。


### ツールを師として学んでみる

本当に必要だったものは管理そのもの。だったら管理しさえすればツールはいらないのかといえばそうでもなく。現実的にスプレッドシートとGoogleドライブのフォルダ分けで自分たちがやりたいことをやるには、かなり苦労することが目に見えています。ツールのサポートを受けられるからこそ「管理しよう」と思えるので、ツールの存在は前提になってくるかと思います。

これは本当に良い機会であると思われました。そしていま、テスト管理ツールの検討から一歩進み、その運用においてテストをどのように構造化すべきかの検討を行っています。ツールを使うために、これまでのやり方を見直し始めたわけです。

ツールは色々とサポートしてくれる一方で、「ここからは自分で考えるんだ」というような突き放しがあるなと感じます。しかし暗黙のうちに「どこに頭を使うべきか」を教えてくれており、これに従うことで自分たちのテスト活動が良くなるのではないかという光明のように感じられています。

あらゆるツールは、何かしらの世界観を持っています。それは過去の様々なベストプラクティスのパターン化されたものであり、ツールの想定されている使い方に沿うことで、私たちは蓄積されたベストプラクティスの一端に触れることができるのだと思われました。

もちろん、そうした世界観の合う合わないは現場によって異なるかとは思います。しかし、ツールの宿している蓄積からは、大いに学ぶものがあります。郷に入っては郷に従えといいますし、可能である限り愚直に従ってみることは大事なことかと思います。師に学ぶ弟子のように。私たちはツールを師とし、そこから学ぶ弟子になるのです。[^5]

[^5]:あらゆるものを師として学ぶ弟子であれ、というのは私が常々大事にしているスタンスで、以前それで記事を書いたことがあります。こちらもお読みいただけるとうれしいです。[師が欲しいあなたへ：あなたは師を得ることが出来ません](https://note.com/kiyou77/n/n58a7b695515b)

### まとめ

というわけで、ツールを使うことを検討する中で、いろいろなことに気が付かされた、というお話でした。

私たちはまだツールを使ってすらいず、ただ運用を想像してみているだけのこの段階で、既に自分たちの課題が何であったのかを突き付けられているため、使い始めることでより多くの得られるものがあるのだろうと感じています。

とはいえ導入が決まったわけでもなんでもないため、導入見送りとなる可能性もなくはありません。ですが、再利用性を念頭においてテスト観点を構造化することの重要性は、さっそく明日からも使える学びですので、全く無駄にはなりません。が、まあ導入まで持っていけるとよいなと現時点では思っています。

また、今回テスト管理ツールを中心に色々と書きましたが、書きたかったことはテスト管理ツールのことでも、テストケースの管理方法のことでもありません。「ツールからは多くを学べることができる」ということ、そして「ツールから学ぶために、愚直にツールを使ってみよう」ということです。これはテスト管理ツールに限らず、あらゆるツールに言えることと思います。

ツールは師です。師から学ぼう。12月なので、師はいま走り回っています。我々も走ろう。