テスト設計パターン(仮)を考える会 考えてみたメモ 仕様スニペット001
こちらについて考えてみました。
まずは仕様の理解から
親子関係にあるAとB(部署と従業員)
ここでは素直に人事労務システムの部署とそこに所属する従業員と捉えます
親Aの数は0〜48
数字が出てきた時点で境界値分析を使うことが確定します
0部署、1部署、n=48部署
子Bの数は全体で0〜128
数字が出てきた時点で境界値分析を使うことが確定します
AあたりのBは0〜16
子Bは子Aを必ず1つ持つ
部署に所属していない従業員はいないし、兼務もない。
子Bはいつでも削除可能
退職はいつでも可能と。手続きがないのが羨ましいですね。
物理削除なのか、論理削除なのか考える必要がありそうです。
関連づく子が一人でもいる限り、親を削除することはできない
ということは、おそらく物理削除でRESTRICT制約が入っています。
ここから、作られるであろうシステムを想定していきます。
データ構造を考える
前提としてデータ構造を確認します。以下でなかったら考え直し。
作る機能群
画面からAPIをfetchしてもろもろやっていくシステムで考えます。
多分部署と従業員でそれぞれCRUDに対応したAPI作ると仮定します。
部署(A)の表示
部署(A)の作成
部署に親部署があるとは書いてないですが親子関係にすると「兼務」に引っ掛かる気がするのでないことにします
部署(A)の更新
今回の課題とはあまり関係がなさそうなので省略
部署(A)の削除
従業員(B)の表示
従業員(B)の作成
従業員(B)の更新
部署の移動があるので考慮(後から追加)
従業員(B)の削除
で、「それらを呼び出す一つの画面がある」と仮定します。
テストケースを考える
境界値でいけそうです。一部デシジョンテーブルを使います。
部署(A)一覧の表示(GET /api/v1/departments)
0件(empty UIの表示), 1件, 48件まで出力できること
削除した部署が表示されないこと
部署(A)詳細の表示(GET /api/v1/departments/:id)
0人(empty UIの表示), 1人, 16人まで出力できること
削除した従業員が表示されないこと
削除した部署の場合404レスポンスが返ること
部署(A)の作成(POST /api/v1/departments)
0件、47件のとき部署を作成できること
48件以上のとき、400レスポンスとエラーメッセージが返ること
部署(A)の削除(DELETE /api/v1/departments/:id)
該当の部署が削除済みのとき、404レスポンスとエラーメッセージが返ること
該当の部署の従業員数が1以上の場合、400レスポンスとエラーメッセージが返ること
該当の部署の従業員数が0の場合、204レスポンスが返されること
従業員(B)一覧の表示(GET /api/v1/employees)
所属している従業員が0件(empty UIの表示), 1件, 128件まで出力できること
削除した従業員が表示されないこと
従業員(B)詳細の表示(GET /api/v1/employees/:id)
未削除の場合従業員の詳細と200レスポンスが返ること
削除した従業員の場合404が返ること
従業員(B)の作成(POST /api/v1/employees)
0件、127件のとき従業員を作成できること(201)
従業員が全体で128件以上のとき、400レスポンスとエラーメッセージが返ること
所属予定の部署の所属従業員が15人のとき登録できること
所属予定の部署の所属従業員が16人以上のとき400レスポンスとエラーメッセージが返ること
デシジョンテーブルで整理した方がいいかもしれません。
従業員(B)の更新(DELETE /api/v1/employees/:id)
該当の従業員が削除済みのとき、404レスポンスとエラーメッセージが返ること
該当の従業員が存在する場合、かつ該当の部署が15人のとき200レスポンスが返され部署が移動されること
該当の従業員が存在する場合、かつ該当の部署が16人のとき400レスポンスとエラーメッセージが返ること
デシジョンテーブルで整理した方がいいかもしれません。
従業員(B)の削除(DELETE /api/v1/employees/:id)
該当の従業員が削除済みのとき、404レスポンスとエラーメッセージが返ること
該当の従業員が存在する場合、204レスポンスが返されレコードが消えること
今回は考えませんが、受け入れテストで「まっさらなところから部署を登録して行ってマックスの件数まで登録、従業員の削除と部署の登録まででき諸々のUIがデザイン通りであること」までテストしたら完了です。
考えながら思ったテスト観点の決め方
数字が出てきた時点で境界値分析が必要だと考えました。
状態遷移も考えましたが、単純に人数だけなので要らないと考えました。
親あたりの子の制約があるので従業員の追加と更新に関してのみデシジョンテーブルを使うと思います。(複数の条件がある場合はデシジョンテーブルを使う)
追加と削除と聞くと、CRUDの他の(RとU)も要らないか考えました。
中間テーブルの可能性を結構考えましたが、問題文を読んで意図的に削除しました。
この記事が気に入ったらサポートをしてみませんか?