こんにちは、freeeのQAでマネージャーをしてるymtyです。
freee QA Advent Calendar2023 22日目です。
私は、QAマネージャーとしていくつかのプロダクトのQAに関わっています。今日はその中のひとつで、freee会計の申請機能（経費精算、各種申請、支払依頼、購買申請）を担当しているQAのメンバーであるMさんとリグレッションテストで使うテストの設計をした話を書きます。
テスト設計の細かい内容は読み飛ばしたい方は最後のほうにある（ここ大事）テスト設計の裏話って部分だけ読んでもらえればいいと思います！
- きっかけ
- 最初にやったこと
- ワークフローのステータス遷移のテスト設計
- テストで確認したい状態やイベントを追記
- 0スイッチテストケースをテスト実行しやすいように連結してシナリオにする
- 関連申請の紐付けパターンと申請時の入力パターンのテスト設計
- 権限のテスト設計
- （ここ大事）テスト設計したときの裏話
- おわりに
きっかけ
申請機能は、リグレッションテスト時の自動テストを用意しているのですが、機能がどんどん追加されているため、不十分な状況になっていました。実際にデグレード、つまり既存機能で変更不要なところがハッピー（バグ: freeeではバグをハッピーと呼んでいます）になってしまうこともありました。
ハッピーが起きてしまったことに対する振り返りで、リグレッションテストを網羅的に用意することをQAが行う対策とすることにしました。
最初にやったこと
Mさんには、どのような観点のテストが必要かをピックアップしてもらいました。網羅といっても、どの観点に対してどう網羅するか？をはっきりさせないといけないからです。
ピックアップしてもらった観点
- ワークフローのステータス遷移
- 関連申請の紐付けパターン
- 申請時の入力パターン（外貨か？証憑あるか？など）
- 作成した申請の一覧画面での検索でできること
- 申請の詳細画面で表示できること
- 権限によってできることとできないこと
- インボイス制度に伴う機能改修
この中で、4.一覧画面、5.詳細画面でできることは、できることをリストすればそのままリグレッションテストとして使えます。
また7.インボイス制度に伴う機能改修は、改修した内容をリストすればリグレッションテストとして使えます。
それ以外は、パラメーターと値（以降、P-Vと表記します）を洗い出して、テストに抜け漏れがないようにしたほうがよく、P-Vの組み合わせでテストケース数が爆発的に増える可能性もあるので、テスト設計が必要ですので、パターンを設計してもらうことにしました。
ワークフローのステータス遷移のテスト設計
「1.ワークフローのステータス遷移」は、状態遷移モデルで表せるので、状態遷移表を作ってもらうことにしました。ワークフローのマイクロサービスでの状態遷移モデルをエンジニアが過去に社内ブログにあげていたので、その状態遷移モデルを GIHOZというテスト設計ツール に記載して、状態遷移表と０スイッチカバレッジテストケースを自動生成しました。
0スイッチカバレッジでテストケースを生成すると上記の15パターンで網羅ができるということがわかります。
テストで確認したい状態やイベントを追記
次に上記の状態遷移モデルには現れてないがテストで確認しておきたい状態とイベントを追記して状態遷移表をブラッシュアップしていきました。
状態では申請中の状態を「申請中」と「申請中（複数承認者）」に分けました。申請から承認は設定により承認する人数を複数にできるためです。
イベントが2種類選べる場合（以下の状態遷移表で「申請中」の経費精算を「承認済み」に遷移させるイベントが「承認or代理承認」と書かれているのが該当）は、承認と代理承認という2つのイベントを1つのセルの中に書いておき、テスト実行の際にどちらかを必ず一回は行うとしました。
GIHOZでは、状態遷移モデルを描くと状態遷移表とカバレッジに応じたテストケースを生成してくれますが、状態遷移表を直接書いて、テストケースを生成することもできます。表の内容を少し変えていくだけであれば状態遷移表で書けたほうが効率いいので便利です。
以下の状態遷移表は経費精算の例ですが、4申請それぞれで仕様が異なるので、この状態遷移表は４申請分作りました。
経費精算以外（支払依頼、各種申請、購買申請）は、割愛します。
状態遷移表を書き直して再度0スイッチカバレッジのテストケースをGIHOZで生成しました。経費精算の例では25パターンとなっています。
0スイッチテストケースをテスト実行しやすいように連結してシナリオにする
0スイッチカバレッジのテストケースは、実行する際には、一連の流れとして実行していくことになります。あるテストケースの終了状態と別のテストケースの開始状態が同じ状態になるもので順番に実行していくと、一連の流れとしてテスト実行が効率よく行えます。
0スイッチカバレッジテストケースの一覧から、順番に組み替えたシナリオを作りました。以下がシナリオになります。シナリオは実際にユーザーが行いそうな流れで組み立てるので、0スイッチカバレッジテストケースが全部使われないこともあり、また同じテストケースをなん度もつかうことになることもあります。そのため下記Spreadの一番右側の「対象パターン」という列で、0スイッチカバレッジテストケースのどのテストケースを使っているかをわかるようにNoを記載しています。また、複数回同じテストケースをシナリオの中でつかっていることがわかるように、セルの色を変えています。
上記のやり方と順番はことなりますが、先にテストシナリオを作っておいて、その後1スイッチカバレッジのテストケースから見て網羅できているかを調べて不足があればシナリオ追加するって方法でもいけるかと思います。
上記以外に2シナリオ目、3シナリオ目も作ったのですが、本ページでは割愛します。
結果的に、3つのシナリオを用意することで全部のテストケースを一度は実行できるようになりました。
関連申請の紐付けパターンと申請時の入力パターンのテスト設計
「2.関連申請の紐付けパターン」と「3.申請時の入力パターン（外貨か？証憑あるか？など）」は、は、共に申請を作るときの入力のパターンという意味では一緒であるため、一緒に組み合わせを作ってテスト実行すると効率よいだろうと考えて、ペアワイズ技法で組み合わせました。
ペアワイズは、P-Vを組み合わせるためのオールペアのアルゴリズムにかけるだけですが、ありえない組み合わせもテストケースになってしまうと、テスト実行時に「このパターンはテストできないじゃん！」ってなるので、制約式で組み合わせに現れないようにする必要があります。
以下のように制約式を記載しました。
テストケースを生成した結果、ペアワイズ法では4申請全部合わせて25パターンでオールペアの網羅ができることがわかりました。
このテストケースを全量として、実際にテストする際はこの中から必要に応じてさらにピックアップしてテスト実行を行うとしました。例えば経費精算にて「定期区間控除ありで交通経路なし」というパターン（以下のNo14）は、機能として設定は可能ですが、現実的にはこのパターンで経費精算する人はいないはずです。この設定でおかしなことになるかってテストは一度は必要ですが、リグレッションテストとして毎回行わなくてもよさそうです。その場合はテストケースからは外します。
権限のテスト設計
申請機能では、ベースになる権限のセットとして、以下の権限セットがあります。
- 管理者
- 一般
- 取引登録のみ
- 閲覧のみ
- 申請・承認
これらのセットの中で、更にfreee会計の機能ごとに以下の権限を設定できます。
- 自分のみ
- 閲覧
- 登録・編集・削除（ここは機能によって若干言い回しが異なります）
なので、単純に権限の確認を網羅的にするのであれば、権限セットの4パターンと機能ごとの権限の3パターンで12パータンテストをすればよいのですが、実際は、「管理者」と「一般」は基本的に何も変わらないので全部組み合わせる必要はないが、管理者だけができることがあるので、その確認が必要であったりします。
また、上記のセットで４申請分のテストをするのですが、他の機能の権限の組み合わせでできるできないが決まる（例えば、経費精算の権限の設定と証憑の添付の設定）こともあるので、そのパターンも表現しないといけません。
単純に出てきた条件式を全網羅的に記載すると、表が異常にデカくなります。（Mさんは最初それをやってギブアップしそうになりました。）この組み合わせを考えて条件部分の記載をするのがテスト設計のポイントになります。
支払依頼、各種申請、購買申請のデシジョンテーブルはここでは割愛します。
動作の部分は、全部「可」「不可」の両方を記載しました。二択なので１行でも収められそうだし、そのほうが表が長くならないので良さそうですが、生成したテストケースに「不可」と明示的に記載してあった方がテストする際に不可であることを確認できるのでいれたいというMさんのアイデアを聞いて、「確かに、もっともだ」って思ったので、このようにしました。
（ここ大事）テスト設計したときの裏話
こう書くとすごくスムーズにテスト設計しているように読み取れると思いますが、ここに行くまででMさんと私で何度もディスカッションをしています。
ワークフローのステータス遷移のテスト設計の時を例にしてその時のことを書いてみます。
まず、最終的にはテスト実行をスムーズに行いたいので、Mさんはテストシナリオを作るところから始めました。私からは、「最終的にシナリオにするのは完全に合意だけど、状態遷移に抜け漏れがあるといけないので状態遷移表を書こう」って提案を行い、書いてもらうことにしました。しかし、Mさんから「状態遷移表を書かずに手でやっていいか？」と私に話がありました。「テストしなければいけないことは頭の中にイメージがあるので、そのままシナリオにした方が早い」というのが理由です。
確かに、テスト設計をするのにテスト技法が必須というわけではないです。知らなくてもできます。もっというと、テスト技法を使わなくても、テスト対象に詳しいQAエンジニアの頭の中にはどういう流れでテストしていけば良いかというイメージがあるでしょう。そういうイメージをそもそも持ててないとしたら、テスト対象を理解できていないのでまともにテストできないからです。
テスト技法を使う大事な理由として、QAエンジニアの頭の中にあるノウハウの塊（この塊はいろいろなことが絡み合うように固まっているので、本人以外はよくわからない）から、必要なことを剥離していき、他の人でもわかるように整理したモデルですっきり表現できるようにすることがあります*1。スッキリ表現できることで自分自身の理解度も上がり、さらにいうと、規模が大きくなったり、変更がたくさん入ったりしてもテストの考え方を再現可能になります。テスト技法を使えるということは、モデリング能力が上がっていくことであり、応用力が身につくのです。
こんな話をMさんに何度もしながら納得してもらってテスト設計進めました。
実際、私は今回、Mさんと一緒にテスト設計するまで経費精算の仕様を詳しく理解していませんでしたが、一緒にテスト設計ができ、テスト設計を通じて仕様理解もできました。
おわりに
ここまで、freee会計の申請機能（経費精算、各種申請、支払依頼、購買申請）を担当しているQAのメンバーであるMさんとリグレッションテストをテスト設計に取り組んだ事例を紹介しました。 このテスト設計の内容はチームのエンジニアとも共有し、特に仕様の認識にズレがないかを確認しました。
開発者にとってもこのテスト設計の資料（仕様の認識という意味ではテスト分析ですが）を改修時に事前に確認したり単体テストを書くときのネタにしてもらうことで役に立つものになります。
freee QAは、より品質の高いプロダクトをより早く届けるために、挑戦を続けていきます。
明日は、uemuさんが、「Webサービスの歩き方 - シン・境界値分析」というタイトルの記事を書くことになってます。楽しみですね！
最後まで読んでいただきありがとうございました。
それでは、よい品質を〜
*1:ノウハウの塊を剥離する話は電通大の西康晴先生の講演「てすとづくり ～質の高いテスト設計の原理～」から引用してます。
