このレッスンのゴール
- 受け入れ条件を自分で書ける
- 見た目・文言・例外ケースの確認視点を持つ
- プレビューと本番の違いを説明できる
受け入れ条件を先に書く
品質はセンスではなく、条件です。依頼前に『これが見られたら成功』を3行で書いておくと、レビューが速くなります。
- 正常系: いつも通りの使い方でこうなる
- 文言・見た目: モバイルでも欠けない、誤字がない
- やってはいけないこと: 別機能が壊れていない
プレビューは下見
多くのサイト案件では、PR ごとにプレビュー URL ができます。本番に出す前の下見です。Cloud Agent や CI がコメントしてくれることもあります。
プレビューでよく見えたら本番でも同じ、とは限りません。データ、権限、秘密情報が違うことがあります。それでも『出してから初めて見る』より安全です。
あやしいときの聞き方
『この変更で壊れうる場所は?』『テストした手順は?』『ロールバック方法は?』は、経験年数に関係なく有効な質問です。Agent にも人にも使えます。
理解チェック
- 受け入れ条件を3行で書ける
- プレビュー確認の手順を自分の言葉で言える
実践
進行中または仮想のタスクに対し、受け入れ条件を3行と、確認手順を5分で書き切る。
いま身についている開発者スキル
QA 視点 / 受け入れテスト
マイルストーン
レビュー力の土台ができた
リポジトリ・ブランチ・PR・品質の見方が揃いました。第4章では、その裏側の仕組みを深めます。