テスト漏れを防ぐために状態遷移図を書く

これはソフトウェアテストの小ネタ Advent Calendar 2022の1日目の記事です。

筆者は普段Webアプリケーションのフロントエンド領域開発&保守を担当しています。過去、保守していたWebアプリケーションで特定の操作フローのケースが丸ごと抜けていた事案がありました。運用開始時は良かったのですが、ユーザーが特定の操作フローを行ったときにバグが見つかってしまう事態に発展してしまったことがありました。

このときはCRUDのCRD部分しかテストができておらず、U＝更新のケースが抜けていました。このようなことを繰り返さないようにするために、状態（ステータス）を持つアプリケーションは状態遷移図をきちんと書き、そこからテストケースを起こすのが有効と考えています。

状態と状態遷移図

【この1冊でよくわかる】ソフトウェアテストの教科書　［増補改訂第２版］では状態について

一定の同じ動作を続けている様子

動作後に異なる動作を開始しない様子

と説明されています。バッチ処理やステータスを持っているアプリケーションは状態を持っていると考えられるでしょう。

これを図や一覧表でまとめたものが状態遷移図です。ただ、アプリケーション開発時は図式化した物を使った方が良いです。状態が複数あると、Aの状態からBに進むパターン、Cに進むパターン…と進み方が枝分かれすることがあります。一覧表だと考慮が大変だったり、後から見返したときに全体を把握しづらい等で見落としが発生しやすくなります。

時間が進むにつれて状態が変わる場合は一覧表の方が良いですが、それ以外では図式化する方が保守のときに助かることが多いです。考慮点が多い中でぱっと見で分かるというのはとても助かります。

実際に書くとき工夫していること

図書館アプリケーションを例にしてみます。状態がいくつもあります。

返却済み（保管中）
- 本が返却されている＝保管している状態
貸出中
- 本を貸し出している状態
延長手続き待ち
- 期限日の3日前に返却通知メールを送信する
延長手続き済み
- 延長手続き待ちの状態で貸し出し延長手続きができる
- 延長手続きが完了するとこのステータスになる
貸出延長中
- 貸し出し延長済み、かつ元の期限を過ぎている場合このステータスになる
延滞中
- 貸出中または貸出延長中の期日を過ぎても本が返却されていないとこのステータスになる

実際に書いてみたものがこちらです。ツールはdrow.ioを使いました。作図ツールを使うのがおすすめです。個人的に一番体験が良かったのはCacooです。

工夫：色を分ける

状態の移り変わり種別ごとに色を分けると、後から見返したときに処理フローを把握しやすいです。図書館のアプリケーションだと、フローとしては3つに分かれています。

期限内に返却する：緑
期限を延長して延長期限内に返却する：青
延滞手続き：赤

全て黒で書いてしまうと、線が重なったときに見づらくなります。読み間違えを防ぐため、フォーマットが決まっていない限り色を分けるようにしています。

工夫：アプリケーション内のステータス番号も記載する

アプリケーションでは、状態（ステータス）は番号とセットで管理されていることがあるかと思います。データベースのPKとステータス番号が紐づいている場合もあるかもしれません。

1: RETURNED
2: BORROWING
...

もし番号とセットで管理されている場合、状態遷移図に書き込んでおくことをおすすめします。単体テストなどの自動テストを設計する際、状態遷移図と照らし合わせてケースの抜け漏れを確認できます。また、チームメンバーとコミュニケーションをする際、番号・ステータス名どちらを使っても状態遷移図をベースにできます。表現が揺れていると考慮漏れやミスの原因となるため、可能な限り記載しておくのがおすすめです。コードを読む際も役に立ちます。