こんなQAは嫌だ! ~バグ起票が早すぎる!~

QA

今回は「こういうQA活動にならないように気を付けよう!」という話をするよ!

はじめに

本記事は以下サイトを参考に記載しています。
興味ある方は是非原文を読んでみて下さい!

How to Deal with Difficult People on Software Projects
Software is easy. People are hard.

バグ起票をはやく書くことにこだわるテスター

テスト業務としてバグを検出することは大切ですし、そのためにテストをしているという見方も出来ます。
もちろん、遅いより速いほうが仕事は良いことが多いですし、バグ起票を速く書くこと自体が悪いわけではありません。

早く書くことに注力しすぎて、以下のような状態にならないように気を付けていきましょう!

バグレポートが詳細ではない(伝わらない)

バグレポートが簡易的すぎて「伝わらないバグレポート」になっていないでしょうか?

簡易的に書いているからこそ、早い起票になっている場合は注意しましょう。

重複しているバグレポートがある

単純な重複はさすがになくしましょう。

ここで問題なのが「根本的な原因が同じだけどQAで気づけない」不具合です。

当然仕方がない部分もありますが、なるべくQAでも意識して重複なのかどうかを可能な限りチェックしましょう。

多少の重複は気にせず、ガンガンチケットを起票してほしい!という場合もありますが、バグ起票をはやく書くことに気を取られて重複しているのであれば注意しましょう!

バグの再現に時間をかけていない

バグ起票をはやく書くことを意識しすぎて、バグの再現率について疎かになっていないでしょうか?

バグレポートにおいて、再現率は重要な情報です。
100か100以外だけでも、修正する際の重要なヒントになります。

また、何かの発生条件があるのに見落としている可能性もありますし、そうなると開発側で再現が出来ず手戻りが発生するかもしれません。

多くの企業ではバグが発生した際の確認回数を指定することもあります。

もし再現確認回数のルールがない場合は見直してみてみましょう!

おわりに

今回紹介したことは会社や開発組織によっても当然変わってきます。
質はどうでもいいから早くバグ起票をしてくれ!
ということもあります。

最適な品質活動は組織によって異なりますので参考の情報としましょう。

テスト実行および、バグを起票することが目的ではありません。
QAエンジニアとして、「品質を上げる」ための活動ということは日頃から意識していきましょう!

タイトルとURLをコピーしました