初心者が状態遷移図を実務で作ってみてつまずいたポイント
ソフトウェアテストの研修でテスト技法を学んだとき、「状態遷移図」は比較的理解しやすい技法だと感じていました。
状態と状態を線で結ぶだけで、画面や処理の流れが整理できる。
しかし、いざ実務で使ってみると、研修では見えていなかった“つまずきどころ”がいくつも浮かび上がってきました。
そこで今回は、テスト初心者である私が、状態遷移図を実務に適用する過程で特につまずいたポイントを整理します。
※本記事は株式会社モンテカンポの新人スタッフが記録したレポートを元に、記事として編集しなおしたものとなります。
| 私について簡単に自己紹介をします。 前職では、サーバ（ハードウェア）開発に関連する業務に従事していました。 そのため、ソフトウェア開発やソフトウェアテストに関しては、実務として深く関わる機会はほとんどありませんでした。 ソフトウェア分野の基礎知識としては、基本情報技術者試験の資格を取得していますが、あくまで座学ベースの理解に留まっており、実際のテスト業務は未経験の状態で現在の会社に入社しました。 そのようなバックグラウンドを持つ私が、研修で学んだテスト技法をどのように理解し、どのように実務で使おうとしたのかが、今回の前提となっています。 |
つまずき①「状態とは何か」を決められない
最初に直面した壁は、
「今回のテスト対象は、どのような状態を持ち得るのか？」
という問いでした。
研修では、状態が明確に定義された題材が用意されており、「この状態からこの状態へ遷移する」という前提がほぼ自明でした。
しかし実際のWebアプリケーションでは、状態の切り口が一つではありません。
例えば今回の検証対象では、以下のような分け方が考えられました。
| ・画面単位での状態（LP、マイページ、応募画面など） ・レシート内容による状態（キャンペーン対象外／対象内、金額条件の違い） ・ユーザーの応募状況による状態（商品A獲得回数、抽選券の有無、抽選済みかどうか） |
どれも「状態」と言えそうで、どれも間違いではありません。
その結果、「どこまでを状態として扱うべきか」「これは状態なのか条件なのか」という判断ができず、状態定義の段階で手が止まってしまいました。
つまずき② 研修の例題と実務のギャップ
研修で状態遷移図を書いたときは、「実務でもだいたい同じ感覚で描けるのでは」と思っていました。
しかし実務では、状態そのものよりも遷移（イベント）の数が圧倒的に多くなります。
Webアプリケーションでは、1画面の中に複数のリンクや分岐が存在します。
そのため、状態の数がそこまで多くなくても、矢印の本数は一気に増えます。
研修の題材では「状態が多くて複雑」という印象が強かったのに対し、実務では
「状態は整理できるが、遷移が多すぎて図が読みにくい」
という別の難しさがありました。
つまずき③ 状態は「加算」ではなく「乗算」で増える
状態遷移図を描きながら、もう一つ気づいたのは、
状態は単純に足し算で増えるわけではない、という点です。
例えば今回のケースに
「応募期間内／期間外で画面表示が変わる」
という仕様が追加された場合、
| LP画面（期間内） LP画面（期間外） マイページ（期間内） マイページ（期間外） |
というように、既存の状態が丸ごと分岐します。
少し条件が増えただけで、状態数が倍増し、遷移も一気に複雑になります。
「状態を1つ追加する」という感覚では済まないことに、作図して初めて気づきました。
つまずき④ ツール選定を甘く見ていた
今回はGoogleスライドを使って状態遷移図を作成しましたが、矢印の数が増えるにつれ、次のような問題が顕在化しました。
矢印やイベント名の文字が重なる
状態の配置を少し動かすだけで全体が崩れる
図の見やすさを保つための調整に時間がかかる
状態遷移図は「考えるための道具」であるはずなのに、
「きれいに描くこと」自体が負担になってしまう場面がありました。
この経験から、状態遷移図を本格的に扱うのであれば、専用ツールを使う意義は大きいと実感しました。
つまずき⑤ 状態遷移図だけでは足りない
最後に感じたのは、
状態遷移図は万能ではない
という当たり前だが重要な事実です。
今回の検証では、
| 表示内容の確認 表記ゆれの確認 |
といった観点も求められていましたが、これらは状態遷移図では表現できません。
状態遷移図は「画面や処理の流れ」を整理するには有効ですが、
検証内容のすべてをカバーできるわけではありません。
「では、状態遷移図で表現できない部分は、どのテスト技法で補うのか」
「複数のテスト技法を、最終的にどうテストケースへ統合するのか」
この疑問が、次の課題として明確に残りました。
まとめ
状態遷移図は、研修では「分かりやすいテスト技法」に見えていました。
しかし実務で使ってみると、
| ・状態定義の難しさ ・遷移数の多さ ・状態増加の爆発性 ・ツール選定の重要性 ・他技法との組み合わせの必要性 |
といった、初心者ならではのつまずきポイントが次々に現れました。
これらは失敗というより、実務で使ったからこそ見えた違和感だと思っています。
同じように「研修は受けたが、実務での使い方がピンと来ない」という方にとって、今回の記事がひとつの参考になれば幸いです。
QA業務効率化ならPractiTest
テスト管理の効率化についてお悩みではありませんか？そんなときはテスト資産の一元管理をすることで工数を20%削減できる総合テスト管理ツール「PractiTest」がおすすめです！
PractiTest(プラクティテスト)に関する
お問い合わせ
トライアルアカウントお申し込みや、製品デモの依頼、
機能についての問い合わせなどお気軽にお問い合わせください。
この記事を書いた人
株式会社モンテカンポ新人テストスタッフA。
前職では、サーバ（ハードウェア）開発に関連する業務に従事。
ソフトウェア開発やソフトウェアテストに関しては、初心者。
基本情報技術者試験の資格を取得。実際のテスト業務経験をいま積んでいる。
経験のなかで学んだことを記事として公開中。
記事編集：川上サトシ（マーケター、合同会社ぎあはーと代表）