🍜

Notionとspreadsheetを活用したテスト設計

2024/12/19に公開

はじめに

こちらはe-dash advent calendar 2024の19日目の記事です。

2024年10月、e-dashのQAグループに参画しましたQAエンジニアのuedaです。e-dashのQAグループは2024年5月に新設されたばかりのため、現在もQAプロセスの構築を進めています。

e-dashではアジャイル開発のフレームワークとしてスクラムを採用しており、2週間のスプリントの中で、開発タスクに対するテストを行いながら、品質管理の仕組みづくりにも並行して取り組んでいます。

この記事では、入社してからQAグループとして行った私の活動についてお伝えしたいと思います。

テスト管理の改善

入社して最初に取り組んだのが、テスト管理方法の改善でした。
参画時点では、主にスプレッドシートでテストケースを作成している状況でした。
この方法でも基本的なテスト管理は可能ですが、より効率的で価値のある形でテスト資産を蓄積できないかと考えました。

特に注目したのが、既に社内全体で活用しているNotionの可能性です。
Notionはドキュメント作成とタスク管理の両方の機能を持ち、開発チームとの協業にも適しています。
そこで、Notionとスプレッドシートそれぞれのツールの特徴を分析してみました。

2つのツールの比較

スプレッドシートでの管理

メリット

  • 一覧性が高く、多数のテストケースを効率的に管理できる
  • テスト項目、期待結果、実施結果など定型的な情報を整理しやすい
  • 条件付き書式やフィルタリング機能を使って可読性を高められる
  • テスト実施状況の進捗管理がしやすい

デメリット

  • 背景情報や意図の一貫性が保ちにくい
    • 行やセルを追加して背景情報を記載することは可能ですが、大規模なテスト設計では構造が複雑になり、どのセルがどのケースに対応するかがわかりにくくなる場合があります。
  • 関連情報の参照効率が低い
    • 開発タスクや仕様書へのリンクを作成することは可能ですが、リンク先をチラ見する機能がないため、全体像を把握するには手間がかかります。
  • 視覚的な管理が限られる
    • 情報をセルで分ければ視認性は改善しますが、階層構造や関係図など、より直感的に情報を表現する方法はスプレッドシートでは工夫が必要です。

Notionでの管理

メリット

  • リッチテキストエディタにより背景情報の可読性が高い
  • 開発タスクと直接紐付けられ、関連情報の参照が容易
  • 階層構造を活用して情報を整理しやすい

デメリット

  • 一覧性の確保が難しい
    • データベースビューを使用すれば一覧表示は可能ですが、スプレッドシートほどの一覧性や操作性は得られません。
  • テストケースの編集に制限がある
    • セル結合や特定範囲の書式設定など、細かな表現の自由度がスプレッドシートより低く、更新や編集に手間がかかります。
ツール テストケース一覧性 テストケース整理 背景や意図の整理 情報関連付け
スプレッドシート
Notion

比較を踏まえての方針

分析結果を踏まえ、情報の性質と参照者の視点から管理方法を整理しました。

スプレッドシート、Notionどちらか一方ではなく、それぞれのメリットを最大限に活かして使い分けることにしました。
基本的な考え方は以下のとおりです。

  • Notion:テスト設計書やTEST SPEC[1]など、QA以外にも共有することが想定される情報
  • スプレッドシート:具体的なテストケースや実行結果など、QA業務に特化した詳細情報

具体的には以下の図のイメージです。(紫がNotion、緑がスプレッドシートを意味します)

この使い分けにより、以下のような改善効果が得られました。

  1. 開発プロセスとの親和性向上

    • 社内で広く使用されているNotionを活用することで、エンジニアやPMによるテスト設計書のレビューがスムーズに
    • 開発タスクとテスト設計書の紐付けにより、背景情報の参照が容易に
  2. テスト資産の効率的な管理

    • TEST SPECをNotionで管理することで、テスト設計の流用や参照が容易に
    • ドキュメントの作成状況や承認状態を一元的に管理可能

今後の展望

テスト管理の方針が固まりつつある一方で、次の課題としてリグレッションテストの整備が浮き彫りになりました。現状はアドホックテストやテストスコープを広げたテスト、バグバッシュなどを実施しており、これらの方法では網羅性や再現性が低いという課題があります。この課題を解決するために、リグレッションテストを整備し、変更による既存機能への影響を効率的かつ確実に確認できるプロセスの確立を目指します。
これらの取り組みを通じて、QAグループとしての基盤を作り、スピード重視のアジャイル開発においても確かな品質を提供できるプロセスを築いていきたいと考えています。

脚注
  1. 機能改良などによる仕様変更を反映するテスト仕様書を指しています。過去のテストケースには変更を反映せず、TEST SPECを確認することで最新の仕様を把握できる仕組みとしています。 ↩︎

Discussion