以前、時系列で起こるイベントを洗い出すモデリングの話を
勉強会などでしてきました。
今回は、ECサイトを例に、チュートリアル形式で記載します。
まず、古くなってしまいましたが、
以前作った資料を添付します。
時系列を意識したテストを洗い出すためのアミダモデリング
今は、Sashimi modelというと別の言葉になってしまいますので、
言い方を変え、アミダモデルとしています。
今回は、これを実践で使う場合を説明します。
概要
まずは、何のためのテストをするかを確認する
今回は、購買をする際の住所の話をしましょう。
アクセプタンスクライテリアは、
- 顧客に、滞りなく荷物が発送できること
- 顧客のライフイベントに対応できること
- トラブルが発生した際に、適切に対応できること
と、します。
実際に書いてみる
書き出す前に、ステークホルダーとコンディションを整理しておきます。
ステークホルダーを書く
ステークホルダーは、
- ユーザー
- ストアフロント（Webサイト）
- データベース
としました。これを、アミダの横軸に置きます。
イベントを書いていく
このテストの目的は、出荷時に住所が滞りなく引き出せることです。
ですが、実際にはいろいろと考慮しないといけない点があることが、
モデリングからわかります。
この点線と、その視点にあるサークルには、以下の意味があります。
- 点線：イベントが起こる場合と起こらない場合がある
- サークル：繰り返し発生することがある
コンディションを足す
イベントを書いたところで、状態遷移が発生するコンディションを付け足します。
今回のコンディションの例は、
-
アカウント
- 住所
- 離島か否か
-
品物
- 重さ
- 大きさ
としました。（実際にはもっと複雑になるでしょう）
完成
テストの作り方
こうしてできた表によって、以下のテストアクティビティが可能です。
- 条件の抜け漏れチェック
例えば、点線は、イベントが起こる場合と起こらない場合がある、と書きました。
つまり、この表から、住所登録がされる場合とされない場合があることがわかります。
つまり、注文した時点で住所登録がされていない、というシナリオが見えます。
また、サークルは繰り返しである、と書きました。
このことから、住所登録が繰り返し行われる可能性がある、ということがわかります。
ということは、商品が注文された時点で、住所登録が複数回行われ、離島か否かの
パラメーターが 何度も変更されていることもあり得る、ということです。
あるいは、時系列のモデルなので、商品が注文された後に住所が変更される
可能性があることもわかります。
こうしたイベントとタイミングの関係は、定規を置いてその時点の左側に
書かれている線を見ると、 イベントが発生した時点で影響のあるコンディションや
別のイベントが明確になります。
- 組み合わせテスト
イベントにつけたコンディションの変化によって、その後のイベントに
影響があることがわかります。これを使って、組み合わせテストが書けます。
- シナリオテスト
条件の抜け漏れチェックで発見できたような状態とイベントの相関関係を
シナリオテストに起こせば、
エッジパターンを考慮したユーザーシナリオが書けます。