はじめに
こんにちは、世界。
ログラスでQAエンジニアを担当している大平です。
現在、私はスクラムチームに所属してテスト活動をしています。
今回は、スプリント期間内で実施しているテスト分析・設計やテストケースの管理に悩んでいたところを「TestLinkの一部の機能をNotionで再現して改善しよう」と実験した話です。スクラムチームでテスト活動をどう管理するかの参考になれば幸いです。
コンテキストと悩みごと
私が所属するスクラムチームの開発やテストのプロセスはこんな感じでした。
- 1週間スプリントで実施
- バックログはNotionのScrum Board templatesを利用して管理
- バックログアイテムは価値の単位で小さく分割するという方針
- バックログアイテムには、受け入れ基準とは別にテストケースを記載
- テストケースが多数に及ぶ場合は、スプレッドシートに記述し、Notionページにリンクを貼る
- テストの設計＆実施はスプリント内で実施
- テストの設計＆実施はQAエンジニアだけではなく、エンジニアも実施
日々のテスト活動の中で以下の課題が出てきました。
- メンバー同士でテストケースをレビューする際にテストの意図がわかりにくく抜け漏れが判断しにくい
- テストケースが増えると、Notionで管理しているバックログアイテムのページが長くなり、可読性が低下する
- テストケースがバックログアイテムのページに紐付いているので再利用しにくい
いくつかの課題に対して、今回は以下の部分にフォーカスすることにしました。
- レビューしやすいようにテストの意図（テスト分析・設計の思考）を文章として残したい
- バックログアイテムとテスト分析・設計とテストケースの紐付けをわかりやすくしたい
- バックログアイテムのページはシンプルにしたい
また、今のスクラムチームでは自分たちでテスト分析、設計、実装、実施まで行うため、以下については、対象外としました。
- テストケースの詳細な手順の記載や管理
- テストケースのバージョン管理
- 詳細なテスト実施履歴の管理
この条件で、どのような手が打てるか考えた際、商用のテスト管理ツール利用は現段階のチーム状況ではオーバースペックと考えました。また、スプレッドシートではテストケースの管理は楽になりますが、テストの分析・設計が記述しにくいことが難点でした。
なかなか改善案に難儀していたのですが、たまたま前前前職の先輩とお話する機会があり、その当時にTestLinkを利用していたことを思い出しました。私は、仕様とテスト分析・設計とテストケースを構造的に紐づけるTestLinkの思想が好きでした。
そして、まさにこの構造が現在の悩みを解決できるのではと思い、現在チームで利用しているNotionで再現できるか実験してみることにしました。
TestLinkとは
今回の実験を説明する前に、簡単にTestLinkの説明をします。
（TestLinkをご存知な方はこの章は飛ばしてください）
TestLinkは、オープンソースのWebベーステスト管理ツールです。
TestLinkは以下の図の構成となっており、テスト仕様書（分析設計書）にテストスイート（テストケース群）、テストケースが紐づく形です。
引用：https://www.jasst.jp/archives/jasst08s/pdf/A2-2.pdf
今回は、このテスト仕様書（分析設計書）とテストケースが紐づく構造を参考にしました。
詳細なテストケースの管理については、現在のチームでは必要ないので、対象外としています。
Notionで実現したこと
Notionを以下の3つのDBで構成しています。
- バックログDB
- テスト分析設計書DB
- テストケースDB
この3つのDBはNotionの Relation 、 Rollup 機能を使って連携しています。
図：各DBの関係性
バックログ、テストケースは一般的な構成だと思うので説明は省略し、今回はテスト分析設計書の詳細について説明します。
テスト分析の部分について
テスト分析では、決められた項目を埋める形式になります。決められた項目を埋めることでテストの全体像を把握することが狙いです。
実際のテンプレートの抜粋画像
項目の詳細は以下の通りです。
- テスト対象がわかる資料
機能の仕様がわかるドキュメントや要件がまとめられているMiroのリンクや自社や競合の類似機能の記載、ビジネス要件がわかる資料など、テスト対象を分析するにあたって、必要な情報を集められるだけ、集めます。 - テスト対象の概要
「テスト対象がわかる資料」から自分の言葉で、テスト対象の概要をまとめます。まとめ方は、ユーザーストーリー形式が多いです。できるだけ3行ぐらいでまとめるように書きます。 - テスト対象機能の詳細
テスト対象の具体的な機能名を書き出します。テストが必要な箇所を洗い出します。 - 考えられるリスク
起きて欲しくないことや気になることを箇条書きします。この部分は、自分で考えるだけではなく、実際にコーディングしているエンジニアやビジネスサイドにヒアリングもします。
また、過去に似たような箇所で発生した不具合についても、あわせて記載します。 - テストすること
実施するテストを具体的に書きます。必要であれば、因子と水準の概要についても書きます。
私の場合は、思考を発散するために、テストすることをマインドマップでざっと描いた後、箇条書きでまとめたりしています。 - テストしないこと
テスト対象に含まれているが、今回はスコープ外になる理由を含めて、書き出します。あえて、テストしないことを書くことによって、後から読むレビュー者との目合わせに使います。 - テストに必要な準備
事前に準備が必要なテストで必要な環境、データ、ツールを書き出します。
テスト設計の部分について
テスト分析でまとめた「テストすること」をもとに、実際のテストケースに落とし込むためにデシジョンテーブルや状態遷移図を作成などの設計をします。
このテスト設計の部分までを作成後、レビューを行います。レビュー完了後、実際のテストケースを作成します。
実際のやり方について
このテスト分析・設計部分は、スプリント開始後、バックログアイテム着手時すぐに実施します。
理想として、コーディング完了前に関係者とレビューして、事前にテストに関して、共通認識をとることが望ましいです。事前にテスト分析・設計することで、設計の不明点を洗い出すことが狙いです。（タイミングによっては、コーディング後になってしまうこともあります。今のところ、無理のない範囲で実施しています）
また、コーディングするエンジニアとQAエンジニアが共同で実施する場合もあります。その場合は、ラフにテスト分析まで共同で実施して、テスト設計の具体的な部分をQAエンジニアが作成します。
むすび
今回は、スクラムチームでのテスト管理方法、スプリント内でのテスト分析、設計、テストケース作成までを実施するやり方について説明しました。
実験した結果としては、もともと課題感としてあったレビューしやすさについては、テスト分析のパートで認識をあわせることができるので、テスト設計部分の抜け漏れについてチェックしやすくなったと感じます。バックログアイテムの可読性、テストケースの再利用性は、まだ改善の余地があり、さらにNotionの機能をどんどん活用していきたいと思い、Notionを勉強中です。
また、この実験を始めてから、同じチームのエンジニアメンバーが、事前にテスト分析をすることによって、仕様の詰め切れていない部分をわかることができたというケースもありました。すぐにテストケースを考えず、いったんテスト分析設計書を作成し、テスト対象の全体を俯瞰できることは、実装する上でもプラスになるということがわかりました。
ただし、まだ複雑な仕様部分だと、テスト分析、設計に時間がかかり、コーディング完了までに間に合わないケースが発生する課題があるため、テスト分析、設計の実施スピードを上げる必要があります。
今のところ、対策としては、テスト分析・設計の量をこなして、スピードと精度を上げていくしかないと考えています。
みなさまのテストの取り組みのヒントになれば幸いです。
おわり。
株式会社ログラスは「良い景気を作ろう。」をミッションに、企業経営を推進する次世代型経営管理クラウド「Loglass 経営管理」を開発し提供しています。
Discussion