ソフトウェアの品質を学びまくる

ソフトウェアの品質、ソフトウェアテストなどについて学んだことを記録するブログです。

バグの原因と結果は1:1じゃない

miwaさんがJaSST東北から以下のツイートを送ってくれました。

バグの現象(見た目)だけで重篤度?を決めるのはホント危ないです。バグの原因とそこから想像する一番嫌なことで決まるので「軽微なバグだな」と思っても軽視しないようにって、いつも自分に言い聞かせてます。みんなも気をつけてね。#jassttohoku

こちらのツイートを見て、「なるほどその通りだ。そしてこれって、普段自分が考えていることとになるやつだ!」と思って、ワンページサマリーを作ったのでした*1

ワンページサマリー

テストで見つけたあるバグの現象は、そのバグの現象の一例でしかない

上のスクショの右のほうです。
見つけた現象E0は、その原因となった原因C0(ここではバグ)の本当の「重さ」を表すとは限りません。
E0からC0に行って、C0が起こしうるたくさんのEnを検討して、そのうち一番キツイEmaxから重要度を判断する必要があります。
イメージとしては、「正常運用中ならこれが起きても問題ないけど、系切替中に起こったら両系断にならない?」みたいな感じですね。

あるバグを見つけた手順は、そのバグを再現させる手順の一例でしかない

上のスクショの左のほうです。
現象E0を見つけた原因C0(ここでは再現手順*2)が、本当の「起こりやすさ」を表すとは限りません。
極端な話ですが、「1秒に100回連続クリックしたらクラッシュした」というバグレポートがあったとして、「100回連続クリックするやついないだろう、対処不要」とはなりません。1秒に2回連続クリックでも起きるかもしれません。もちろんテストする人は、その現象を起こすための「最少手」を特定しようとしますが、バグの原因がわからないことには、「本当の再現手順」を特定することは困難になります。

まとめ

絵に描いてみると当たり前なのですが、
「いや、そんな手順誰もやらないので発生頻度・低、対処不要」
「いや、大した事象じゃなく影響は小さいので重要度・低、対処不要」
って意外によくある風景なんじゃないですかね?

  • テストで見つけたあるバグの現象は、そのバグの現象の一例でしかない
  • あるバグを見つけた手順は、そのバグを再現させる手順の一例でしかない

ということを意識しておきたいものですね。

ご参考

miwaさんのツイートに関係するブログエントリーは、こちらです。
このような、技術とエッセイが同居したような文章を書けるようになるには、どういう練習をすればいいのでしょうね? 尊敬しています。

miwa719.hatenablog.com

バグの「発生頻度」については、これまで人によって考え方が違うので、こちらで整理しています。

www.kzsuzuki.com

そのバグは地球破壊爆弾になるかもしれない by Midjourney

*1:原因・手順・バグ、結果・現象など、言葉が揺らいでいるのを見逃していただきたい。

*2:ここで対称性の破れが起きていて、前のパラグラフでは原因とはバグそのものを意味していたのに対し、このパラグラフではそのバグを発現させるためのキッカケ・手順という意味で使っています。きれいに整理することができませんでした。誰も気にしないかもしれないけど。