真実はいつも1つ～未再現不具合を考える

Bugs Life

» 2021/06/04

今回のコラムは"テストエンジニアあるある"からディベートの形式で書いてみようと思います。

お題は「一度しか発生しなかった不具合を報告するか、しないか」

では、それぞれの主張を聞いてみましょう。
読んでくれる方も自身の経験でどうだったか思い返してみてくださいね。

しない派の主張

• テスト手順外の要因で発生している可能性がある
• テストミスかも
• 再現しないのだから、調査のしようがない
• 不具合データベース上にいつまでも残り続けるため、報告などに支障が出る
• 「また再現した時に起票してください」
  "しない派"の主張としてはこんな感じでしょうか。

する派の主張

• たとえ一度でも発生したことに間違いはない
• 再現しない、とも言いきれない(10回で発生しなくても100回ではどうか)
• 起票しておかないと、いつか忘れる
• 他の不具合と合わせた時に発生する原因がわかるかもしれない
  "する派"の考えとしてはこんな感じでしょうか。

私の場合は

私自身のこれまでの実務では"しない派"寄りでした。
「また再現した時に起票してください」これは実際に言ったと思います。
テスト実行メンバーに経験が浅い人が多かったことで、テストミスの可能性をかばいきれないという事情もありましたし、このような不具合は開発チームからもよく問い合わせがくるので、それが煩わしく思うがゆえに起票しない方を選びがちだったと思います。

ただ、今は"する派"に寄っていると思います。
報告上の見せ方は工夫次第で何とでもなりますし、後々の分析のため、不確定でもデータは多い方が良いと考えるからです。
ただ、最終的にテストミスと結論付けられるしまう怖さもあるのは確かです。

テストミスではありません

こうした未再現不具合を抱えることで開発チームからのあたりも厳しくなることがあります。

「開発チームのメンバーが再現確認したが発生しなかった」
「本当にテストミスではないのか」
「この不具合を残したままリリースできない」
「本当にテストミスではないのか(2回目)」

こうなるとテストリーダーも段々不安が増してくるもので、
「メンバーに再度確認してきます」と謎の回答をしてテスト実行者にヒアリングに行くわけですが、
テスト実行者「いやいや、出ましたよ。テストミスではありません」
テストリーダー「本当に間違いがない？バージョンとか諸々...」
などと、押し問答している内に不穏な空気になってしまうこともあったりします。

再現しない不具合の末路

このような未再現不具合ですが、どのような末路を辿るのか、不具合管理で使いそうなステータスと合わせて書いてみました。

✖「却下」　取り下げられ、なかったことにされてしまう
✖「不明」　原因がわからないため対処のしようもない、何もしない
✖「解決済み」　『再現しない、ということがわかった』
✖「調査中」　時の経過と共に、記憶からも進捗からも忘却の彼方へ
△「(次PJへ)持ち越し」　高確率で次PJには移行されない
〇「対応済み」　根本は直していないが、次に発生した時に解析できるように対応

「未完了」扱いのステータスでは気に留めていますが、
上記で✖でも「完了」扱いのステータスとなると、抱えているものがなくなることで思わず安堵してしまうというのは、心理としてあると思います。

未再現不具合をもう少し考える

私自身は様々な経験を積んだ今、未再現不具合ほど重要である、と捉えています。

まず、ソフトウェアのコードは何回実行しても消耗しないため、単一の処理は何回実行しても再現する(100％) or 再現しない(0％)の世界なので、再現率20％とはなりません。
となると、周辺で実行毎に値の変わるデータ、繰り返されることで蓄積されるデータ、設計／仕様上の矛盾、ソフトウェアのエンジニアが気付きにくいハードウェアの要因など、考察は広く悩ましくなります。

上記を踏まえると、再現性の高低は修正容易性(修正のしやすさ)と比例してくるのではないでしょうか。
　・　再現性：高い　＝　修正容易性：高い
　・　再現性：低い　＝　修正容易性：低い

未再現であればあるほど、修正が難しく、修正コストが高くなるということです。
あとは、未再現の不具合内容がユーザにどの程度影響するかを分析し、方針を決めていくことになります。

これからのソフトウェア開発を考えると、ローコード／ノーコード開発～自動デバッグの進化により単体レベルの不具合は減少するため、統合・システムレベルの不具合とテストエンジニアはより密な付き合いになります。

テストミスとなる要因は減らし、未再現の不具合は「嘘ではないもの」として、様々な分析を用いて真実に導いていく、というのがこれからのテストエンジニアの不具合への向き合い方なのではないでしょうか。