Claireさんは、Oracle社のQAエンジニアで、テスターの立場から現場改善を主導している方です。Report(事例紹介)ジャンルのセッションで、同じ現場改善の実践者として興味があったこと、「テストの見える化」がどういうものかに非常に興味があったことから参加しました。Bugs)を見つけたところだったので、非常にタイムリーだなとも感じての参加でした。彼女はかなり熱い実践者でした。■テスターとしての悩み:課題認識Claireさんのチームでは当初、バグが見つかった場合にどれを優先的に解決すべきか、チーム内でうまく合意をとれずに苦労したそうです。そのため、コミュニケーション方法の工夫が必要になるのですが、Claireさんは2種類の「見える化」によって実現しました。Designer、Developerで構成されるスクラムチームです。テスターであるClaireさんにとって、彼らはチームメイトであると同時に、テストユーザまたはステークホルダーと見ることもできます。プロダクト開発では、ステークホルダー分析を行ってニーズ・要望を把握します。Claireさんは、チームメンバーをテストのステークホルダーと捉え、チームメンバーのペルソナを作成することで、テスト・バグに対するニーズ・要望を見える化したそうです。ペルソナを作成した結果、チームメンバーが次のようなニーズ・要望を持っていることが分かりました。Designerバグがどの機能に多いか?バグを再現できるか?試せるか?見た目の要望を満たしているか?機能の正確性を満たしているか?Developer原因は何か?次に何をすればよいか?動作するか?この時点で、ステークホルダー毎にテスト・バグに対する要望・ニーズに差異があることが分かります。■見える化その2:ステークホルダーに応じたバグボードClaireさんは、ペルソナに続いてステークホルダー毎にバグボード(バグを書いた付箋を貼ったタスクボード)を作成しました。Done:完了の定義)を明確化することで、バグ解決をスムーズにしたのです。具体的には、次のようなバグボードを用意しました。Managerバグを重大性(Severity)の順に整理し、どのバグから解決すべきかを判断。Designerバグのサイトマップを作成し、どの機能のバグ群を重点的に解決すべきかを判断。Developerスプリントボードにバグタスクを組み入れ、どのタイミングでバグを解決するかを判断。スプリントボード上にバグのレーンを用意し、Timebox化して1つずつ解決していく。ストーリーにバグタスクを振り分け、1つずつ解決していく。バグボードを作り分けたことで、各ステークホルダー内外のコミュニケーションが増え、結果としてチーム全体のマインドがポジティブに変わってきたそうです。■現場の改善ストーリーにこそリアルがあるテストのステークホルダーのペルソナを作成する。バグ情報をペルソナ毎に再構成・提供することで、迅速な開発と修正を実現する。これらをテスター主導で実現。チームメンバーのペルソナを明確化し、それをもとにバグ情報の見せ方を工夫していくストーリー展開が、現場の課題解決を生き生きと伝えていて、非常に参考になりました。有名な方の理論ももちろん有効です。それ以上に現場での試行錯誤のレポートは、その学習過程が明確なことと、同じように試行錯誤している自分と重ね合わせやすいことから、より身になることが多いと感じました。■QAの新しいロールモデルもうひとつ私が注目したのは、一連のバグの見える化を通じて、Claireさんがチームメンバーをコーチングしながら、テストを円滑化していったという点です。Claireさん自身も、一連の活動を通じてチームメンバーをクロスファンクショナルなチームへ育てていったということを話していました。私がよく耳にするQAエンジニア像は、開発チームから「降りてきた」プロダクトのテストを「押し付けられる」というものです。開発チームと切り離され、どちらかというと無理を押し付けられて難儀しているQAエンジニアたち。Claireさんのやり方は、QAエンジニア側から開発チームに働きかけて、テストのしやすいプロダクトやチーム構成にしていくものです。これはスタート地点は違うものの、私が取り組んでいるアジャイルコーチの仕事と同じです。したアプローチは、QAエンジニアの新しいロールモデルとしてもよいのではないかなと思います。※注:レポート内のスライド画像は、Claireさんの許可を得て掲載しています。新しいレポートできました。さんのセッションのお話です。WowThemes.netFacebookTwitter。