LayerX QAマネージャーの中野@naoです。

アジャイル開発のスピード感とあるべき品質保証の両立、悩みますよね。私たちLayerXのQAチームも、日々試行錯誤を重ねています。今回は、その中でも『テストプラン』に焦点を当て、私たちがどのように考え、実践しているのかをご紹介します。

概要

私が所属するバクラク事業部では2週間サイクルでリリースを行なっており、リリース前の3営業日がテスト期間です。QAエンジニアはインプロセスQAとして、各プロダクト開発チームに入ってテストや品質に関わる活動をしています。

従来のテストプランは、テスト戦略、環境、データ、スケジュール、リソース、タスク、リスク管理といった多岐にわたる要素を詳細に網羅していましたが、プロダクトの開発プロセスやクリティカル度合いに応じ、記載項目や内容を柔軟に変化させる必要性が高まっています。

軽量型テストプランから『蓄積型』テストプランへの進化

軽量型の問題点

LayerXに入社後、私はいくつかの異なるバージョンのテストプランを作成してきました。まず初めに行ったのは、開発スピードに対応するために軽量なテストプランを作成することでした。軽量なテストプランは、スプリントの概要、テストアプローチ（どんなテストを実施するか、タスク管理）、その他必要最小限の情報で構成されていました。

例：軽量テストプランの項目

スプリント概要
テスト対象機能
テストアプローチ
- 実施するテストの種類（機能テスト、リグレッションテストなど）ごとのチケット

最初はこれで十分だったのですが、あるスプリントで複数人で連携してテストすることになり、情報不足を感じるようになりました。例えば、テストデータの有無を記載していないと、他のQAエンジニアが困る可能性があります。

さらに、本当に良いテストに仕上げるために現状考えているテストはプロダクトリスクをどの程度ケアできているのか確認できる必要がありますし、テスト活動の生産性の文脈ではテストベースや関連する情報を利便性が高い状態で管理したくなります。そのような思考の中で多岐にわたって考えられていた網羅的なテストプランの必要性を改めて感じるようになりました。

しかし運用面でスプリントごとに項目を追加・削除するのはコストがかかりますし、一度増やした項目を減らすことにも抵抗がありました。また、テストアプローチ（テスト分析の結果、どのようなテストを実施するかを定義したもの）は毎回変わりますが、そのアウトプットを再利用しづらいことにも違和感がありました。

そこで気づいたのは、テストプランには、継続して記載すべき項目と、ログとして残すべき項目があるということです。

継続して記載すべき項目: テスト戦略のコンセプト、テストデータ情報、プロダクトリスクなど
ログとして残すべき項目: 各スプリントのテストアプローチ、結果、仕様検討時のメモなど

重要なのは、「テスト計画を常に最新の状態に保つ」こと、そして「必要十分な情報」で運用することです。軽量なテストプランを毎回作って使い捨てにするのではなく、同じテストプランに情報を蓄積し、それを適切に絞り込みながら最新の状態に保てるように設計していく方向に考え方が変わりました。

Notionで実現する動的なテストプラン管理

弊社ではドキュメント管理にNotionを利用しており、テストプランもNotionで管理しています。Notionのデータベース機能を用いた動的なデータの管理によって、情報を蓄積しつつ、必要な情報だけを絞り込んで表示することが容易です。そこで、Notionを使って蓄積型のテストプランを設計していくことにしました。

例：Notionでのテストプラン管理

テストプラン内の情報をデータベースで管理
各開発期間毎のテストアプローチをチケットとして追加
- チケットには、テスト対象機能、テスト方法、担当者、結果などの情報を記載
ビューを切り替えることで、必要な情報だけを表示
- 「最新の開発期間」ビュー：直近のスプリントの情報のみを表示
- 「全開発期間」ビュー：過去の開発期間の情報も全て表示
リレーション機能を活用して、関連情報を紐付け
- テストデータとテストアプローチを紐付け
- プロダクトリスクとテストアプローチを紐付け

