はじめに

皆さん、元気にテストやってますか？
この記事では、弊社で取り組んでいるテストケース管理のより良い形を追い求めた活動のご紹介をしていきます。

なお、偉そうなタイトルを掲げておりますが、記事投稿段階ではスプレッドシートでの管理をしており、道のり半ばであることを予め理っておきます。

対象読者

プロダクトやシステムの運用に携わっている方
テストケースを表計算ツール（ExcelやGoogle スプレッドシートなど）で管理している方
テストプロセスの効率化に興味がある方

背景

本活動のきっかけとして、弊社のエンジニア組織がよりスピーディーな価値提供を実現すべく
設計・実装・テストなど全ての工程を一人のエンジニアでやっていこうという試みがなされています。

テストにフォーカスすると、今まではQAチームがテスト工程の責任を持っていたのですが、エンジニアに役割が移るということです。
ここで問題となるのが、エンジニアの誰でも均質的なテストを設計・実施できなくてはならないという点です。
特にテスト設計は、仕様理解やテスト観点に対する知見に依存する度合いが大きいため、テスト設計者によって品質が異なります。
そこで誰でも均質的なテスト設計ができる仕組み作りが課題として挙がってきたのです。

工程を分担している云々に関わらず、割とどのエンジニア組織でも恩恵を受けそうだなと思ったので記事にして誰かの役に立てばと思います。

試み

ソリューションとして、テスト管理ツールの導入が挙がりました。
テスト設計の均質化を実現するためには、ポイントが2つがあります。

各機能ごとのマスターテストケースを作成すること
マスターテストケースを開発全体で育てる土壌が整っていること

マスターテストケースとは、機能ごとに検証するべきポイントを汎用的に集約したテストケースの集合体のことです。
マスターテストケースの存在によって、ケースを引っ張り出して既存機能のテスト設計が容易に可能となります。
新規機能の場合はマスターテストケースの恩恵を受けづらいですが、既存機能への影響を検証するリグレッションテストやマスターからテスト観点を参照してテスト基準を知ることができます。
あとは機能開発や改修が発生する度にマスターテストケースをアップデートし続けることで、継続的に価値提供が可能となります。

これらを実現するための手段がテスト管理ツールというわけです。
テスト管理ツール導入をゴールとしたときに、3ステップに区切って進めているのでご紹介します。

STEP1：テストケースの集約

マスターテストケースを一から作成するのは、プロダクトの規模が大きくなるにつれて骨が折れる作業になってきます。
そのためマスターテストケースの元ネタ（データソース）として過去のテストケースを集めて、マージするのが有効かと思います。

弊社の場合、共有Driveや個人のローカルにテストケースが散在していたので、テストケースを集約しました。
ここでのポイントは機能単位でテストケースを置いておくことです。
マスターテストケースがマスターとして機能するためには、できるだけ細かい単位の粒度でテストケースをコンポーネント化して、それらを組み合わせることでテストケースを作り上げていくプロセスを実現したいです。
マスターをできるだけ細かく作るために、テストケース集約の段階で分割できているのが望ましいです。

STEP2：テストケースのマスター化

続いてマスターテストケース作りです。
集約したテストケースたちをマージし、足りないケースを補完していく作業です。
テスト管理ツールには便利なインポート機能がついているので、テスト管理ツールを先に決めて、インポートフォーマットに沿ったテストケースのマージをするとスムーズかと思います。

足りないケースの補完は凝り始めるとキリがないです。マスターテストケースは開発チーム全体で育てていくものという意識を忘れずに諦めの心も一定必要かと思います。
また、STEP1でも軽く触れましたが、テストケースを集約する単位はできるだけ細かい方が良いです。

ここまでできれば一次運用することが可能になるかと思います。
弊社ではスプレッドシートで作成したマスターテストケースをGoogleDriveに格納して、一次運用を開始しました。
プロセスはこんな感じです。

STEP3：テスト管理ツールの導入

STEP3ではテスト管理ツールを導入です。
テスト管理ツールでググってみると、たくさん種類があることが分かります。
チームと親和性があるツールを選定して見てください。

選定する上での基準や観点を記述しますので、ご参考になれば幸いです。

ツールの選定基準

・ケースインポートの簡易さ
多くのテスト管理ツールは既存のテストケースをインポートする機能が備わっています。
できるだけ手間をかけずにインポートを済ませ、ツールライクなプロセスのデザインに入れることが重要と考えています。
ちなみにテストケースの他にデータパターンに沿ってマトリクス状に管理する表（ディシジョンテーブルと呼んだりするっぽい）のインポートも選定基準に含めて検討していますが、こちらをインポートできるツールはすくないようでここだけスプレッドシートで管理する可能性が微粒子レベルで存在しています。。

・チケット管理ツールなどの連携
開発案件ごとにチケットを切ってアサインや進捗を管理している開発現場が多いと思いますが、チケット管理ツールとの連携も選定基準となります。
弊社ではPivotal Trackerを採用しているので、こことの連携ができるかを調査しています。

・メンテナンスのしやすさ
ケースのマスターをいかにしてメンテするか、マスターの直接編集できる人を制御できるか、テストケースをバージョン管理できるかといった観点です。
マスターテストケースを育てていく為には、エンジニアのみんながノーストレスでマスターを追加してもらえるフローを日々の開発業務に組み込む必要があります。
とはいえ誰も彼もがマスターを編集できて、それをチェックできないようでは、無秩序です。
GitHubのようにPRやapproveの機能（或いは類似した機能）が備わったツールを探しています。

・テスト実施の生産性が向上するか
テスト管理ツール導入によってテスト実施の生産性が下がってしまっては逆効果です。
実際にデモ環境を触るなどして、開発組織にあったツールを選定したいです。