【シナリオテスト】の書き方とコツ：MECEに分解し適度に細分化する方法
はじめに
開発で関わっている、医師向けプラットフォームサービス「Antaa」で、シナリオテストを書く機会があったので、注意点とコツを記載したいと思う。
ちなみに、Antaaでは、医師・医学生向けに主に下記の3つのサービスを運営している。
QA：医師同士の質問解決プラットフォーム
Slide：医師が学会や研究レポート・勉強会の発表資料をシェア
Channel：医師が学べるオンライン動画サービス
シナリオテストとは
シナリオテストとは、システム開発における総合テスト（システムテスト）の手法の一つで、ユーザーがシステムを使用する際に想定される操作や、公式な使用手順などを踏まえた上で、そのような操作のもとでシステムに不具合が起きないか、問題なく使えるかどうかを確認するもの。
シナリオテストでは、プログラミングコードを直接記載する必要はない。つまり、エンジニアでなくても記載できる。
単体テストとは
シナリオテストと対になる概念が単体テスト。
単体テストは、ソフトウェアの各コンポーネントや関数が個別に正しく動作するかを確認するテスト。プログラムの各部分が期待通りに機能するかを検証するために用いる。
コード中心。例えば、パスワードのバリデーションの場合は、下記のような単体テストを書き、実際には利用しているプログラミング言語でテストコードを書く。
シナリオテストと単体テストの違い
まず単体テストを行なって、画面単位・コード単位でのバグを潰してから、次に、統合テスト（シナリオテスト）を行う。
以下に違いを箇条書きで列挙する。
シナリオテストを書くときのコツ
実際に書いてみて感じたシナリオテストの注意点とコツを記載しておく。
求められるのはMECEに条件分解する能力
シナリオテストを書く上で求められるのは、MECE（Mutually Exclusive, Collectively Exhaustive）に条件を分解する能力。
コンサルの因数分解作業と似ている。
重複や漏れがないようにシナリオを整理し、あらゆる可能性を網羅することが重要。これにより、テスト漏れを防ぎ、より信頼性の高いテストが実現できる。
適度な細分化
一方で、MECEに分解しつつも細分化しすぎるのも良くない。シナリオを細かく分解しすぎると、テストの管理が複雑になり、逆に非効率になる。適度な細分化を心がけ、必要な情報を過不足なく含めるようにする。ここのバランスが難しいところ。
もちろん全てのケースで全部シナリオテストを行い完璧を期した状態でリリースするのが、時間が無限になるのであれば望ましいが、そういう状況ではないことがほとんどのため、MECEに分解しつつも代表例をピックアップして、テストを取捨選択するのも重要。
UIUX担当した人がシナリオテストも書くと効率的？
シナリオテストを書いてみて感じたのは、UIUXを書いた人がシナリオテストも記載すると効率的なのでは？ということ。
開発チケットを切る前に、Figmaなどデザインツールを使って画面遷移のモックアップをデザイナーなりPdMなりが記載することがあると思うが、、、
続きは、こちらで記載しています。
いいなと思ったら応援しよう！
