13. 状態遷移テスト
アドカレ13日目は「状態遷移テスト」。
状態遷移テストは、表の4行目にあたる。
上記表の最終行が、ラルフチャートを書いた結果、状態遷移テストを実施すると判断する材料である。
入力のところは「-」である。これは入力の有無は考慮しないということで、入力はあってもなくても良い。（通常、広い意味での入力により、状態は遷移する。）
「広い意味での入力」とは、[OK］[キャンセル]ボタンなど画面が切り替わるイベントや、指定時刻になった時のタイマーイベント、メモリーフルなどの警告イベント、ポーリング先のデータ変化、マウスボタン、通信のパケット到着、音声等々、ソフトウェアへ届く信号の全てが対象となるということ。
ベランダで休憩中の女の子が散歩に出たくなる理由はひとつではないのだ。
※ これらをまとめて「イベント」と呼ぶ。
次の状態変数がRead/Writeになっている点がポイントだ。状態をどこかに覚えているということだ。例えば車のワイパーは自分が今、「間欠モード」か、「低速モード」か、「高速モード」かどこかに記憶している。
もっと馴染み深いエアコンで言えば、自分が冷房中か暖房中かを記憶している。
そして状態を「○」、状態の移り変わりを意味する遷移を「→」で表す。例えばキャッチイメージを詳しく見てみよう。
ベランダで休憩をしていた女の子は、天気が良くて、散歩日和だなあと思う。
ところが、「ベランダで休憩状態」からいきなり「お散歩中状態」には遷移しない。「外出着えらび状態」を経て部屋着から着替えから外に出るからだ。
このように、順番の規則があるものをテストするときには、状態遷移テストを行う。様々な技法（正確には網羅基準）があるが、GIHOZを使って状態遷移図を書いてテストケースをGIHOZに作ってもらうのが1番良いと思う。やり方は昔のnoteの記事を参考にしてほしい。
なお、状態遷移図のあるあるとして、「遷移を表している図」という誤解がある。そうとも言えるのだけれど、むしろ状態間の遷移を限定している図と考えてほしい。「この状態からは“ここ”と“ここ”にしか行けない」を表している図が状態遷移図である。したがって、イベントを受け付けないというテストも重要である。