テストの初心者が状態遷移図を実際に作成してみた！
このシリーズは、私自身の「初心者研修記録」をもとに、研修で学んだテスト技法を実務でどのように活用したのかを記録したものです。
今回はその中から、実務で初めてテスト技法を意識的に活用した取り組みとして、「状態遷移図」を用いた検証の記録を整理し、記事としてまとめました。
私自身、ソフトウェアテスト受託業務の企業に就職してまだ3カ月ほどであり、ソフトウェアテストに関しては社内研修で学んだ知識しか持っていない状態でした。
実務経験がほぼない中で、研修で学んだテスト技法をどのように業務に落とし込んだのか、その過程と考えたことを初心者の視点で残しておきたいと考え、今回の記事を作成しています。
※本記事は株式会社モンテカンポの新人スタッフが記録したレポートを元に、記事として編集しなおしたものとなります。
| 私について簡単に自己紹介をします。 前職では、サーバ（ハードウェア）開発に関連する業務に従事していました。 そのため、ソフトウェア開発やソフトウェアテストに関しては、実務として深く関わる機会はほとんどありませんでした。 ソフトウェア分野の基礎知識としては、基本情報技術者試験の資格を取得していますが、あくまで座学ベースの理解に留まっており、実際のテスト業務は未経験の状態で現在の会社に入社しました。 そのようなバックグラウンドを持つ私が、研修で学んだテスト技法をどのように理解し、どのように実務で使おうとしたのかが、今回の前提となっています。 |
今回活用するテスト技法
今回、初めて実務でテスト技法を活用するにあたり、研修を受ける前から一度は耳にしたことのある、おそらく比較的メジャーなテスト技法であろう「状態遷移図」を使ってみることにしました。
状態遷移図とは、名前の通り、複数の状態を持つ対象が、どのような条件やイベントによって別の状態へ遷移するのかを図として表現するテスト技法です。
研修では、いくつかの例題をもとに状態遷移図を作成しましたが、それらはあくまで練習用の題材でした。
実際の業務で活用した場合に、どのような図になるのか、どの程度の粒度で状態を定義すればよいのか、具体的なイメージを掴めていない部分が多くありました。
そこで今回は、実際の検証対象をもとに状態遷移図を作成し、「実務で使う状態遷移図とはどのようなものか」を自分自身で確かめることを目的としました。
テスト内容
弊社では、Webアプリケーションの検証受託事業を行っています。
今回私が担当した検証業務の概要は、以下のようなものでした。
※なお、検証対象は社外秘情報を含むため、今回の記事では一部仕様の改変および名称の変更を行っています。
検証対象の概要
| ・レシート画像から購入金額を読み込み、キャンペーンに応募するWebサービス ・キャンペーン対象商品を購入していれば、その場で商品Aを獲得 商品Aの獲得には回数上限があり、上限以内であれば何度でも応募可能 ・さらに、対象商品の合計金額が一定金額（x円）以上の場合、抽選券が付与される 後日抽選に当選すると商品Bを獲得 |
検証要件
| ・Webサイト内の表示確認、表記ゆれの確認 ・各画面の画面遷移確認 |
このように、ユーザーの操作や条件によって画面遷移や結果が変化する仕様であったため、状態遷移図を用いた整理が有効ではないかと考えました。
テスト技法の検討
状態定義でつまずいたこと
最初に私が考えたのは、「今回のテスト対象は、どのような状態を持ち得るのか」という点でした。
研修の例題しか経験していなかった私にとって、この状態の定義が、想像以上に難しい作業でした。
というのも、ひとつのテスト対象であっても、視点を変えると状態の分け方がいくつも考えられたからです。
今回のケースでは、例えば以下のような切り口が考えられました。
| ・画面の状態遷移 （LP – ランディングページ画面、マイページ画面、応募画面、応募履歴画面、応募完了画面、エラー画面） ・応募するレシートの内容により応募対象が変化 1. キャンペーン対象外のレシート* 2. キャンペーン対象内且つ対象商品購入金額がx円未満 3. キャンペーン対象内且つ対象商品購入金額がx円以上 *キャンペーン対象とは「該当期間内の購入」「該当商品の購入」の条件をすべて満たしていること ・商品Aの獲得回数が上限に達したか、抽選券有無、抽選済みかどうか |
このように考えていくと、どこまでを「状態」として扱うべきか判断がつかず、状態定義の段階で手が止まってしまいました。
研修で学んだことの振り返り
社内研修で初めてテスト技法に触れた際、私は以下のように学びました。
テスト技法とは、テストケース（テスト項目）を作成・選択する際に使用するものである。
ただし研修を通して理解したのは、テスト技法は単に自分自身の理解を深めるためのものではないということです。
テスト技法は、開発担当者や他のテスターなど、関係者に説明することを前提として作成する必要があります。
つまり、テスト技法は関係者間の共通言語として機能するものだということです。
また、テストケース作成の根拠とするために、ひとつの図や表で全体を網羅することが理想とされています。
図や表を見るだけで、どのようなテストケースを作成すればよいのかが分かる状態が、目指すべき姿だと学びました。
今回の方針決定
今回の検証では、「表示確認」と「画面遷移確認」が主な検証内容でした。
このうち、状態遷移図で直接表現できるのは、画面遷移確認であると考えました。
そこで今回は、
| 画面の状態遷移（LP画面、マイページ画面、応募画面など）をベースに状態遷移図を作成する |
という方針で進めることにしました。
状態遷移図の作成と感想
状態一覧の作成
まず、状態を洗い出すところから始めました。
最終的に、以下の19状態を定義しました。
※すべて末尾に「画面」が付く想定です。
| LP | マイページ | 応募規約 |
| 応募 | 当選(商品Aのみ)(商品A当選初回) | 当選(商品A&商品B抽選券)(商品A当選初回) |
| 当選(商品Aのみ)(商品A当選2回目以降) | 当選(商品A&商品B抽選券)(商品A当選2回目以降) | 確認エラー |
| 応募履歴 | 商品A当選後応募フォーム | 商品A当選後応募内容確認 |
| 商品A当選後応募完了 | 商品B抽選当選後応募フォーム | 商品B抽選当選後応募内容確認 |
| 商品B抽選当選後応募完了 | お問合せ入力 | お問合せ内容確認 |
| お問合せ送信完了 |
状態遷移図の作成
上記の状態をもとに、実際に状態遷移図を作成しました。
作成して感じたこと
実際に状態遷移図を作成してみて、まず感じたのは「思っていたよりも状態数が少ない」ということでした。
もっと複雑な図になるのではないかと想像していましたが、状態そのものは比較的整理できました。
一方で、Webアプリケーションという特性上、1画面内に複数の別画面へのリンクが存在するため、矢印（遷移）の数は想像以上に多くなりました。
今回のケースが特別というわけではなく、他のWebプロダクトでも同程度、もしくはそれ以上の遷移数になる可能性は十分にあると感じました。
さらに、状態が増える場合、単純に加算的に増えるのではなく、乗算的に増える可能性があるとも感じました。
例えば、「応募期間内と期間外で画面表示が変わる」といった仕様が追加されると、LP画面、マイページ画面、応募画面など、それぞれに期間内・期間外のバリエーションが生まれ、画面数が倍増する可能性があります。
今回はGoogleスライドを使って状態遷移図を作成しましたが、矢印の数が多くなると、矢印やイベント名の文字が重ならないように配置を工夫するのが非常に大変でした。
この経験を通して、状態遷移図専用の作成ツールの有用性を強く感じました。
なお、本来であれば状態遷移図とあわせて状態遷移表も作成するべきですが、今回は状態遷移図の作成に集中しました。
状態遷移表については、次回の課題として取り組んでみたいと考えています。
まとめ
今回は、実際の検証対象をもとに状態遷移図を作成しました。
研修で扱った例題と比べると、実務のテスト対象では状態遷移図の複雑さが大きく異なり、特にイベントや遷移の数が膨大になることを実感しました。
実務で状態遷移図を作成する際には、専用ツールを活用することで、作図の精度向上や作業時間の短縮が期待できると感じました。
また、状態遷移図だけでは検証内容のすべてを表現することは難しいという点も、今回の取り組みを通して明らかになりました。
今回のケースでは、表示確認や表記ゆれの確認といった検証内容を、状態遷移図だけで表現することはできませんでした。
そのため、状態遷移図で表現しきれない部分については、別のテスト技法を組み合わせて活用する必要があると考えています。
複数のテスト技法をどのように一つのテストケースにまとめていくのかという点は、今回の取り組みを通じて新たに生まれた疑問でもあります。
今後は、テスト設計全体にも踏み込んだ取り組みを行い、今回得た気づきをさらに深めていきたいと考えています。
QA業務効率化ならPractiTest
テスト管理の効率化についてお悩みではありませんか？そんなときはテスト資産の一元管理をすることで工数を20%削減できる総合テスト管理ツール「PractiTest」がおすすめです！
PractiTest(プラクティテスト)に関する
お問い合わせ
トライアルアカウントお申し込みや、製品デモの依頼、
機能についての問い合わせなどお気軽にお問い合わせください。
この記事を書いた人
株式会社モンテカンポ新人テストスタッフA。
前職では、サーバ（ハードウェア）開発に関連する業務に従事。
ソフトウェア開発やソフトウェアテストに関しては、初心者。
基本情報技術者試験の資格を取得。実際のテスト業務経験をいま積んでいる。
経験のなかで学んだことを記事として公開中。
記事編集：川上サトシ（マーケター、合同会社ぎあはーと代表）