こんにちは。株式会社8bitの高本です。
最近リリースしたサービスの品質強化と改善を行っているのですが、テストをする人と直す人の間のコミュニケーションは、結構難しいと再認識しました。
開発者は無意識に正常ルートをたどってしまうので、開発者のテストは正直あてにはならないことが多いです。
出来るだけ、開発していない方がテストをやることが良いと思いますが、思いもよらないバグの発生をどうやって伝えたら分からない、うまく伝わらないということがあります。
正確に情報が伝わらないと開発者もテストしている人もイライラしてなかなか思うとおりに品質向上へ繋がりません。
そこで、最近テストをしてもらっていて、開発者の目線からテストをしてもらってどういう情報が欲しいというポイントをまとめてみました。
Webサービスを作っているチームにテスターという明確な位置づけの方がいらっしゃらない場合が多いです。Webディレクターの方がテストをすることも多いかと思います。
ということでタイトルに「Webディレクター」と入れてみました。
開発者の方やサービスの内容によってはもっと欲しい情報があるのかもしれませんが、個人的に思ったことです。
開発者とバグのやり取りでうまいこといかないときの参考になればと思います。
1. 再現データ
添付ファイルや入力項目へ入力した文字列など何を入力やアップロードしたのか、正確なデータを報告します。もし、忘れてしまった場合でももう一度思い出しながら同じバグを再現させてなるべく、正確にデータを記録しておいて欲しいです。
2. エラーが発生した画面の前とその前の画面
エラーが発生した画面もそうですが、直前の画面の情報(URLなど)が欲しいです。
結局エラーは直前の動作が原因で起きるわけで、どの画面で操作をしたのか、操作したその前に何か登録したのか？などの詳しい情報が欲しいわけです。
3. どのボタンやリンクを押したのか？
どのボタンやリンクをクリックしてエラーが発生したのか？
複数のボタンやリンクがある場合は一応報告してもらえると助かります。
もし、クリックしていない場合もそのことを書いて欲しいですね。たまにEnterキーを押して、全然別のボタンにフォーカスが当たっていたりすることや、Enterキー押下に対応していないこともあったりするので。。
4. 使用ブラウザとそのバージョンやOS情報
ブラウザのバージョンは確実に欲しいです。
ブラウザによって仕様は異なりますので、ブラウザにログイン情報を保存するようなサービスの場合、ログイン周りで発生したバグはブラウザのバージョンや種類によることもありますので。
携帯やスマホの場合はその機種情報なども欲しいですね。
6. 直前の画面やエラーが発生した時の画面のURLも
2で画面の情報を挙げていますが、URL自体の情報も欲しいです。
URLにはその画面で処理をするために利用する情報が含まれていることもあるので、実際に変なデータが入ってきていたのではないか？などバグの原因調査に大きくかかわる情報が含まれていたりしますいので。。
「再現しないから修正できない！」と投げやりな感じになってしまう場面をみかけますが、テストをする人もそんなことで怒られても困ってしまうと思います。
2～3回やってみてあきらめないで根気強くやることが重要だと思います。
——–
後は、伝え方によるところもあると思いますので、なるべく分かりやすく、本当は共通の言葉で通じるようテストをする人もある程度専門用語に精通しておいたほうが良いと思います。
当社で運用しているWebサービスの品質管理サービス「COLORBOX」でも日々のテストでうまいことコミュニケーションとるにはどうサービスを改善すべきか考えています。
