こんにちは、フリーのQAマネージャーをしているymty（ゆもつよ）です。
今回は、フリーのQAにてどのようにしてテストチャーターを作って実行しているか、1年ほど前に新規リリースした「freee支出管理 小口現金」の新規開発時の、実際のテスト分析資料を元にご紹介します。
テストチャーターを書く前に、私が入る案件で行っているのが「フィーチャーの整理と論理的機能構造をつかったテスト分析」です。
言い換えれば、「このフィーチャーは内部で小さな機能がどう動いてるか、そこまで深掘りして理解した上で何をテストすべきか？」をロジカルに分解していくプロセスです。
ステップ①：マインドマップでフィーチャーを洗い出す
まずは対象プロダクトにどんな機能（フィーチャー）があるのかを洗い出します。 新規開発の場合は最初にこれをやる必要があります。機能拡張の際はすでにフィーチャー一覧はできているはずなので、このステップは不要です。 フィーチャー一覧を作る時は、画面ベースでもよいのですが、単に画面単位ではなく、業務視点・目的視点での機能（フィーチャー）整理を意識します。 最初にシステムのざっくりとした全体像を絵に描きます。
その後、要求や要件が書かれたドキュメントからフィーチャーを洗い出します。
以下は洗い出しの際に実際に作成したマインドマップです。
ここでは、単にプロダクトのフィーチャーだけでなく、影響先になるfreee会計のどこに着目すべきかも整理しています。
✍️ ポイント：
単純にUIベースにするのではなく、処理や目的に着目することで、後工程のテスト設計がぐっとラクになります。
ステップ②：機能ごとに論理的機能構造図を描く
次に、マインドマップで整理したフィーチャーに対して、論理的に内部構造を深掘りしていきます。これは、プロダクトのアーキテクチャーを知らないとできないわけではなく、システムとして考えればこうなるはずだという論理的な整理と深掘りをすることに意味があります。
この記事では、マインドマップで洗い出したフィーチャーの１つである「小口現金出納帳」にフォーカスして具体例を説明します。
以下の論理的機能構造図はそのフィーチャーの構造を論理的に分解したものです。論理的機能構造図を使ったテスト分析とは何か？は、JaSST'21 Tohokuで行われたワークショップの資料が参考になります。
この図の紫の付箋が、小口現金出納帳というフィーチャーがユーザーによって使われる際にどのようなタスク（フィーチャーの中の小機能）を経由して処理が行われているかを表したものです。 例えば「入力時に権限によって異なった選択肢が出る」→「入金と出金の金額を集計」→「現金残高と比較」→「いろいろな中から表示が必要なものだけ選んで出力」といったような流れがわかるように書いていきます。 この紫の付箋に対して、オレンジ色の付箋でどんな確認が必要なのかを書いていきます。青い付箋はレビュー時のコメントが書かれています。
この図では、上記に加えて会計月や締め日などの条件によって表示される明細がどう切り替わるか、 取引の種別（会計起票・小口現金として起票・振替伝票など）によってどう振る舞いが異なるかをロジックとして整理しています。
✅ ここで明らかになっていったことの例
表示対象月のロジック（例：締め日が15日 vs 末日）
並び順（日付昇順 or 降順）
ページング処理の有無
複数の権限による振る舞いの違い
この構造分析が「テストすべきこと（切り口）」を明確にしてくれます。
ステップ③：分析結果をテスト分析シートに落とし込む
論理的機能構造を使ったテスト分析を元に、テストすべき点を「テスト分析シート」にまとめていきます。
このシートには以下のような情報を記載しています：
- 分析対象の機能
- 分析対象の機能に対してテストすること
- 想定される振る舞い（P-V＝カバレッジアイテム：パターンとして必要なパラメーターも分析結果でわかるレベルで記載）
- 仕様補足や注意点（備考欄は、リスク洗い出し会で出たリスクアイテムのリンクや、エンジニアと共有した時に得たフィードバックを書いてる）
- 開発順番
例えば論理的機能構造図にて以下の図のようにオレンジの付箋で書いていたものは...
テスト分析シートでは以下の図のように書かれます。
このシートを作成し、エンジニアやプロダクトマネージャーへテスト分析を共有し認識を合わせることで「テストチャーターとして書ける状態」へと整理していきます。
ステップ④：テストチャーターに落とし込む
いよいよ、探索的テストの出発点であるテストチャーターを記述します。
テストチャーターは、フリーのQAの標準テストプロセスで作成するテスト実行用の成果物です。まずは、テスト分析結果からタイトルだけのテストチャーターを作ってしまいます。
以下は、「入出金一覧に表示する明細の取得」に対するテストチャーターです。
🧪 テストチャーター：
これにより、「どの切り口で、何を確認すべきか」が明確になります。テストチャーターには基本的に操作手順などの細かいことは書きません。細かいことを書くほどテストチャーターのレビューやメンテナンス工数が増加するからです。詳細な間違いがないかをレビューするよりもテスト実行する時に結果をしっかり残すことに注力します。テスト実行する人がチャーターを書いた人と別になる場合は、どのような意図のテストをしたいのかを対面で伝えます。
ステップ⑤：実行結果を記録し、仕様変更にも対応
作成したチャーターは、Zephyrにて、実行結果を記録していきます。
- 実際に確認したことの記載
- 仕様通り動作したかの結果（Pass/Fail）
- スクリーンショット証跡
- 仕様修正が必要だったポイント（例：締め日切替時の表示不備）
などを詳細に記録することで、再テストや結果レビューの際にも非常に役立ちます。テストチャーターに書いてないが確認しておくべきだと実行時に気付いた場合は、「その他テストしたこと」に書いておきます。 この例は、テストしたいポイントだけ書いておいてあとはテスト実行時に探索的にやるテストになっていますが、権限の確認や税金計算などパターンをしっかりと設計しないといけない場合は、さらに添付資料として パターン設計した表を添付しておき、その表に対して全てテストすることでテスト結果をPassしたことにするという運用をしています。テストすることに対して、このようなメリハリをつけて対処することで、適切なテストになるようにしています。
おわりに：チャーターは「論理的構造と言語化」が命
テストチャーターを書くというと、「とりあえず動かしてみる」印象を持つ方も多いですが、 フリーではそう考えていません。 本質的には、どんな論理的構造を持った機能で、どこがテストのポイントなのかを言語化することが最も重要であり、重要なことをちゃんと押さえた上で「誰かに言われるがまま」ではなく、自分自身でプロダクトのことを考えてテスト対象を動作させることができるのがテストチャーターを使うメリットです。
今回紹介したように、
- マインドマップで全体像を洗い出す
- 論理的構造図で上部だけで物事を見ないように内部を理解
- 分析シートで整理してエンジニアやプロダクトマネージャー含めたチーム内で共有
- テストチャーターでテスト方針を明示
- 実行・記録を残すことでしっかりとテストしたことがわかるようにする
という流れを実践することで、誰がやってもブレの少ない探索的テストが可能になります。
📘 補足：この分析フローは「ゆもつよメソッド」と呼ばれるテスト分析手法をベースにしています。
今回のプロセスは、一般的に「ゆもつよメソッド」と呼ばれているテスト分析をフリーではどんな感じで使っているかの一例になります。
プロダクト知識が浅い状態でも、論理構造と目的志向の整理によって、早期にプロダクトを理解し、その上での高精度のテストが可能になります。
今回の事例では、私がテスト分析をしたときのことを書きましたが、このチームは私がいなくなってからも論理的機能構造図を使って分析するようになっています。
このチームのリードをしてるkanaさんがSlackでこんなことを書いてるのを見つけた時は嬉しかったです。
テスト作成して実行していくやり方の一例として参考になれば幸いです。ご質問やフィードバックがあれば、ぜひコメントで教えてください！それでは、良い品質をー！
フリーのQAでは一緒に働く仲間を募集しています！このリンクから応募待ってます！
