underscore42rina.hatenablog.com
2週連続ですが、今週のテストランチでもモブテストをやってみました。
（モブテストってなぁに？て方は、前回のエントリーを見てくださいね）
今回の参加者
前回より増えて12名くらい？ 今回はテスト対象を作っているエンジニアや
ディレクターも参加してくださいました：）やったね！
テスト対象
先週とは別の自社で作っているサービスの1画面をテスト対象としました
やってみたふりかえり
成果
Issueが7件（うち、バグが2件とか？）でした。やっぱり効果はあるようです
よかったこと
1回目のふりかえりで「2回目はさらにテスト対象を絞ろう。画面ではなく1項目についてテストしよう」という案が出て採用しました。
テストスコープを狭くすることで、4分をぐっとバグを出すことに注力できたんじゃないかと思います。
また、最近自社に入ってきた非エンジニア（でもエンジニア出身かな）の方も参加くださったのですが
終わったあとに前職の心配をしてしまう程度にテストに対する意識を肌で感じていただけたっぽいです。よかった♡
うまくいかなかったこと / カイゼンしたいところ
- テスト対象が基本的なことだったこともあり、新しい知見が前回ほどなかったかもしれない
人にはよるけど、既知の内容が前回より多かったような気がしました。
それでも、非エンジニアのメンバーには復習になってよかったかもしれません。
- ナビゲーターが多すぎた
さすがに11人は多すぎました。最低でも2グループにわけた方がよさそうです。
- テスト対象、やりたいテストの内容によってはもっと少なくてよいのでは？
参加くださったディレクターからの提案？ですが、今回のテストの内容であれば3人くらいで十分では？という話になりました。
たしかに4分という時間で効率よくであれば、そのくらいでよいかもしれません。
ただし、もっとドメイン知識がいりそうなテスト対象であったり、シナリオテストのような内容であれば人数が多くてもいいかもね
という話になりました。
- やっぱりふりかえり6分は短い
2回目のテストまでに改善する内容を6分でするのは無理があるかなぁと思いました。
それでも上で書いたような案がでて採用できたのはすばらしいと思います！
テストランチという短い時間なので、6分ですることをカイゼンではなく、次のテスト対象（スコープが狭い場合）を決めることに注力したり、
テスト中の説明とかにしてしまうとかの方が消化不良にならなくていいのかも？
次回のテストランチは
モブテストについては、一旦テストランチでのチャレンジは終わりです（すぐやるかもしれないけど）
各プロダクトの開発で入れてみてもいいかもなぁと思います。
次回はこのモブテストが終わってIssueを実際起こすまでに私が考えていることを 共有できるといいなと思っています（それ社内共有ツールに書けばいいじゃん。とも思う）
