UIの表示崩れやAPIリクエスト時のエラーは「見てわかる」のですぐ気付ける。ただ、アプリケーションに関するドメイン知識が絡む部分のバグは見落としやすい。どうやって見つけようか？
意識している心持ち
「これってそもそもさぁ…」というひねくれた気持ちを持ちながらテストする。
- ⚪︎日前って普通は当日を抜かすけど、業務仕様的に認識合ってるんだっけ？
- （期限があるものは）状態が変わったときに期限延長して良いんだっけ？
- 制約はあるんだっけ？
具体例
本の貸し出し管理アプリケーションがあったとする。
業務的な仕様
返却済み（保管中）- 本が返却されている＝保管している状態
貸出中- 本を貸し出している状態
- 貸し出し期限は貸し出し日込みで2週間
延長手続き待ち- 期限日の3日前に返却通知メールを送信する
- メール送信後このステータスになる
延長手続き済み延長手続き待ちの状態で貸し出し延長手続きができる- 期限は元の期限＋2週間伸びる
- 延長手続きが完了するとこのステータスになる
- 再延長はできない
貸出延長中- 貸し出し延長済み、かつ元の期限を過ぎている場合このステータスになる
延滞中貸出中または貸出延長中の期日を過ぎても本が返却されていないとこのステータスになる- 一冊でも延滞がある場合他の本を貸し出しできない
バグを見つけるときに着目するポイント
太字の部分に特に着目する。
- 期限は
貸し出し日込みで2週間とある。期限が当日込みで14日後に設定されているだろうか？ - メール通知は
返却日の3日前送信だが、この3日前は当日を抜かす認識で良いのだろうか？ - 延長した際、手続きした日＋2週間で設定されてしまっていないか？
延長手続き済みのとき、再延長手続きできないように制御されているか？- 画面・API共に制御できているか？
延滞の本がアカウントに紐づいているとき貸し出し制御されているか？- 画面・API共に制御できているか？
と言った具合で、業務フローに沿って見落としがないかを検討する。
雑感
トラブルシュート時に話がややこしくなるのは仕様バグなので、可能な限りリリース前に潰したい。アプリケーションのドメイン知識が無いとごっそり確認が抜ける。
ちゃんと業務仕様にも興味を持ってやりましょうね、という当たり前の話なのかもしれない。
