実例マッピングとお触り会
こんにちは、kubopです。
先日実例マッピングをiOSチームと行い、それを使ってテストケースを作成してみんなでお触り会をしました。
実例マッピング会を開催する
実例マッピングとは
実例マッピングでは、具体的なユーザーストーリーを作成する事が出来ます。
実例を一つ一つ明らかにすることで、ユーザーにとっての問題点を検討することが出来、新機能を構築するための許容条件の判断（＝受け入れ条件）に役立ちます。
イメージとしては
「投稿機能が欲しいな〜」というストーリーに対して
「例えば投稿する時は、<b></b>みたいなタグが埋め込まれたら排除したいよね」という例を書き出し、
「想定外の文字列が入力された場合は、除去して空白で置き換える」といったルールを書き出せる。
ステークホルダーは、「じゃあ想定外の文字列って何？」といった質問を投げられる。みたいな認識。
実例マッピングの具体的なやり方
議論中のストーリーを黄色の付箋に書きます。
緑色の付箋に例を張り出します。
例をもとに、青色の付箋にルールを抽出します。
例・ルールに対して赤色の付箋で疑問点を洗い出します。
例えば、Uber Eatsのようなサービスでは…
黄色付箋
ストーリーを定義するもの。
ストーリーは、たとえば「配達先住所を変更する機能」などの機能単位からなる。
青付箋
ストーリーを実現するために必要な実装ルール。
たとえば、「有効な住所のみ許可される。」といったバリデーションなど。
緑付箋
実際にルールが適用された場合の振る舞いの例。
たとえば、「有効な住所を入力されなかった場合に注文処理が完了しなく、hogehogeといったエラーが表示される。」など
赤付箋
実装ルールに関し、懸念点や疑問点。
たとえば、「有効な住所はどのように判定するのか」など。
実例マッピングのメリット
機能の中のルールを分解でき、可視化することが出来る。
チーム内で共有することができ、Slackなどに質問が散乱することがない。
実例を伴うことで、それ自体がテストケースに流用できる。
実例マッピングのデメリット
進め方がマジでわからない。
ファシリテーターの負担。人により、いまいちピンと来ない感がある。
必要性の説明から始まるので、本題にいくのが大変。
毎回やるには、プロジェクトにインして定期的に開催する必要あり（今回はできなかった。
お触り会を開催する
まずは仕様を把握
上述した実例マッピングを用いたり、実際に自身が調査した仕様をもとにテストケースを作成します。
本当はテスト計画から行い、がっつりリスクベースで考えたかったのですが、そこまで大きな機能ではなかったため割愛。トレーサビリティもあんまりとれてなく、反省。
テスト分析、テスト実装を繰り返し行いました。
いざ、リリース前お触り会
kubopがファシリテーターになり、チームのみんなでテストを実施。
基本的にQAは全体的にお触りし、チームのみんなには担当者を割り振って深掘りしてもらう。
その際、テスト観点をあらかじめ記載していたのでその通りにさわってもらったり、変な文字列をいれてもらったりする。
みんなでわいわい、「これって仕様だっけ？」みたいなのを確認しながら行う。
結果
不具合を結構な数、リリース前に検知することができた！
今回の範囲でなく、もともとあった不具合も発見することができた！
仕様を細かく、可視化して文書ベースで確認することができた！
知らなかった仕様を知ることができた！
所感
実例マッピング〜お触り会と続けて行うことで、仕様理解と不具合発見を併せて出来てよかった！
チームの中でノリノリで行え、わいわい感をもって実施できてよかった。
実例マッピングの進め方については、まだまだブラッシュアップできそう。
まずは実例マッピングの有用性をどんどん布教したい。
テストケース作成、分析の職人芸を磨いていきたい。まだまだスキル不足。
参考資料
実例マッピングの聖典です。
すごくわかりやすくて、助かった資料
この記事が気に入ったらサポートをしてみませんか？