こんにちは、bit0です！ ここ2ヶ月ほどテスト実行を経てQAエンジニアとして本配属を迎えました。 1ヶ月間はテスト実行、2ヶ月目の終わりからテスト設計を勉強させていただいております。 QAとして働き始めてから一番悩んだのが「テスト設計ってどう書けばいいの？」ということでした。
1ヶ月目ではテスト設計者が作ったテストケースを実行したり、フリーテストとして不具合がないか見て回ったりしました。 私のいるチームは新機能開発や、機能改修、プラン変更など怒涛の開発スピードだったため、既存影響がないか、デグレーションを起こしていないかをフリーテストで検証していました。(工期に余裕がなかったのもありますが) この1ヶ月のおかげで感覚的に不具合検出する力を身につけ、テストの楽しさを堪能しました。
そして2ヶ月目の後半にはいってテスト設計を依頼されましたが、今まで感覚的にやっていた内容を言葉にする、ケースにする壁にぶち当たりました。
この記事では、私が身につけた設計方法をステップごとに紹介します。
ステップ1：目的を明確にする（何を守りたいか）
テスト設計の最初の一歩は、「何を守るためのテストか？」を明確にすることです。
例えば「ログイン機能」を例にすると、 目的は「正しいユーザーだけがログインできることを保証する」になります。
ここがあいまいだと、テストケースが「動作確認の羅列」になってしまいます。
そのため、テストの目的を一文で書き出す！
「このテストで何が壊れていたら困るのか」を明確にする
ステップ2：観点を洗い出す（どう壊れうるか）
目的が決まったら、次は観点（リスク）を洗い出すステップです。
「この機能はどんな時に壊れるか？」を考えながら、ざっくり観点をリストアップします。 ここは1ヶ月目のフリーテストが凄く活きているなと感じています。 一例ですが、
例：ログイン機能の観点
入力パターン（正しい／間違ったメールアドレス・パスワード）
状態（アカウント有効／無効／ロック）
挙動（エラー表示／遷移先／ボタン活性状態）
環境（スマホ／PC／各種推奨ブラウザ）
仕様書に書かれていないケースも、ユーザーの行動をイメージすることで見えてきます。 これにプラスして、このチームはこういう対応が弱い、ここの設計ややこしかったなーという箇所を重点的に検証します。
ステップ3：テスト条件を整理する(何を確認するか)
洗い出した観点をもとに、テスト条件（=確認すべき内容）をまとめます。
この段階では「何を確認するか」まで。 「どう確認するか（具体的なデータや手順）」は次のステップで具体化します。
ステップ4：テストケースを設計する(どう確認するか)
条件をもとに、実際のテストケースを書きます。
例：テストケース記述
No 前提条件 手順 期待結果 1 有効なアカウントを用意 正しいメール・パスワードでログインボタンを押す ホーム画面に遷移する 2 登録済みアカウントを使用 パスワードを1文字違いで入力してログイン 「メールアドレスまたはパスワードが違います」と表示される
ポイント：
手順と期待結果を対応させる
不要に細かく書かず、目的が伝わる粒度にする
ユーザーの操作順序を意識する
私が一番最初に読んだ記事に書いてあった教訓をまとめとして終わります。
まとめ：テスト設計は“品質を考える設計”
テスト設計は「ケースを書く作業」ではなく、 「どんな品質を守りたいか」を考える設計活動です。
どんどん力をつけてユーザ視点を意識できるQAとして成長していきたいです！
