113.テスターの一日 その④
バグ登録時のフロー
バグを登録するときの流れは組織によってまちまちだと思います。
ここで紹介するのはきゅんちゃんたちのチームはということで。
テストリーダーに全部の情報が集まる形です。
不正（アノマリー/期待と異なる結果）があった場合はチャットでリーダーに報告します。
口頭で済ましてしまうと他のメンバーに情報が伝わらなかったりします。
そうなると重複した報告が出てきてしまいます。
そしてリーダー側で、情報が不足してないかの確認（他の端末は見た？など）や、報告された情報が重複されてないかや、勘違い（偽陽性）などではないかの判断を行います。
で、わかった情報からバグ修正の優先度をつけて登録指示です。
メンバーはバグを登録したら、テストケースにバグ票のURLを紐づけて、登録報告です。
新人さんの場合は、登録完了の報告後にリーダーがバグ票のチェックを行ったりします。
まとめるとこんな感じです。
- チャットでバグ報告
- リーダー側でフィルタリング（重複、アノマリー、情報不足の確認）、優先度付け
- バグ登録
- バグ登録後報告＆テストケースとのトレーサビリティ確立（紐づけ）
- （リーダー側でバグ票確認）
このやり方は作者が昔テスト部隊をやっていたときの流れです。
（今はコンサル的な感じでテスト実行全然してない……）
テスト期間は通常3～4日だったのでガンガン進めなければいけないわけで。
どこかにいったんまとめて後から……と悠長なことをしてると、数時間の対処/判断の遅れが致命傷になったりしていました。
で。
リーダーにその場その場で情報が集まると、どんなバグが登録されているか、どの辺がバグが多いかといったことがリアルタイムでわかって助かるわけです。
バグの重複登録のフィルタリングも楽だし、次にとるべき戦略もスグに考えられるので……ということでやっていました。
ただこれがテスト実行者が10人単位になってくると、チャットが神速で流れていくようになってテスト実行者の方が履歴を追えなくなります。
（ふりかえりで大体「チャットが追えない」ってProblemがでる）
そうなってくると、スプレッドシートに報告を書いてもらい、書いてるそばから作者がガンガンとレスをしていく、という形でやっていました。
書いている途中の内容見ちゃって、書き終わる前に返答書くのは失礼だよな…とか思いながら書き終わるのを待っていた思い出がありますｗ
たぶん作者はマックスでテスト実行者26名ほどでゲームのテスト進行をしていました。
その時はあれこれ追いつかず「わからない人は手を上げてー」ってやったら、もう完全に居酒屋のホール担当みたいになっちゃったことがありました。
優先度基準
バグに付ける優先度は基本的には「バグを修正してほしい優先度」です。
優先度が高いモノから直してほしい、といったところです。
またテストの終了基準にバグの優先度が出てくる組織もありますね。
「優先度高以上の不具合が全て修正されていること」などなど。
優先度については、開発メンバーとも話し合い合意をとっておかないとテスト側の独りよがりの記号になってしまうので注意です。
あと優先度、決めはじめるとガッチガチに決めたくなるものですが、作者の経験としてはそこまでガッチリ決める必要がないのなら、ある程度枠がわかってあとフンワリ程度が動きやすい感はありました。
ガッチガチだと「このバグは優先度は何に当たるだろう…」と毎度毎度調べるのに時間を使ったり、最終的には判例主義みたいに事例羅列になったりしたり。
マンガに描いたような例を書いておきます。
作者が前に使ってた基準とアトラシアンが大体同じでした。
アトラシアンだけ見たい方は以下をご参照ください。
アトラシアン クラウド バグ修正ポリシー | アトラシアン サポート | アトラシアン製品ドキュメント
最高（Blocker）
機能がまるっと使えない。そのアプリを使うユーザーが業務実行（その機能を使って実現したいこと）ができず回避策もない。テスト進捗も止まる。
高（Critical）
最高と同様で１つの機能が使用できないが、回避手段はある。または個人情報が洩れる（人のページが見れちゃう等）といったセキュリティ問題、パフォーマンスの大幅な低下
中（Major）
仕様に明記された通りになっていない。期待通りに動作しない状態。ユーザーエクスペリエンスが損なわれるものの、やりたいことの実行は可能。CSSが当たってないなどの大きなUIの崩れ。
低（Minor）
主にUIの問題。クリティカルではない機能が期待どおりの動きをしていないなど小規模な問題。
最低（Trivial）
テスト後半などに、なんとしてでもバグを出そうと絞り出したような、重箱の隅をつつくような問題（jやgの下の部分が1ピクセル削れているように見えます！など）
この場合、中と低で迷うバグが結構出ると思いますが、その辺厳密にしていくとつらいことになるかと思います。本当にそこまで厳密にわけたいか考えましょう。
リーダーが判定する場合は、そのブレ幅は小さくなります。
アプリがクラッシュしたとき
クラッシュログをお願いしまーす！
ログで何が起きたか調べられるのです。
結構面倒くさがる人、聞かなきゃわからないから恥ずかしがって聞かない人がいるのですが、ログ大事！ってことを覚えておいてもらえると嬉しいです！
ログ大事！
青葉さん
なんかいっつも「ダメですっ！」って言ってるイメージ。
たぶん今回絵を描くときに一生分の青葉さんを検索したと思う。
描いている様子の動画！
今回の動画では「マンガのセリフ」について説明しています。
