テスト量より、先に見る場所を外したくない
開発におけるバグは、後の工数増加やユーザーからの信頼低下につながります。
もちろんテストは大事です。ただ、全部を同じ濃さで見るのは現実的ではありません。実務の中でテストを重ねるうちに、事故になりやすい場所には偏りがあると感じるようになりました。
私が特に気をつけたいと思っているのは、次の3つです。
- ループ処理
- 権限チェック
- 性能
この記事では、それぞれの観点で何を疑うか、どういうテストを置くと抜け漏れが減るかを整理します。
1. ループ処理
複数ユーザーへのメール送信や、一括更新、CSV取込のような処理では、ループの不具合がそのまま大きな障害につながります。
起きやすい原因
いちばん多いのは、変数の初期化漏れや前回ループの値の引き回しです。
- 前のレコードの値が残る
- 条件分岐の片側だけ値を更新している
- 一部のケースだけ配列やハッシュを使い回している
単体では通っても、複数件を連続で流した途端に壊れることがあります。
3件で見る「サンドイッチ法」
私は次の3件を並べるテストが有効だと感じています。勝手に サンドイッチ法 と呼んでいます。
1件目: すべての情報を埋める
2件目: 必須項目以外は空にする
3件目: すべての情報を埋める。ただし1件目とは別パターンにする
この並びで実行すると、前のレコードの値が混ざっていないかを見つけやすくなります。
チェックしたいこと
- ループごとに初期化されているか
- 前件の値を暗黙に参照していないか
- 空データを挟んだときに壊れないか
2. 権限チェック
権限周りの不具合は、単なる表示崩れでは済みません。情報漏えいや不正操作に直結するので、バグの中では優先度が高い場所です。
画面単位の権限に、作成・閲覧・更新・削除 が重なり、さらに役割が増えていくと、抜け漏れは一気に起きやすくなります。
起きやすい原因
- 画面ごとに個別実装していて判定が散らばる
- UIでは隠しているが、APIやURL直打ちの防御が弱い
- 役割追加時に既存画面の見直しが漏れる
先に作っておきたいもの
権限は、実装より前に 誰が何をできるか の表を持っておく方が安全です。
- 画面や機能
- 操作種別
- 役割
- 許可 / 不許可
この表があるだけで、レビューとテストの基準がはっきりします。
実装で気をつけたいこと
- 判定ロジックを一元管理する
- 権限がない場合の挙動を先に決める
- 画面表示だけでなく、APIやバックエンド側の両方で必ず防ぐ
「見せない」と「実行できない」は別問題です。権限チェックは後者まで守れているかを見たいです。
3. 性能
性能は、ユーザーから見るとそれだけで不具合です。
処理が遅い、画面が返ってこない、CSV出力が終わらない。こうした問題は、機能が正しくても体験を壊します。業務システムも例外ではありません。
起きやすい原因1: N+1問題
一覧画面や集計処理でよく出ます。クエリログを見ながら実装していないと、気づかないまま本番へ流れやすいです。
起きやすい原因2: 相関サブクエリ
コード上は短く書けても、SQLとしては重い形になっていることがあります。少なくとも「このSQLは何回走るか」を意識しておくと、危ない実装に早く気づけます。
テストで見たいこと
- 想定件数でどのくらい時間がかかるか
- SQLの発行回数が増えすぎていないか
- バックグラウンド処理に逃がすべき処理が同期で走っていないか
性能テストは後回しにされやすいですが、リリース前に一度は見ておく価値が大きいです。
まとめ
バグを減らしたいとき、テストの本数だけを増やすより、事故の大きい場所を先に守る方が意味があります。
- ループ処理は前件の値混入を疑う
- 権限チェックは表で管理し、バックエンドまで守る
- 性能は不具合として早めに見る
全部を完璧に押さえるのは難しいです。とはいえ、壊れやすい場所を先に意識しておくだけで、テストの質はだいぶ変わると思います。