はじめに
今いるチームでは、モバイルアプリのリリース前の確認を手動テストで行っています。
テストケースの管理はずっとGoogleのスプレッドシート（以下スプシ）を使っていましたが、運用が破綻しかけていました。
そこで、ケースの管理はコードベースで行い、実施だけをスプシで行う形に切り替えたところ問題が解消しました。本記事では、具体的に何をやったのかを紹介します。
スプシ管理の辛かった点
これまではPR単位で実装者がスプシにテストケースを追加していました。追加する人やタイミングがバラバラなので、次第にスプシはごちゃごちゃになり以下の問題が起こっていました。
- 同じ確認をするケースが、別の書き方で複数できている
- 古いケースと新しいケースで期待値が矛盾している
- どのPRでどのケースが増えたのか追えない
開発中のテストでは特に困ることはありませんでしたが、リリース前に全体を通してテストしようとすると、見づらい上に何が正しいのかわからない状態になっていました。
さらにPRレビューでも、「スプシの◯行目にケースを追加しました」とリンクを貼り、該当行をハイライトする運用でした。そのため2人以上が同時にPRを開いていると、どの変更がどのPRのものか分かりにくく、レビューがしづらくなっていました。
ケース管理をコードベースに載せた
問題の根本は、誰でも自由に書き換えられる場所が正（信頼できる唯一の情報源）になっていたことだと思いました。
そこで役割をそれぞれ、「ケース管理はコード、実施はスプシ」というふうに分けることにしました。
| 置き場所 | 役割 | |
|---|---|---|
| ケースの定義 | リポジトリ内のYAML | PRでレビューし、CIで検証する |
| テストの実施・結果 | スプシ | テスターが○×と備考を記入する |
スプシには、マージ済みのYAMLから生成したxlsxを取り込みます。そのため、スプシにあるのは常に最新のテストケースです。
全体の流れは以下のとおりです。
1. ケースの追加・修正
2. 検証
3. PRレビュー
4. マージ
5. xlsx生成
6. スプシに取り込む
7. テスト実施
テストケースはYAMLで
cases:
- id: LIB-023
feature: マイライブラリ
viewpoint: 画面操作
precondition: ログイン済み
input: ライブラリ画面を下にスワイプする
expected: インジケータが表示されて最新の情報に更新される
スプシ時代にケースが荒れた反省から、書き方にもルールを決めることにしました。例えば、
-
idは一度振ったら変えない。 削除した番号も再利用しない -
inputには操作をひとつだけ書く。 「AしてBしてCを確認」は分割する -
expectedには観察できる結果を書く。 「正しく動く」のような検証できない書き方をしない
こういった最低限のルールに加え、シート構成・観点・対象端末は config.yaml にまとめました。なので端末を増やしても、判定列や集計が自動で追従します。
重複や矛盾をCIで弾く仕組み
検証はエラーと警告の2段階に分けました。エラーが1件でもあればCIが落ち、警告は統合を検討するための候補として表示します。
| 種類 | 内容 |
|---|---|
| エラー | 未知のキー（typo）、必須項目の漏れ、ID形式の誤りや重複、未定義の観点 |
| エラー | 前提条件・操作・期待値が実質同一のケース |
| エラー | 前提条件と操作が矛盾しているケース |
| 警告 | 同じことを確かめている可能性が高い類似ケース |
「実質同一」の判定では、全角半角や空白、括弧の違いといった表記ゆれを正規化してから比較します。機能名は比較に含めないので、別の機能名で登録された重複も見つけることができます。
矛盾の検出は、「端末を横向きにしている」が前提なのに操作が「端末を横向きにする」になっているような、前提で成立済みの状態を操作で作り直すケースを対象にしています。どの状態と操作の組み合わせを矛盾とするかは config.yaml にルールとして定義しています。
類似ケースは、期待値と操作の文字列類似度で判定しています。期待値が同じなら同じことを確かめている可能性が高いので、期待値を主、操作を従として見ています。ただし、前提条件が異なるペアは「条件を意図的に分けたケース」とみなして対象外にしています。意図的に似せているケースは設定ファイルに理由付きで登録すれば、警告を抑制できます。
このように人の目では見落としがちな部分を機械的に検証することで、人間のレビューはケースの内容に集中できるようにしました。
テストケースを作るAgent Skill
ケースの作成そのものも楽にするため、コードの差分から自動でケースを生成するAgent Skillを用意しました。
実際に作成したスキルの流れは以下の通りです。
- 実装の差分から、ユーザーに見える振る舞いの変化を洗い出す
- 既存ケースを全件読み、関連語で横断検索する
- 既存ケースと照らし合わせて、「追加しない／既存を更新／削除／新規追加」を判断する
- YAMLを編集し、検証でエラーと警告を0件にする
- 「追加したもの」「追加しなかったもの（根拠となる既存ID）」「変更・削除したもの」「人間に判断してほしい点」を報告する
ポイントは、単純に差分から新しいケースを生成するだけではなく、既存ケースと比較して本当に追加する必要があるかまで判断させていることです。
ただしAIが出すのはあくまでも根拠付きのたたき台で、最終的な過不足の判断は人間が行います。
xlsx生成とスプシ取り込み
レビューを通過したテストケースからxlsxを生成し、既存のスプシを丸ごと置き換えるようにしました。
丸ごと置換するため古いケースや手修正が残らず、常にきれいな状態を保てます。
一方で、以下の点には注意が必要です。
- 置換すると実施結果も消えるので、テスト実施中は取り込まない
- セルの保護は取り込みのたびに消えるので、Apps Scriptで定義列の保護を再適用する。保護は編集時に警告を表示する設定にしており、うっかり触ったときに気づけるようにしている
実際に運用してみて
まず何より、常にテストケースがきれいな状態なので全体テストをする際に迷わなくなりました。重複の多かった380件のケースが330件まで減り、書き方も統一されたことでテストの実施もしやすくなりました。
副次的な効果として、スキルによってテストケース作成の労力も大きく減りました。
また、テストケースがPRレビューの差分にそのまま載るので、レビュワーもレビュイーも負担が少なくレビューがしやすくなりました。
おわりに
スプシでのケース管理が破綻しかけていた原因は、信頼できる唯一の情報源が誰でも自由に書き換え可能になっていたことでした。
定義と実施を別の場所に分けたこと、検証を機械的に行うようにしたこと、AIにたたき台を作ってもらうようにしたことは特にやってよかったと感じています。
どれも特別な仕組みではないですが、組み合わせることでテストケースを常にきれいな状態にできるようになりました。
同じように手動テストケースに悩んでいる方の助けになれば嬉しいです。