実際のテストプランのサンプル

上記でトグルが展開されている「Test approach & Activities」の部分がDBになっており、動的なデータ管理を前提とすることで、毎回のテストアプローチをチケットとして切り出し、スプリント内の開発部分に限定した「新機能テスト」と、サービス全体を意識したリグレッションテストなどを明確に区別できます。スプリント内に閉じた情報のアップデートは、最小限であればテストのアプローチ部分を設計するだけでも価値があります。（現在のテストプランの記載カテゴリーは文末に記載してあります）

蓄積型テストプランに生まれたメリット3点

テストプランを蓄積型にしたことによって以下のようなメリットが生まれました。

テストの起点を作れた
- テスト対象、スコープ、アプローチを明確にする
- 結果としてテストの抜け漏れを防ぐ
ナレッジを貯め続ける仕組みが作れた
- 過去のテスト結果、得られたドメインナレッジを蓄積する
- ナレッジの共有を促進する
- 結果としてテストの生産性の改善につながる
コミュニケーションのログが残る
- テストに関する議論、決定事項を記録する
- チーム内の情報共有を促進する
- 結果としてコミュニケーションコストの低減につながる

まとめ

アジャイル開発において、従来の重厚なテストプランは適応しづらいですが、スプリントを跨いだ形で継続的に更新できるテストプランを活用することは有用だと感じています。また、そのためにNotionのようなツールを活用し、動的に情報を管理できる仕組みを設計することが重要だと考えています。

また、「テストの起点を作れた」「ナレッジを貯め続ける仕組みが作れた」「コミュニケーションのログが残る」という役割をテストプランに持たせることで、テストプランの価値をさらに高めています。

最後に

今回の記事では、バクラクの開発におけるテストプランの取り組みについて紹介しました。私自身、テストプランについては、まだまだ試行錯誤の途中です。実は、私がテストプランに興味を持つきっかけとなったのは、以前に同じような課題を抱えていた時に見た James Whittaker氏の講演でした。当時はこれにより軽量なテストプランのコンセプトの着想を得ました。奇しくも、今年のJaSST’25 TokyoでWhittaker氏が基調講演を務められるとのことで、個人的に非常に楽しみにしています。

そして、JaSST’25 Tokyoといえば、1日目（3/27 16:30-）に弊社のQAエンジニアの高橋が「手動 × ローコード × コードベース：3つのアプローチをつなぐ実践」をテーマに登壇します。参加される方は、ぜひそちらも聴講いただけると嬉しいです！応援よろしくお願いします！！

お知らせ

4/18（金）19:00-21:00に、LayerXのオフィス（東銀座）にて「インプロセスQA Meetup!」を開催します。各社からのLTだけでなく、グループディスカッションの時間もご用意しておりますので、課題の共有や意見交換の場としてぜひご活用いただければと思います。
ご興味ある方はぜひご参加ください！

layerx.connpass.com

また、今後のイベント情報に関しては公式Xアカウント @LayerX_tech でアナウンスしますのでフォローお願いします。

おまけ現在のテストプランのカテゴリー

現在の私のテストプランは、以下のようなカテゴリーで構成されています。

Status Summary
- テストプロジェクトの状況確認用。主にテスト進捗とバグのメトリクスのグラフ
Reference
- 仕様、備忘録などを検索して使えるようにプロジェクトに関連する参考情報
- 一部仕様に関するドキュメントは別途NotebookLMで管理
Test Strategy
- テストアイテム、スコープ、アプローチ、毎スプリントごとのテスト方針など
Risk Register
- プロダクトリスク
Test Data
- テストデータ（CSV、PDF、画像ファイルなどを含む）とテスト環境の情報
Bug Management
- チームのバックログの中にあるバグをビューで参照
Communication
- 各種コミュニケーションの説明とSlackチャンネルのリンクなどを記載