バグやだ。
開発におけるバグは、後々の工数の増大やユーザーからの信頼を失う原因になりかねない永遠の悩みの種ですよね。
バグを削減するために、まず真っ先に思い浮かぶのはテストですが、0にするのは現実的ではないですし、あまりにやりすぎるとコスパが悪くなるという面もあります。だからこそ大事なのはしっかりと優先順位をつけて必要十分なテストを行うかが大事だと感じています。
自分自身、結構テストを業務で行ってきたというのと、その過程でバグが多い機能・観点というのがわかってきたので、原因とその対策について書き記しておこうと思います。
バグ観点1：ループ処理
システム開発では、ループ処理を使う場面が多くあります。
例えば、複数ユーザーへのメール送信や、多数のレコードをCRUD（作成・読み取り・更新・削除）する処理などです。
ループ処理に不具合があると、大きな障害につながりやすいので注意が必要です。
原因：初期化忘れ
ループ処理でのバグの原因は、使用する変数の初期化忘れがほとんどです。
前回のループの残り値を参照してしまったり、意図せず値を上書きしていたりする可能性があります。
サンドイッチ法！！
これを防ぐ簡単なテスト方法があります！その名もサンドイッチ法！（勝手に命名しています）
たとえば、次の3つのレコードを用意してテストすると、上書きや意図しない値の引き回しがないかを確認しやすくなります。
1レコード目：すべての情報を埋める
2レコード目：必須項目以外は空
3レコード目：すべての情報を埋める（1レコード目とは異なるパターンで）
この3つを続けてループ処理にかけて結果を確認することで、 前のレコードの情報を誤って利用していないかを簡単にチェックできるのがポイントです。
自動テスト・手動テストいずれでも応用できるため、ぜひ取り入れてみてください。
ポイント
・ループ処理での変数の初期化確認
・サンドイッチ法で前レコードの情報が混ざらないかを効率的に検証
・テストデータの準備がテスト精度を左右する
バグ観点2：権限などのチェック処理
シンプルな権限設計であればチェック漏れは少ないですが、画面単位×CRUD操作に加え、管理者／一般ユーザー以外の多様な権限が増えてくると、 権限チェックの抜け漏れが起こりやすくなります。
原因：管理・設計不足
画面単位×CRUD操作×多様な権限となると膨大な権限チェックが必要になるため、それを未然に防ぐために、FATになる前に設計していく必要があります。
※長年運用している権限の方法を変更するのはかなり難しいと思いますので、初めのうちにいかに不整合が起こりにくい設計にするかが重要だと感じています...
権限管理の抜け漏れを防ぐ工夫
権限管理の抜け漏れを防ぐためには、いくつかの工夫が必要です。
まず、一元管理を徹底することで、権限チェックを共通メソッドやミドルウェアで一括管理し、各所でバラバラに実装することによるミスを防ぎます。
これにより、システム全体で一貫した権限制御が可能となります。
次に、画面設計段階でのエラー強制を行い、権限がない場合は即座にエラーを返す仕組みを組み込むことが重要です。
これにより、ユーザーが誤って許可されていない操作を試みた際に、即時に適切なエラーメッセージを表示し、不正なアクセスを防ぐことができます。
また、テストリストの作成も欠かせません。画面ごとの操作と権限の組み合わせを整理し、それをもとにテストを可視化することで、どの権限でどの操作が可能かを明確にします。
これにより、テスト不足による権限の抜け漏れを防ぎ、より堅牢なシステムを実現できます。
ポイント
・権限周りのチェック漏れは重大セキュリティ事故につながる可能性
・一元管理でコードをシンプルに
・事前設計が抜け漏れ防止の鍵
バグ観点3：処理速度
処理速度はユーザーエクスペリエンスに直結します。
特にTo C向けのサービスでは頻繁に意識されますが、 BtoBや業務系のシステムでも疎かにできません。
原因1：N+1問題
処理遅延の要因として最もよく見られるケースだと思います。
クエリ実行ログを確認し、異常な呼び出しがないかチェックしながら実装していくことが大切です。
原因2：相関サブクエリ
こちらも頻繁に見られるケースだと思います。まずは簡単でもいいので、SQL実行イメージをもちながら実装すると、重そうな処理だなと事前に設置できるのでは？と思っています。
負荷テストをフローに取り込むことが大事
負荷の問題はシステム開発をしていれば常につきまといますし、意図せず重い実装をしてしまうことはあります。
ですが負荷テストをフローに盛り込んで、事前に察知・修正できれば何の問題もありません！
あと、パフォーマンス修正って時に100倍とか速くなり、とっても楽しいです！
ポイント
・パフォーマンス面も早期にテストして問題を発見する
・SQLのチューニングを習慣づける
逃げずにやる
テストは地味で面倒ですよね、わかります（特に手動テスト）。
でもしっかり計画を立てて、過不足なく効率的にテストすれば、意外と素早く良いテストができると思います！
設計時も、常に納期に追われているだろうとは思いますが、未然にバグを防ぐ形に落とし込むことが、後々のバグ修正時間をなくすことができると思います。
共に頑張ってまいりましょう!
本記事の視点がみなさんの役に立てば幸いです。