【不具合調査で考えていること】第4回：正常なケースと比較して原因を絞り込む

不具合が発生したとき、そのケースだけを調べていても、原因が見つからないことがあります。

ログを確認しても、どの処理が異常なのか分からない。
データを見ても、問題がありそうには見えない。

そのようなときに役立つのが、同じ処理が正常に完了したケースとの比較です。

不具合が起きたケースだけでは判断しにくい

たとえば、特定の注文だけ登録に失敗したとします。

失敗した注文データを確認すると、入力項目もそろっていて、一見すると問題はありません。

しかし、正常に登録できた注文と並べてみると、次のような違いが見つかることがあります。

• 商品の種類が異なる

• 入力された文字数が長い

• 利用者の権限が異なる

• 操作した時間帯が異なる

• 外部システムから返された値が異なる

• 処理にかかった時間が長い

不具合が起きたケースだけを見ていたときには気づかなかった違いが、比較によって見えてきます。

比較する条件をできるだけそろえる

正常なケースなら、どれと比較してもよいわけではありません。

条件が大きく異なるケースを選ぶと、違いが多すぎて、どれが不具合に関係しているのか判断しにくくなります。

たとえば、注文登録の不具合であれば、次のような条件をできるだけそろえます。

• 同じ利用者

• 同じ端末やアプリのバージョン

• 同じ種類の商品

• 同じ操作手順

• 近い時間帯

• 似た内容の入力データ

条件が近いにもかかわらず、一方は成功し、もう一方は失敗している。
その二つの間にある違いが、原因を絞り込む手掛かりになります。

見つけた違いが原因とは限らない

比較によって違いが見つかっても、すぐに原因だと判断することはできません。

たとえば、失敗した注文だけ備考欄が長かったとしても、それだけで文字数が原因とは断定できません。

別の注文でも同じ長さの備考を入力して確認する。
文字数を少しずつ変えて、どこから失敗するのかを調べる。

このように条件を一つずつ変えることで、その違いが不具合に関係しているかを確認できます。

複数の条件を一度に変えると、どの変更が結果に影響したのか分からなくなります。

比較で見つけた違いは、原因ではなく、まずは確認すべき候補として扱います。

ログも正常時と比較する

ログを調べるときも、エラーが記録された箇所だけを見るとは限りません。

同じ処理が正常に完了したときのログと並べることで、

• どの処理までは同じなのか

• どこから流れが変わっているのか

• 本来出力されるはずのログがないのか

• 処理時間に違いがあるのか

を確認できます。

異常時のログだけでは意味が分からなかった記録も、正常時と比較することで、その位置づけが分かることがあります。

まとめ

不具合が起きたケースだけを見続けても、何が通常と違うのか分からないことがあります。

そのようなときは、条件の近い正常なケースと比較します。

ただし、見つかった違いが、そのまま原因とは限りません。

比較によって原因の候補を見つけ、条件を一つずつ変えながら関係を確認していく。

正常なケースは、単なる成功例ではありません。
不具合がどこから始まったのかを見つけるための、重要な比較対象になります。

おすすめの一冊

既存コードの動作を確認し、安全に修正する考え方を学ぶなら、マイケル・C・フェザーズ著の『レガシーコード改善ガイド』が参考になります。

Kindle Unlimitedなら無料で読める本も

対象の技術書であれば、Kindle Unlimitedなら追加料金なしで読めます。

まだ利用したことがない方は、初回30日間無料体験もあるので、この機会に試してみるのもおすすめです。

※対象書籍は時期によって変わるため、利用前にご確認ください。

※上記はAmazonアソシエイトを利用しています。