はじめに👏
はじめまして。
エックスポイントワンでQAエンジニアをしております、山﨑です。
今回は品質保証向上のため弊社でやっている取り組みの一つでもある
「修正箇所の影響範囲を明確に書く」ことについてお話ししていきたいと思います！
修正箇所の影響範囲の明確化とはなんぞや🤔
エックスポイントワンではGitHubを使って不具合（issue）を管理をしており、
テスターは不具合発見をした際、issueを立てます。
開発はそのissueの内容を確認して、該当箇所の修正に取り掛かります。
不具合修正後に、テスターが修正確認を行うのですが、
修正を行ったエンジニアに修正箇所がどの箇所まで影響があるのかを明確にしてもらうようにしております。
以下の例を見てみましょう。
例）一つのシステムでA機能とB機能があるとき
- テスターはA機能のテストは終了している
- B機能テスト時に不具合があったためissueを立てる
- 開発は2のissueを元にB機能の不具合を修正
- 修正したロジックがA機能でも使われていたためA機能でも修正
- 開発は「修正済み」のみ伝え、テスターに修正確認依頼。
このときテスターはA機能まで修正されていることは知らず、
B機能の修正確認のみで終わってしまうと思います。
また、A機能はテストが終了しているため、再度テストを行うこともありません。
そのため、例2の修正によってA画面でデグレが発生していたとしても気づくことができず、
不具合を見逃してしまうことになります。
例4を明確に記載しテスターに伝えることで、テスターはB機能の修正確認だけでなく、
A機能も再度テストすることができ、もしデグレが発生していても気づくことができます。
実例✨
下記画像は実際の弊社のプロダクトで発生した 「◯◯検索画面にて、◯◯番号欄に文字列を入力し検索を行うと500エラーになる」 という不具合の修正時のコメントです。
※一部伏せ字にしております。
不具合は特定の画面で番号を入力する欄に文字列を入れて検索を行うと500エラーになるというものでしたが、
修正内容は数値以外を入力できなくし、また他箇所にも適応されました。
そのため、修正確認時は変更箇所全てを確認することができました。
取り組み前は・・😨
この取り組みを始めたきっかけは「不具合漏れ」があったからです。。
前述の例のように、影響範囲を明記していないことで、確認しなかった影響範囲部分で不具合が発生し、
システムの品質に大きく関わってしまいました。
取り組み後感じたこと🎉
より細かい修正確認ができる
影響範囲を明確に示すことでテスターはその範囲に集中して修正確認を行うことができます。
条件分岐などがあるロジックなどでは、明確に記載することでその条件が整理され、
考慮不足なども発見しやすくなりました。
当事者でなくても状況判断がしやすい
影響範囲が明確でないと、どこをどのように修正したかがissueだけでは判断するのは難しいです。
ですが明確化されることでissueを書いたテスターと修正したエンジニアの当事者だけではなく、
誰でもissueを確認することで不具合の状況を掴みやすくなりました。
知見が深まる
影響範囲を明確にしてもらうことで、テスターの知見が広がっていきます。
実際に、不具合発見段階であらかじめ同様のロジックを使っている箇所の確認をするなど、
テストを実施するときに意識できるようになりました。
まとめ✍️
修正範囲の影響範囲を明確かするというのは、少し手間がかかる部分だと思います。
ですが、不具合漏れを防いだり、余計な確認の手間が省けたり、
自分自身で見返したときに状況がすぐわかることを考えると、
品質の向上には欠かせないプロセスだと実関しました。
弊社ではこの取り組みを続けていき、よりよい品質が提供できるよう日々精進してまいりたいと思います！
Discussion