🗒️

検証時の不具合起票について

2024/11/22に公開

こちらの記事は、LUUP のTVCM放映に合わせた一足早い「Luup Developers Advent Calendar 2024」の22日目の記事です。

はじめに

こんにちは、QAチームのかすみです。
今回はLuupのQAチームの不具合の扱い方についての記事です。

使用ツール

QAをするにあたって切り離せないものがあります。不具合管理です。
スプレッドシートやJIRA、Redmine、Backlogなど起票ツールは星の数ほどありますが、うちのチームではGitHubを使っています。
理由として他チームとのやり取りがほぼGitHubメインで、ストレスなくやり取りができる為です。

不具合の分類について

分析用にラベルをつけています。

  • クライアント:iOS、Android、Serverside
  • 不具合分類1:UI、Logic
  • 不具合分類2:ログイン/登録、アカウント操作、アプリ外、エラー、マップ、ライド中、開始手続き、返却手続き、管理画面
  • 対応判断:対応不要

また、ラベルとは別で「QA Priority」という不具合の対応優先度をfieldに追加して、QAチーム以外に不具合の影響度合いを可視化しています。

  • Critical:テスト中のバージョンで直さないといけない(今すぐ)
  • Major:テスト中以降のバージョンで直してほしい(なるはや)
  • Minor:直せる時に修正してもらえればOK(積み)
    QA Priority

Criticalはすぐ直さなければユーザーが利用する際に大きな影響を与えてしまうものや、そもそもの要件定義を満たさないものにつけています。
Majorはすぐに対応が必要ではないけれど、近いうちに修正しなければ機能や表示として困ることが出てくるものに付けています。
Minorは軽微な誤字脱字や色指定の誤りなどの表示に関するものに付けています。

ライド時のフローや会員登録といったもので機能的不具合を見つけたら問答無用で「Critical」を紐付けます。

不具合起票

不具合起票の際は、エンジニアから修正時に必要な情報ヒアリングして作成したissueテンプレートを利用しています。

  • 発生したアプリのバージョン
  • 不具合発生の前提条件
  • 期待結果
  • 実施結果
  • 不具合の再現手順
  • 再現率
  • 発生環境(端末情報)
  • エビデンス

Bug Template

内容を埋めたら、ラベルとプロジェクトを紐づけて起票します。
※アサインやマイルストーンはエンジニアの方々にお任せしてます。

前職までエビデンスは画像で提供することが多かったです。Luupにジョインしてからは動画を添付してます。
プロダクトの性質上、連動した動きがおかしいという不具合が多いので、画像より動画の方が分かりやすいので「お!」と思った部分でした。
ジョインしたての時に画像でエビデンス添付してたらめちゃくちゃ時間がかかったのでチームメンバーの起票を参考にしたところ、動画でした。勉強になりました。
起票時の時間短縮という観点を抜きにしても、動画の方が分かりやすいなと自分は思っています。
※特定の画面でのUI不具合は画像の方が分かりやすいとかはありますが。

不具合の分析

次のバージョンのテストが始まる前に不具合をまとめてアプリ開発チームの定例で共有しています。

起票時の情報をベースにして、iOSやAndroidやServerでどのくらいCriticalの不具合があったのかを中心にまとめて共有しています。

quarter毎にも不具合の分析結果を共有しています。
ここではどのバージョンで不具合が多かったのか、その不具合はどこで発生していたのか、UI系が多いのかLogic系が多いのか、そういった情報を展開して次の開発に活かしてもらっています。

分析の課題としては、すべて起票時の情報ベースのため、紐付けがされていない情報での分析が行えない点です。
例えば、前バージョンから発生していたのか?などの情報がissueに載っていないと、その不具合が潜在的だったのかそうでないのかの切り分けが困難になります。
今後の分析や不具合修正のためにも、起票時のチケットの情報を充実させていきたいと考えています。

分析で何を目指すか

分析することで最終的に製品の品質をよくしたいです。
それはそうだ、という内容になってしまうのですが、分析することで「どこで」「どのくらいの」「どのような」という内容を深掘りできます。
その内容をエンジニアに共有することでプロダクトのどこに不具合を作りやすいのかが分かりやすくなります。
それを積み重ねることで手戻りの少ない、品質のいいプロダクトを目指していきたいです。

終わりに

今回は不具合の管理について記載しました。
LuupのQAチームとしてまだまだできること、やれることがあるはずです。
色々な可能性を模索してより良いものを皆さんにお届けできるように努めたいと思っています。

Luup Developers Blog

Discussion