プロダクト知識の理解を促進するテスト分析「辻レビュー」の話

こんにちは。freee人事労務でQAエンジニアをしている村岡です。社内ではkairiと呼ばれています。ニックネームは特に本名とは関係ありません。

この記事は freee QA Advent Calendar2023 の14日目です。

今回はQAメンバー内でテスト分析レビューをしてみたら想定していた以上の効果があったのでそのお話をさせていただきたいと思います。

前提

freeeでは1チーム数人の開発エンジニアに対して1人のQAエンジニアが入り、一つのプロダクトに複数のプロジェクトが並行して走っています。チーム内のQAエンジニアは単独で動くことが多く、それぞれのQAエンジニアにそれぞれ担当しているドメインの知識が属人的に身についている状態です。

そのため、チームが異動になった場合や、QAメンバーが急遽お休みしたタイミングで他のメンバーが引き継ぐのに苦労することがあります。

これを解消するためにチーム内で勉強会が開催されていたりするのですが、浅く広く勉強することはできても狭く深く勉強することは相当時間をかけないと難しく、概要は知っていても実際にテストすることはできないような状態が発生することもありました。

辻レビュー

freeeでは以前から「辻レビュー」という文化があります。発祥はよくわかっていないのですが、おそらく「辻斬り」から来ているものと思われます。

レビューといえば人によってレビュアーがある程度決まっていて、その人にレビュー依頼することが多いと思いますが、辻レビューの場合レビュアーが自主的に対象を見つけてレビューしに行きます。

この辻レビューを取り入れれば、上述した課題に対して何らか効果があるのではないかと考えました。

というわけで、以下画像は私が実際に辻レビューを依頼してみた現場になります。私のチームの場合辻レビューをする文化は当時なかったので、自分から斬られに行っています。不自然さは否めませんが気にしないでください。

初めての辻レビュー依頼「辻レビュー希望です。もしマインドマップ見れなかったらスレに書いてください資料一覧テスト分析マインドマップ」 — 初めての辻レビュー依頼

私はマインドマップでテスト分析する派なのでマインドマップツールへのリンクを貼っていますが、その辺は好みとプロジェクトの規模によると個人的には思っています。

Design Doc（仕様書）
Design（freeeだとfigmaを使用していますのでそのURL）
Test Design（テスト分析）

上記三種類のDesignをメンバーに共有しています。

期待以上の効果

斬られに行った側としては「なんか見逃してるテスト観点見つけてもらえるといいなー、今こんなテストしてることが伝わるといいなー」くらいの気持ちだったのですが、

ドメイン知識の共有になる（＝当初の目的）
ちょうど同じプロダクト内の関係している開発案件への連携に繋がる
自分のテスト観点が他の人のテスト観点の漏れ発見に繋がる
自分のテスト分析のいいところを他の人が真似できる
もちろん自分のテスト観点の漏れも見つけてもらえる
単純にわいわいできて楽しい

など、当初の思惑を超える効果がありました。ポイントとしては、レビューする側の時間が多少食われる以外のデメリットが思いつかないことです。それにしても本格的にキャッチアップしようと思ったらもっと時間がかかるはずですから、効率的な方ではないかと思います。この辺を踏まえて、何度か人事労務QAチーム内では辻レビューの依頼が発生しています。