微細な不具合発見と報告のメリット
はじめに
こんにちは！VoicyでWebフロントエンジニアをしているCちゃんです。
最近はAndroidの開発に挑戦しています！
今回は、社内でやってほしい不具合発見と報告のメリットについてお話しします。
みなさんは微細な不具合を見つけることはありますか？
たとえ、微細だったとしても不具合を一度見つけてしまうと、そのサービスを触るたびに気になりますよね…。あれ直ったかなとたまに試してみたりして。頭の片隅に残ってしまいます。
私は社内で1番微細な不具合を発見し報告している自負があります。QAエンジニアでもテスターでもないのになぜ見つけるのかってたまに聞かれます。それは課題発見が趣味だからです。
もちろん、細かいことを懸念しすぎたり不具合ばかり修正していたら、他のリリースが遅れるという問題もあります。ただ、放置しておくとサービスが不具合だらけになってしまいます。
背景
Voicyでは、不具合報告をするためのSlackチャンネルがあります。
このチャンネルでの半年間の不具合報告の件数をざっくり計算したところ、私は、エンジニア約20人の中では1番目、社内で約60人中4番目の結果でした。不具合に接しやすい仕事をしているメンバーもいる中で、数多くの報告している自負があります。
そんな中、私よりサービスを使っているメンバーもいるはずなので他のメンバーにも積極的に不具合を報告してもらいたいと思い、この記事を書きました。
目的
今回、不具合発見と報告のメリットのお話をする目的は、こんなに細かい小さい不具合を気にして報告している人がいるんだ、こんなスタンスでいいんだと報告しやすい環境を作ることです。
社内で報告しにくい環境というわけではないです。ただ、微細な不具合については、私でもまだ報告に躊躇うことがあります。他のメンバーもたくさん報告するようになったら、自分自身も気軽に報告できて嬉しいなと思っています。そこで、自警を込めて今回のお話をします。
微細な不具合とは
単に不具合というと、仕様に反した動作のことを指します。
この記事でいう微細な不具合は、以下の2つです。
複数の手順を踏んで再現する手順の細かい不具合
表示等のみがおかしい影響の小さい不具合
2つをエンジニア視点で解説します。
1. 複数の手順を踏んで再現する手順の細かい不具合
細かい不具合は、QAで確認していないことが多いです。例えば、新規機能追加時に関連しない既存機能と連動した手順でのケースまでは基本確認していません。
すべての細かい手順をQAで確認するとテスト範囲が計り知れず、リリースまでの時間が長くなってしまいます。また、そこまで細かい手順と同様の手順を踏むユーザが少ないと判断します。この2つの理由から、細かすぎる手順すべては確認しない意思決定をしています。
不具合によりますが、小さい不具合よりは再現手順を明確に定めたり修正方針を固めたりする調査や修正に時間がかかることが多いです。再現手順を明確に定めるまでに時間がかかることも多いです。ただ、手順が明確かつ100%再現すれば再現手順を明確に定める調査自体は比較的短時間でやりやすいです。
2. 表示等のみがおかしい影響の小さい不具合
小さい不具合は、QAのケース漏れが多いです。例えば、文字の見切れや軽微なレイアウト崩れなどです。数字などのシリアスなものの表示に関しては影響が大きいので、微細な不具合ではないです。ちなみに、表示している文字や数字自体が異なる場合、フロントエンドではなくバックエンドの問題のことが多いです。
表示のみが新規機能追加によりデグレすることも多いです。このケースにも影響があったのかと不具合が見つかってから気がつきます。
表示だけであれば同様の環境で同じ手順を踏むと100%再現すると思います。ケース漏れで気が付かなかっただけかつ再現率が100%のことが多いため、調査と修正は比較的容易です。
不具合発見と報告のメリット
結論からいうと、微細な不具合でも日常的に報告するメリットには以下があると考えます。
不具合の報告が早くなる
不具合を修正してもらえる可能性が生まれる
不具合でなかった場合でも仕様の把握が進む
報告してもらった不具合と同様のものが発生しないように、新規機能実装時に仕様検討に入れることができる
不具合を報告しやすい環境があれば、普段報告していなかった人がクリティカルな不具合を見つけても報告しやすいです。
また、不具合に気がついて誰かが報告してくれた場合、開発者自身が気がついた場合以外で、不具合が修正される場合を私は知りません。報告することで修正してもらえる可能性を生み出せます。
たとえ報告した結果、不具合でなくても、たくさん報告されていれば気にならないと思います。また、報告したことでその報告スレッドを見た人全員が仕様を把握できるメリットがあります。
新規機能実装時によくあるパターンとして、
ちょっと問題がある既存仕様があったとして、その仕様を新規機能実装でも踏襲するかどうか検討した時に、不具合として困っている人がいないから工数削減になるし既存仕様でいいかと考えるパターンがあります。
これは、不具合として報告を受けていれば新規機能の実装では直せる可能性が高まります。ですが、開発者目線のエンジニアだけが主張してもあまり検討してもらえないことも多いのが現状です。
あまり考えたくないですが、不具合を報告しにくい文化ができた場合、
1番怖いのは、細かいから報告しなくていいやとか、まあ誰か報告するだろうと放置されて、潜んでいた元凶となる大きな不具合に気がつけなかったり、報告が遅れたりすることです。
2番目に怖いのは、いつの間にか微細な不具合かたくさん出ていて既存機能がデグレしていくことです。
それでも悩んだら
みんな優先度の高い仕事からしている中、これ報告していいのかなと悩んでしまうことは誰にでもあると思います。
こういった社内で報告をするかどうか悩む場合は以下の3つに分類できると考えます。
不具合か仕様かわからない
再現手順がわからない
微細な不具合である
1つ目について、報告するか悩んだ動作が不具合であることもあるので、躊躇わずに確認してほしいし、確認できる環境にしたいです。
2つ目について、報告回数が多いと優先度が高くなるので報告してもらいたいです。どうやっても再現手順がわからず再現しないものでも本番環境で再現したものは私は報告するようにしています。
3つ目について、正直この不具合さすがに気がついているよなと考えることもありますが、私の場合、初めての報告だったということの方が圧倒的に多いです。
一応報告前には、社内のSlackで関連ワードを調べたり、不具合として起票されていないか検索したりした上で報告していることが多いです。
私は今まで検索でヒットしたことは少ないし、過去の仕様が検索で出てくる場合もあるので注意が必要ですが、既存で報告されているかどうか気になる方はやってみるといいかもしれません。
エンジニアとしては、仕様把握をしてもらえると不具合かどうかの判断もしやすいと思うので、仕様の確認はどんどんしてもらいたいです。こちらからも必要な仕様は提供していくように継続して心がけていきます。
おわりに
今回は、エンジニア視点で不具合発見についてお話ししました。
書きたいことを書きました。
報告してもらった不具合の中には、優先度が高くすぐに対応するものもあります。ただ、優先度が低くてすぐに対応できないものの方が割合は多いです。でも、報告されていれば隙を見て直せる不具合もあるし、メリットで述べたように報告してもらった不具合と同様のものが発生しないように新規機能実装時に仕様検討に入れられることがあります。
ちなみに、不具合報告のデメリットについては思いつかなかったので書きませんでした。
この記事が気に入ったらサポートをしてみませんか？