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