2000年代よりスマホが普及されはじめ、モバイルとWebの様々なアプリケーションが作られることで人々の生活を楽にしてくれてます。それほどユーザー目線を優先する開発文化が大切にされ、開発とテスト工程ではより充実しているアプリを公開するために「品質向上」を第一の目標としています。
その中でQAは、バグを見つけ解決するために開発側との円滑なコミュニケーションをすることが大事です。ただチャットで「～機能が動きません」とか「～画面が仕様と異なりますが」のようなメッセージだけには非常に効率ではないしバグを管理することも難しいはずです。そいうことでこの度は、バグチケットの作成についてご説明させていただきます。
＜目標＞
- 不具合チケットの作成項目と内容が分かる
1. バグチケットの作成項目
① インシデント詳細
バグの内容を一つの文章にまとめるところです。簡単には下記のような文章の仕組みで作成することができます。一目でどのバグなのか分かるように作成することが大事です。
"【どの画面にて】【どの操作をした時】【どの事象が発生する】" という仕組みになります。
② 期待結果と実際結果
仕様通りであればどの動きが正しいのかについての期待結果と、実際にどんなバグが発生したのかについての実際結果を記入するところになります。
③ エビデンス（画像・動画）
テキストだけでバグの内容が分かりづらいこともあると思います。そのときはテスト端末やブラウザーのキャプチャー画像とか録画した動画といったエビデンスを添付することでチケットの内容の信頼度を高めることができます。
④ 仕様書URL
バグが発生した画面のUIとか詳細説明といった記載のある仕様書のURLを貼り付け、期待結果を再度確認します。または仕様を作成していた開発側にとっては、バグ内容に基づいて仕様に記載漏れがあると気づいた場合、仕様を更新するタイミングにもなるかもしれません。
⑤ 再現手順（前提条件・手順）
QA側でどの手順で操作したらこのバグが発生したのかについて作成します。特定な条件で発生することであれば前提条件を記入することが大事です。
⑥ 再現率
あるバグはいつも発生するわけではないでしょう。再現率が低かったら原因を早めに見つけることは難しくなり一層詳細にコードを確認する必要があるわけです。書き方としてはテストを5回実施して5回全部同じバグが発生したとしたら「5/5」あるいは「100%」と記入します。
⑦ 実施端末の情報（OS・バージョン）
テスト端末のスマホがiOSなのかAndroidなのか、バグ発生有無がOSによることもあります。OSバージョンの違いもそうです。そいうことで、どの機種のスマホでテストを実施したのかについての情報を記入します。
⑧ アプリの環境・バージョン
アプリが公開されるまで、開発進捗によって異なる環境のサーバーからリリースされ検証していきます。QA側だとしてもQA環境でテストを実施するわけではありません。Staging環境のみで実行できる機能があれば、開発側がリリースしてくれたStaging環境のアプリをインストールしテストを行うことになります。そういうことでどの環境でテストを実施したのか、このバージョンは何かを記入するところになります。
⑨ テスト項目の存在有無
ほとんどのバグはQA側がテスト項目に基づいてテストを実施しながら見つけることです。あるテストファイルのどの項目に該当されるケースなのかを記入することで、コードが修正されたらこのテスト項目をすぐ開き再確認することができるようにします。たびに該当テスト項目がなくて「無し」に記入することもありますが、これは設計にてテスト観点を決めたとき漏れてしまったテストケースであるかもしれないのと言えます。
2. 伝達力を1%上げる
① 実際結果には実際結果を記入しよう
当たり前の話だと思われるかもしれません。しかし、下の例のように期待結果から一文字だけを変え実際結果だと書くことがありますが、この文章はそんなに伝わらないと感じるかもしれません。
例）
- 期待結果：ログイン画面にて「ログイン」ボタンを押下すると、TOP画面に遷移すること
- 実際結果：ログイン画面にて「ログイン」ボタンを押下すると、TOP画面に遷移しない
実際結果には「実際にどんな事象があったのか」を記入することが読み手にとっては分かりやすいはずです。
例）
- 実際結果：ログイン画面にて「ログイン」ボタンを押下すると、TOP画面に遷移せずローディング画面が表示し続けてしまう。
② 表を活用しよう
バグの内容が簡単だったら文章だけでチケット作成を完了すればいいのですが、記入すべき要素がたくさんある場合は書き方を迷っちゃうことがあります。この時は、表にまとめるのがより分かりやすく伝わる方法の一つです。
3. チケット作成後のバグ管理
チケット作成が終わりましたら担当者を割り当てします。最終的には開発者になると思いますが、内容確認が必要だとしたらリーダーに割り当て、リーダーからのレビュアーが終わったら担当者を開発側のメンバーに再度変えてコードの修正をお願いすることになります。
開発者はバグチケットの内容に基づいてどのところのコードを修正しなければならないのか修正範囲を把握することができます。修正した後はまた担当者がQAに変わり、QA側から再確認を行います。あの機能が仕様通り動ければテスト結果をOKに記入することでテストを完了させます。
チケットの内容に補足が必要の場合、開発者は必要な情報を求めることになりますが、この手間をなくすのがコミュニケーションにおいて大事だと言えます。バグが発生する特殊条件など、読み手が求めている情報を記入することは伝達力を高められる方法だと思います。
こういうふうにQA側では開発エンジニアとコミュニケーションを通して様々なバグを解決し問題点を改善していくことでサービスを品質を高めていきます。