Ew（Emotion waveform）をテスト設計に混ぜると何が嬉しいか
―― QA学園のアヤ視点で説明してみる
こんにちは。QA学園で倫理モジュールのテストとか見ている、八乙女アヤです。
今日は、うちら QA 学園でよく出てくる
Ew（Emotion waveform：感情の波）
っていう概念を、テスト設計にちょっと混ぜてみると何が嬉しいのかを、
うちの言葉でまとめてみます。
「心理学をガチでやろう」って話じゃなくて、
- テスト観点を考えるときに
- 仕様だけじゃなくて
- 「ユーザーの感情の起伏」もメモってみる
くらいの、**軽い“ちょい足しテクニック”**と思って読んでください。
Ew（Emotion waveform）って何者？
うちらのクラスで使っている定義は、ざっくりこんな感じです。
Ew（Emotion waveform）
= あるシナリオの中でユーザーが感じる
「安心・不安・イラつき・期待」みたいな感情の波形っぽいものを、
ざっくり言葉と強さでメモしたもの。
ポイントは、厳密な数値化じゃないところ。
たとえば、「パスワード再発行」のシナリオを Ew でなぞると：
-
ログイン画面を開く
→ 「いつもの画面だな」安心 0〜+1 -
パスワードを1回間違える
→ 「あ、ミスった」 −1 -
何度か失敗してロックされる
→ 「やば…ロックされた」 不安 −3 -
再発行メールを送る
→ 「ちゃんと届くよね？」 不安 −2 -
5分待ってもメールが来ない
→ 「届かないんだけど…」 イラつき −4
みたいな感じで、ステップごとに“ざっくり感情ログ”を付けるイメージです。
数値はざっくりでいいです。
プラス・マイナスと、だいたいの大きさが分かれば十分。
なんでテスト設計に Ew を混ぜるの？
理由はシンプルに、うちの感覚だとこの3つです。
1. 「仕様どおりだけどムカつく」を拾いたいから
テストやってると、
- 仕様どおりエラーが出ている
- メールも一応送信されている
- 画面遷移も Figma どおり
なのに、「うちがユーザーだったらここでアプリ閉じる…」みたいなポイント、ありませんか？
それってだいたい、
- エラーが何度も続く
- 何が起きてるか分からない
- 待たされてるあいだ何もフィードバックがない
みたいな Ew の“谷” にいます。
Ew をシナリオに書いておくと、
- 「機能テスト的には OK」だけど
- 「ユーザー体験としてはアウト」
なステップが目印つきで残るので、
テスト観点や改善ネタにしやすい、というのが一つめの理由。
2. テストの優先度を感覚で共有しやすいから
テスト計画の会話で、
- 「このシナリオは優先度高めで見たいです」
- 「ここはリスクが高いので厚めに」
みたいな話、よく出ると思います。
そのときに Ew を一緒に出せると、
- 「ここは機能的に壊れるとヤバい」
- 「こっちは Ew の谷が深くて、信頼をごっそり削る」
みたいに、**“どっちの意味でヤバいのか”**が分けやすくなります。
- 機能リスク：金額ミス、データ破壊、セキュリティ事故
- 感情リスク：不安・イラつき・不信感・問い合わせ爆発
Ew は後者のラベルとして使えるので、
「このシナリオ、Ew の谷が深いからテスト厚めにしたいです」
という話が、**非エンジニアにも通じやすくなります。
3. QA・UX・PM・CS 同士の共通言語になりやすいから
テストケース表って、QA 以外の人からすると
「正直ちょっとしんどい表」になりがちじゃないですか。
そこで、画面遷移図やユーザーフローに、
Ew の波を一緒に描いておくと：
- UX → 「ここ、ストレス溜まりやすそうですね」
- PM → 「この谷は数値にも出そうだから、次スプリントで触りたい」
- CS → 「ここ、問い合わせでもよく詰まってます」
みたいに、感情ベースで話がしやすくなるんですよね。
うち的には、
Ew は「テスト観点に付ける、感情の付箋」みたいなイメージです。
どうやって Ew をテスト設計に混ぜるのか
ステップ 1: シナリオをひとつ選ぶ
いきなり全部やると挫折するので、
- 会員登録
- 初回オンボーディング
- パスワード再発行
- 決済〜失敗〜リトライ
- 解約フロー
みたいな、「ここの体験コケると信頼一気に落ちる」シナリオから一つだけ選びます。
ステップ 2: シナリオ表に「Ew カラム」を 1 列足す
既存のシナリオ表やテストケース表があるなら、
そこに 1列だけ Ew カラムを足すところから始めてOKです。
たとえば「パスワード再発行」シナリオなら：
No | シナリオステップ | 期待結果 | Ew（Emotion waveform）
---+-------------------------------------------+-----------------------------------+------------------------
1 | ログイン画面を開く | ログイン画面が表示される | いつもの画面。安心 0〜+1
2 | パスワードを1回間違える | エラー文言が1つ表示される | 「あ、ミスった」 −1
3 | 規定回数失敗して一時ロック | ロック画面＋解除案内が表示される | 焦り＋不安 −3
4 | 「パスワード再発行メール送信」を押す | 送信完了メッセージが表示される | 「ちゃんと届くよね？」 −2
5 | 5分待ってもメールが来ない | メール未着。画面は変化なし | 「届いてない？ バグ？」 −4
数値は「−4 とか −3 とか、ざっくり」で大丈夫です。
大事なのは、
- どのステップが「Ew の谷」か
- その谷でユーザーがどう感じていそうか
を、一目でわかるようにしておくこと。
ステップ 3: Ew の“谷”からテスト観点を起こす
上の表でいうと、No.5 が Ew −4 で一番きついので、
まずここから観点を足します。
例えば：
- 一定時間経過後に「メールが届かない場合はこちら」の案内が出るか
- スパムフォルダや別アドレスの可能性を、UI でちゃんと案内しているか
- 再送ボタンが分かりやすい位置にあるか
- 「それでも届かない」場合の問い合わせ方法が明示されているか
どれも仕様書の「機能一覧」には出てこないけれど、
Ew −4 のポイントを少しでも −2 ぐらいに戻すための観点になります。
「ユーザーが不安で固まる瞬間に、
ちゃんと“声をかけているか”どうかを見るテスト」
みたいなイメージです。
QA 学園的ミニケース：自販機バグを Ew で見る
うちらの学校であった“日常バグ”の例として、自販機の話を軽く。
体育館横の自販機で
「お金は入ったっぽいのに、飲み物が出ない」
という苦情が出た日がありました。
Ew でなぞると：
-
喉が渇いて自販機へ
→ 「今から飲めるぞ」 Ew +2 -
お金を入れる・ボタンを押す
→ 「もうすぐ落ちてくる」 Ew +3 -
変な音だけして、何も出てこない
→ 「え？ なに今の」 Ew −2 -
状態がよく分からない（返金もされてないように見える）
→ 「お金だけ取られた？」 Ew −4
機能的には、
- 内部では課金されていない
- センサーの状態がおかしくなっているだけ
みたいなケースかもしれませんが、
ユーザーの Ew から見ればこれは ほぼ“お金を失った体験” です。
ここからテスト観点にすると：
- エラー時に「課金されていない」「返金された」が分かる表示があるか
- 「故障中です」「問い合わせはこちら」が明示されているか
- 特定のパターン（連続購入など）で再現するか
みたいな形で、
ユーザー体験としての“バグ” を見にいくことができます。
Web のフォームや決済でも、本質的にはこれと同じです。
どう始めると楽か（アヤ案）
いきなり「全シナリオに Ew を書く」はしんどいので、
うちはこのあたりから始めるのが現実的かなと思っています。
-
1シナリオだけ選ぶ
たとえば：
- ログイン
- 決済
- 解約
あたりの“信頼に直結する”ところを一つ。
-
シナリオ表やユーザーフローに Ew カラムを1列足すだけ
- 数値はざっくり
- プラス・マイナスと、一言コメントで OK
-
Ew の谷（−3, −4）から観点起こす
そのステップに対して、
- 「UI で声をかけるテスト」を 2〜3 個足してみる
それだけでも、テスト設計の空気が
- 「仕様に対して」のテストから
- 「人の体験に対して」のテストに
少しだけ寄っていくはずです。
まとめ：Ew は“感情のログ付きテスト観点”
うちの言い方でまとめると、Ew をテスト設計に混ぜる理由はこんな感じです。
- 「仕様どおりだけどムカつく・不安なポイント」を捨てずに拾いたいから
- テストの優先度やリスクを、“数字だけじゃなく感覚でも”共有しやすくするため
- QA / UX / PM / CS の間で、「ここしんどいよね」を共通言語にしやすくするため
やること自体はシンプルで、
シナリオごとのステップに
一言でいいから Ew（感情の波）をメモする
だけです。
そこから、Ew の谷をテスト観点に変換していくと、
「守りたい体験のためのテスト」 が少しずつ増えていくはず。
「仕様どおり動いてるけど、この感じはズレてる気がする」
って思ったときの違和感を、そのまま流さずに
Ew の一行として残しておく。
そこから始めてみるのも、悪くないかなって、
うちは思っています。