テストの初心者が状態遷移表を実際に作成してみた！
このシリーズは、私自身の「初心者研修記録」をもとに、研修で学んだテスト技法を実務でどのように活用したのかを記録したものです。
今回はその中から、実務で初めてテスト技法を意識的に活用した取り組みとして、「状態遷移図」を用いた検証の記録を整理し、記事としてまとめました。
私自身、ソフトウェアテスト受託業務の企業に就職してまだ3カ月ほどであり、ソフトウェアテストに関しては社内研修で学んだ知識しか持っていない状態でした。
実務経験がほぼない中で、研修で学んだテスト技法をどのように業務に落とし込んだのか、その過程と考えたことを初心者の視点で残しておきたいと考え、今回の記事を作成しています。
※本記事は株式会社モンテカンポの新人スタッフが記録したレポートを元に、記事として編集しなおしたものとなります。
| 私について簡単に自己紹介をします。 前職では、サーバ（ハードウェア）開発に関連する業務に従事していました。 そのため、ソフトウェア開発やソフトウェアテストに関しては、実務として深く関わる機会はほとんどありませんでした。 ソフトウェア分野の基礎知識としては、基本情報技術者試験の資格を取得していますが、あくまで座学ベースの理解に留まっており、実際のテスト業務は未経験の状態で現在の会社に入社しました。 そのようなバックグラウンドを持つ私が、研修で学んだテスト技法をどのように理解し、どのように実務で使おうとしたのかが、今回の前提となっています。 |
今回活用するテスト技法
前回の記事では、システムの挙動を視覚的に捉える状態遷移図を作成しました。
今回はそのステップアップとして、状態遷移図と対になる状態遷移表の作成に挑戦します。
図では見落としがちな網羅性を、表形式にすることでどのように補完できるかを検証していきます。
テスト内容
検証対象は前回同様の案件を扱います。
※機密保持のため、一部の仕様改変および名称の変更を行っています。
【キャンペーン概要】
レシート画像をアップロードして購入金額を読み込み、キャンペーンに応募するシステムです。
| 商品A： 対象商品を購入していればその場で獲得（獲得上限内であれば何度でも応募可能）。 商品B： 対象商品の合計金額が一定額（x円以上）であれば抽選券が付与され、後日抽選で獲得。 |
【検証要件】
| ・Webサイト内の表示および表記ゆれの確認。 ・各画面における画面遷移の整合性確認。 |
テスト技法の活用検討
前回の内容から活用できる部分
前回の状態遷移図で定義した条件をベースに、要素を整理します。
状態定義（全19状態）
※以下の各画面を「状態」として定義しました。
| LP | マイページ | 応募規約 |
| 応募 | 当選(商品Aのみ)(商品A当選初回) | 当選(商品A&商品B抽選券)(商品A当選初回) |
| 当選(商品Aのみ)(商品A当選2回目以降) | 当選(商品A&商品B抽選券)(商品A当選2回目以降) | 確認エラー |
| 応募履歴 | 商品A当選後応募フォーム | 商品A当選後応募内容確認 |
| 商品A当選後応募完了 | 商品B抽選当選後応募フォーム | 商品B抽選当選後応募内容確認 |
| 商品B抽選当選後応募完了 | お問合せ入力 | お問合せ内容確認 |
| お問合せ送信完了 |
状態遷移イベントの選定
図から抽出した遷移のきっかけ（イベント）は以下の通りです。
| 汎用イベント： 「マイページへ」リンク「応募規約」リンク「お問合せはこちら」リンク「応募履歴へ」リンク「応募履歴」リンク お問合せ関連： 「確認する」リンク「お問合せ内容を修正する」リンク「お問合せ内容を送信する」リンク 応募履歴関連： 商品A応募「詳細内容」リンク商品B応募「詳細内容」リンク「確認する」リンク「内容修正する」リンク「確定する」リンク 応募メインイベント： 「応募する」リンク対象レシートを読み込む(指定金額未満, 初回)対象レシートを読み込む(指定金額未満, 2回目以降)対象レシートを読み込む(指定金額以上, 初回)対象レシートを読み込む(指定金額以上,2回目以降)対象外レシートを読み込む「連続で応募する」リンク「再度応募する」リンク「送付先を入力」リンク |
運用上の疑問点
イベントの抽出を行った際、「確認する」イベントが2箇所ありましたが、
その実態は
| 「お問合せ画面上の『確認する』リンクを選択」 「商品A当選後応募フォーム画面上の『確認する』リンクを選択」 |
の二種類。
これらイベントをひとつにまとめてよいのかが不明でした。
また、応募履歴画面に遷移するイベントとして、
| 「応募履歴へ」リンク選択 「応募履歴」リンク選択 |
の二種類がありますが、
これらも別々のイベントとしてカウントすべきかが不明でした。
疑問点をまとめるとこのようになります。
| ・イベント分けはシンプルに状態遷移図に記載のイベントだけで精査していいものなのか？または他の軸(例えば今回であればリンク選択時に実行されるスクリプト)で分けるべきか？ ・今回の検証は外注のシステムテストであり、あくまでブラックボックステストで実施するため、中身の詳細な構造が不明のため、GUIに表示されるイベントでしか分けることができない？ |
疑問に対する考察と判断
テストにおけるイベントの切り出し方について調査したところ、テストの目的によって最適な粒度が変わることが分かりました。
| ビジネスロジック（内部処理）の検証： 処理内容が同じなら「1つのイベント」に統合。 UI/UX（画面遷移・導線）の検証： 物理的な導線が異なるなら「別のイベント」として扱う。 |
今回のケースでは、たとえ表記が同じ「確認する」ボタンであっても、遷移先や実行されるバリデーションが異なる可能性が高いと考えられます。
そのため、ブラックボックステストの観点からは、異なる場所にあるボタンは、たとえ名前が同じでも別イベントとして定義するのが妥当であると判断しました。
状態遷移表の作成
https://docs.google.com/spreadsheets/d/1Xez8HhOFnaanqnHL4hSQlqGk2HUXuSLIc-qI1y1MpdE/edit?gid=0#gid=0
状態遷移表を作成して得られた気づき
正直なところ、今回の検証においては状態遷移表の優位性はあまり感じられませんでした。
というのも、状態遷移図で表現されていないものの、実際には無理やり実行できてしまう状態とイベントの組み合わせが、この状態遷移表には含まれていないためです。
また、状態遷移表内で「（実行不可）」と記載されているものについても、実際には実行できてしまうケースが多いと感じました。
まとめ
| 技法の適材適所： 状態遷移表は、あらゆる状態でイベントを強制実行できる環境（APIテストや、特定のフラグ操作が可能な環境）でこそ真価を発揮する。 開発者との連携： イベントの定義（共通化するか分けるか）を検討する際、内部構造を知る開発者と目合わせを行うことで、より効率的で精度の高い表が作成できる。 |
今回は状態遷移表の作成を行いました。
状態遷移表は、すべての状態×イベントの対応を確認できるため、状態遷移図とは異なりイレギュラーな組み合わせを確認できる点が強みです。
しかし、今回の検証のように、そもそもイレギュラーなイベント実施ができない場合には、あまり有用ではないことが分かりました。
検証対象によって適したテスト技法は異なるため、各テスト技法の得手・不得手を把握しておくことが重要であると感じました。
今回のような状態遷移表は、イベントをどのような状態でも強制的に実行できてしまう環境において、より有用であると考えます。
また、状態遷移表の書き方についても、今回の実践を通して学びがありました。状態遷移図とは異なり、イベントのまとめ方は「機能面」で同一であるかどうかが重要であると分かりました。
その観点では、開発者との共同作成も、状態遷移表の完成度や見やすさの向上という点で有用であると考えました（実際に共同作成が可能かどうかは別の課題ですが）。
今後の検証でもテスト技法を積極的に活用し、実務における具体的な活用方法や有用性について引き続き確認していきたいと考えています。
QA業務効率化ならPractiTest
テスト管理の効率化についてお悩みではありませんか？そんなときはテスト資産の一元管理をすることで工数を20%削減できる総合テスト管理ツール「PractiTest」がおすすめです！
PractiTest(プラクティテスト)に関する
お問い合わせ
トライアルアカウントお申し込みや、製品デモの依頼、
機能についての問い合わせなどお気軽にお問い合わせください。
この記事を書いた人
株式会社モンテカンポ新人テストスタッフA。
前職では、サーバ（ハードウェア）開発に関連する業務に従事。
ソフトウェア開発やソフトウェアテストに関しては、初心者。
基本情報技術者試験の資格を取得。実際のテスト業務経験をいま積んでいる。
経験のなかで学んだことを記事として公開中。
記事編集：川上サトシ（マーケター、合同会社ぎあはーと代表）