実際にやってみてわかったモブでテスト設計してよかったことと課題
はじめに
これはウイングアーク Agile and DevOps Stories のAdvent Calendar 2019、第5弾（2019年12月6日）の投稿です！
テストチーム構成が変更になり「効率的に活動できるように」とか「チーム内の相互理解を促進したい」とか考えて実践してみたのでどんな感じか書きます。
実験と改善を繰り返して自分たちに合わせてみているといった段階ではありますが、うまくいきそうな予感があります。
テストチーム構成
- 品質リーダー: 一人
- テスト設計: 三人 → 二人
- テスト実施: 外部組織
変更の概要
今までの四人チームのやりかた
- QA担当者がテスト設計
- QA内テスト設計レビュー
三人チームになってから、変えてみたやり方
- QA担当者ともう一人でテスト設計
- QA内テスト設計レビュー
なお、一人は品質リーダーなので管理や調整業務の合間にレビューです。
二人でテスト設計に入る狙いは以下のようなものです。
- テスト設計の技術、ノウハウを伝えたい
- ドキュメントレビューのタイミングになってから仕様書とにらめっこしたくない（そして指摘修正ループするくらいなら最初っから盛り込む）
- 短時間で完成度の高い設計をしたい
具体的にどうやったか
- QA担当者はテスト対象の仕様について少し予習しておく
- 2時間の打ち合わせ枠を作る（この時間を以下で作成会と呼ぶ）
- 15分で概要把握（開発の設計レビューor仕様レビューの直後なのでそこそこ理解は早い）
- 20分でテスト大項目作成
共有ディスプレイに表示しつつExcelOnlineで同時に書き込む - 40分でパターンとチェックポイントを大まかに洗い出す
書いてる最中から「これもやったほうがいい」とか横から書き加える - 残り時間で完成度を高める（作りながら理解が深まっているはず）
はたしてうまくいったのか
作成会は2時間使って大まかな洗い出しまでができました。翌日にはテスト設計が大体できてテスト設計レビュー。三人中二人で作っているのでレビュー指摘は少なくなりました。
テスト実施は三人とは別チームが行なっていますが、目立った漏れは指摘されていないです。
- スピード: ドキュメントレビューにかける時間は減ったと思う
- 完成度: お互いに指摘し合いながら作る分、レビューでの手戻りは少なくなった
- 理解度: 今回の実験ではQA担当者が自分なので主観的にはなってしまうが、後で自分で作っている分ドキュメントレビューするよりは理解しているのではないだろうか。
少人数、少ない時間でメンバー間で技術・ノウハウを伝えられ、かつ、設計レベルを平準化、の効果が得られました。
うまくいかなかった例
テスト対象が複雑で開発設計レビューが複数回にわたる（しかもまだ終わってない）ケースに対して作成会を実施したときに以下のような状態になりました。
- 概要把握が仕様思い出し会になる
- あれこれ確認しつつそのまま2時間経過
これはなんか違うぞ…
もっとうまくやる方法はこれからブラッシュアップするとして、この件に関しては、もう一度作成会を実施して進めています。一度思い出し会をやっているので次は割とスムーズに進み、ちゃんと作成会できました。
結果として思い出し会も「あれここ違うんじゃ」とか「これはここに書いてあるからこうだ」とか指摘しあうことで効果はありました。（テスト設計書レビューするときに一人で思い出してたら頭抱えそう）
スピードアップという点ではうまく行ってない気がしますが、相互理解の点では役立ったのではないでしょうか。
まとめ
効率化と学習効率アップのためモブドキュメント作成を試し、少人数チームにおいて期待した効果はあった
- 相互での理解度は向上
- 技術やノウハウは伝えられた
（ちょっとしたことだったり心がけみたいなものも含み、そういうのは教えるというより伝わるものだけれど、モブワークでは感じてもらうことができる） - うまくできたケースではスピードアップ
みえている課題
- 作成会をスムーズに進めるための各メンバーが押さえておくべき最低限の仕様理解のレベルの度合をどうするか
→ ここは回を重ねて具合をつかんでいくのがよさそうです - 最低限のレベルに至るまでにできることはないか
→ 仕様理解に時間がかかるのはソロ&全体レビューでも同じだけど、モブドキュメント作成なら浅い理解度から始めても作成会で理解を深めつつ作業ができるはず
