Webアプリの仕様変更はどこを直す？修正箇所と影響範囲の調べ方｜確認問題の回答例
Webアプリの仕様変更はどこを直す？修正箇所と影響範囲の調べ方の確認問題の回答例です。変更する場所と、確かめ直す内容を分けて考えましょう。
第1問
画面のmaxを720に変えましたが、600分の登録がエラーになります。次に確認する場所を、値の流れに沿って挙げてください。
まず、画面が送ったstudyMinutesの値を確認します。Servletがその名前で文字列を取得し、Modelへ渡しているかを追います。Modelに480分超を拒否する条件が残っていないか、DAOのSQLやDB制約に上限がないかを調べます。原因をModelだけと決め付けず、実際のエラーと処理の流れで絞り込みます。エラーを消すために入力チェック自体を削除するのは不適切です。
第2問
プロジェクト内の480を検索すると、Javaの上限判定、画面の説明文、既存記録の学習時間が見つかりました。すべて720へ置き換えてよいですか。それぞれの扱いを答えてください。
一括置換してはいけません。学習時間の上限判定と、現行仕様を案内する画面の説明文は720へ変えます。既存記録の480は、実際に登録された学習時間なので480のまま残します。変更前の仕様や履歴として残す480も、現行仕様と区別して保持します。
第3問
変更前のテストには「481分なら例外になる」とあります。変更後の期待結果と、新たに必要な上限付近のテスト値を答えてください。
481分は新しい有効範囲なので、481が返る・登録できるという期待結果へ変更します。720分を許可し、721分を拒否するケースを追加します。1分・480分は引き続き有効で、0分は引き続き無効であることも確認します。要件変更を根拠にテストを更新し、失敗を隠すために消しません。
第4問
DTOはint型、DAOは受け取った数値をそのまま保存します。DBにはCHECK (study_minutes BETWEEN 1 AND 480)があります。どこを変更・確認する必要がありますか。
DTOのint型は720を表せ、DAOの受け渡しと列が変わらないなら、それらのコード変更は不要です。しかしDBのCHECK制約は720まで受け入れる定義へ変更する必要があります。既存データを保つ移行手順を検証し、DB作成用・テスト初期化用の定義もそろえます。実際に使うDBの制約が変わったこと、600・720の保存と721の拒否、既存記録が変わらないことを確認します。
第5問
721分を入力するとブラウザが送信を止めました。また、JUnitの時間チェックはすべて成功しました。これでWebアプリの仕様変更を完了にしてよいですか。追加する確認を答えてください。
完了とは判断できません。ブラウザが止めたため、サーバーへ721分が届いたときの拒否と未保存は未確認です。検証環境で実際に721を送信し、エラー内容とDBの件数・内容が変わらないことを確認します。加えて600・720の画面入力から保存・一覧の再表示まで、既存480分の記録の保持、0分などの拒否、ログイン状態や利用者の分離など関連する既存機能を確認します。JUnitの成功を、DBや画面まで検証した結果と混同しません。