バグはゼロにできないが、減らし方はある
バグは嫌です。
開発している以上、完全にゼロにするのは難しいです。
ただ、だからといって何もできないわけではありません。
実務でテストやレビューをしていると、バグが出やすい場所には偏りがあると感じます。
全部を同じ濃さで見るのではなく、事故になりやすい場所を先に疑う。
この考え方が大事だと思っています。
自分が特に見たいのは、次の3つです。
- ループ処理
- 権限・状態分岐
- 性能・データ量
ループ処理は、少量データでは気づきにくい
ループ処理は、バグが見えにくいです。
1件や2件のデータでは問題なく動いても、100件、1,000件になると急に問題が出ることがあります。
たとえば、
- メールを複数ユーザーに送る
- CSVを一括取り込みする
- 一覧画面で関連データを表示する
- 複数レコードを更新する
こういう処理です。
見るべき観点は、次のようなものです。
- 0件でも動くか
- 1件でも動くか
- 複数件で重複しないか
- 途中でエラーになったときどうなるか
- 処理済みと未処理が混ざらないか
- N+1が起きていないか
RailsのN+1問題を見つけて、動作遅延を改善する と同じで、データ量が増えたときの挙動は早めに見たいです。
権限と状態分岐は、組み合わせで漏れやすい
権限まわりもバグが出やすいです。
特に、状態分岐と組み合わさると漏れます。
たとえば、
- 管理者
- 一般ユーザー
- 未ログイン
- 自分のデータ
- 他人のデータ
- 公開
- 下書き
- 削除済み
こういう条件が重なると、頭の中だけでは追いきれません。
テスト観点としては、表にすると見やすいです。
| ユーザー | 対象 | 状態 | 期待結果 |
| --- | --- | --- | --- |
| 管理者 | 他人の記事 | 公開 | 閲覧できる |
| 一般ユーザー | 他人の記事 | 下書き | 閲覧できない |
| 未ログイン | 公開記事 | 公開 | 閲覧できる |
| 未ログイン | 下書き記事 | 下書き | 閲覧できない |
権限は、動けばよいでは済みません。
見えてはいけないものが見えないことも、確認しておきたいです。
AI時代の開発者に必要なセキュリティの基本 にもつながりますが、権限チェックは安全側に倒したいです。
性能は、あとから気づくとつらい
性能問題は、ローカルや少量データでは見えにくいです。
でも本番に近づくほど、急に顔を出します。
- 一覧画面が遅い
- CSV出力に時間がかかる
- メモリを使いすぎる
- DBへの問い合わせが多い
- 画像や添付ファイルが重い
こういう問題は、あとから直すと影響範囲が広くなりがちです。
最初から完璧にする必要はありませんが、少なくとも「増えたときにどうなるか」は見たいです。
Railsのループ処理でメモリ使用量を抑える。N+1の次に見ること のように、件数が増えたときの処理は早めに気づけるようにしておきたいです。
テスト観点メモを先に作る
実装してからテストを考えると、どうしても実装に引っ張られます。
なので、先に小さなテスト観点メモを作るのがよさそうです。
今回の変更:
- 記事一覧にタグ絞り込みを追加する
見る観点:
- タグなし記事が消えすぎないか
- 存在しないタグIDでエラーにならないか
- 公開記事だけ表示されるか
- 下書きが混ざらないか
- ページネーションと併用できるか
これを先に書くだけで、実装後の確認が変わります。
結合テストで想定外のバグを見つけるには、開発者目線を一度外す と同じで、先に観点を外に出しておくと、思い込みを減らせます。
明日からできること
バグを減らすために、まずはPR前にこの3つだけ見るのがよさそうです。
- ループ処理は0件・1件・複数件で見たか
- 権限と状態の組み合わせを見たか
- データ量が増えたときの挙動を見たか
全部を完璧にテストするのは難しいです。
でも、事故になりやすい場所を先に疑うことはできます。
まとめ
バグはゼロにできません。
ただ、出やすい場所を知っておくと、減らし方は見えてきます。
ループ処理、権限・状態分岐、性能・データ量。
この3つは、実務でも特に注意して見たい観点です。
テストは数を増やすだけでなく、どこを見るかが大事なのだと思います。