CSチームでプロダクトの受け入れテストをやってみる

カスタマーサービス部 (CS) のメンバーで、機能リリース前の受け入れテストをやり始めました。企画者やエンジニアがユーザーから見た振る舞いで気をつけるポイントを理解するため、ユーザーからお問い合わせを受けるCSメンバー自身が製品を理解するために役立てています。

開発プロセス

QAのタイミングで、受け入れテストを実施しています。

テストフィードバック

CSが実施した受け入れテストは、下記の3段階でテスト結果をフィードバックします。

• [MUST] 振る舞いに問題があり、修正対応するまではリリース不可
  • ユーザーが混乱する表現や操作を間違えそうなUI
  • お問い合わせが多発する可能性がある振る舞い
• [SHOULD] やや気になる部分もあるが、振る舞いに概ね問題がないのでリリースして良い
  • CS判断としてはリリース前に修正対応すべき
  • ただし、リリース前に修正するかどうかの最終判断はPMに委ねる
• [WANT] より良いUXのために対応して欲しいこと
  • CS判断としては満たして欲しい品質である内容
  • リリース前に対応するかどうかはPM判断に委ねる

フィードバック事例

注意点としては、必要性の度合い (MUST / SHOULD / WANT) は、あくまでも個人主観なので全体最適化どうかは別問題です。そのため、テスター同士や開発チームと会話しながら認識を揃えたり、ある程度の範囲はPM判断に委ねる形にしています。

補足：変更範囲外の画面や機能に対するフィードバック

他の画面や機能との一連の流れの中で、ちょっとした違和感に気がつくことがあります。気がついたことは、とにかく忘れる前に記録してフィードバックします。

ただし、予定外の箇所なのでリリースを止めることは基本的にしません。適宜、PM判断で次回以降の開発タイミングで対応してもらいます。

受け入れテストで避けたいこと

受け入れテストを行う中で、下記のような現象を避けるためにテスト結果のフィードバックを MUST / SHOULD / WANT に分類しています。迷ったらWANT でフィードバックです。

フィードバックする側（テスター）

• 気になることを伝える役割が無意識に暴走してしまい、過剰要求になる
• 細かなフィードバックをためらう
  • 「まぁ、これくらい良いか」が増えて、フィードバックの価値が目減りする

フィードバックを受ける側（開発者）

• フィードバックが多すぎて、対応に疲弊してしまう
• フィードバックを貰うことが億劫になり、受け入れテストを回避してしまう
• 細かいフィードバックにより、本当に大事なことが埋もれる
  • 細かい方が対応が簡単なので、重要なことより簡単なことを優先対応してしまう（人類の性）

おわりに

やや緩い運用ではあるのですが、開発チームとCSチームの会話が増えるきっかけになればスタートとして十分かと思っています。