4か月ペアテストをやって思ったこと
どうも「なそ」です！
みんなアウトプットしてますか？
どうも最近の忙しさから勉強会になかなか参加できなくてアウトプットできていない気がする今日この頃です。
さて、今回のお題は「ペアテスト」についてです。
ペアテストについては何度かテストラジオでも話をしています。
なぜペアテストの話題を取り上げるかというと、4か月にわたって実施してきてた案件が8月末で終了しました。
BPPセッション 良いチームを作ろう from 佐藤 博之
ついでにWACATEでチームの話をしたので、その時のスライドです。いい機会なので棚卸を含めてここで実験結果報告を行うと思います。
1．きっかけ
ペアテストとの出会いは、4月に開催された「Agile Japan」で、和田さんから「アジャイル魂2015」をいただいたことがきっかけです。
和田さん本当にありがとうございます！！
その中で、ペアプログラミングについて書かれている記事を読みこれはテストにも応用できるのではと現在のプロジェクトで実施してみました！
アジャイルの魂 2015より抜粋
誤解されているのは、作業内容に関することです。プログラミングとは設計・コード作成・テストを全て含む創造的な作業を示しますが、詳細設計工程とテスト工程の間にある「PG工程」を2人で作業すると誤解している人が多く、ペアプロの理解を大きく阻害していると感じています。
創造的な作業ということはテスト設計にも当てはまる。ただし、テストエンジニアには「ペアプログラミング」は用語的に合わないので「ペアテスト」と置き換えてプロジェクトメンバーには説明しました。
また、プロジェクトのアサインの状況的にも実践しやすい環境が整っていました。1チームに2名のテスターずつ、3チームありました。私が参画した時点でペアが出来上がっていた。かつ、アジャイル開発を行っていたので、スプリントの開始時にはテスト実行できるものがない！！そのため、実行者にも教育を兼ねてテスト設計をしてもらうことになっていました。
どうせやるなら効率的にやりたい！！
ということで、メンバーと一緒にいろいろやってみることにしました。しかし、業務で成果をあげないといけないため、下記の制約をつけました。
制約①：ペアにしたのは、下記のスキルを持っている人達です。
- テスト設計をしたことがない（普段の業務はテスト実行がメイン）
- テスト設計・テスト実行はお手の物
制約②：ペアを組み替えたいけど、変えたことによる作業効率低下が怖いため、組み替えはあまり実施していない。（あまりということなので、0ではないです。組み替えは何度か発生しています）
制約③：ドライバー、オペレーターの交代は難しいため、各々のタスクを交互にレビューすることで役割を補う。
2．ペアテストの狙い
私はペアテストで狙いは
- テスト設計者はテスト実行者に説明することで、自身の設計スキルを見直す。
- テスト実行者はテスト設計者が何を考えて設計をしているか勘所を感じる
- お互いにコミュニケーションを取ることで仕事の進め方をブラシュアップ
でした。
チームメンバーにはこの意図を伝えた上で実践し、一人のテスト設計者に全てを任せる訳ではなく、チーム全体で解決していきました。
片方のペアが忙しいときは私が変わりに対応したり、別の人にお願いしたりと臨機応変に対応していきました。
ただ、手放しに良かったといえるかというといくつかの改善点ややらなきゃいけないことなどはありました。(業務をやりながらのチャレンジだったため、問題解決のための時間はあまり多くなかったです）
簡単ですが、振り返ってみます。
3．良かった点
- テスト実行者の設計力が上がった！
- テスト分析、テスト設計のフェーズを明確にしたことで手戻りが工数が減った
- 勉強会を企画して、違う人とペアを組んでもらってテスト設計をした
実行者の設計力は目を見張るものでした。参画当初は右も左もわからない。テスト設計ってどうすればいいんですか？という質問しかできなかったが、見様見真似でもテスト分析やテスト設計を作ってくるようになった。もちろん、知見が足りないのは重々に承知していることなので、そこはレビューや声かけのタイミングで補うようにしました。簡単な機能であれば、テストケースを独力で作成できるようになりました。
また、工夫した点としては、テスト分析とテスト設計のフェーズを分けたことです。基本的にテスト設計者は慌ただしく、声をかけづらい雰囲気だったこともあり実行者が気を使って(本来その気遣いは逆効果だけど、こちらもキャッチアップできる雰囲気を出せなかったのはあるのでお互いの反省点)テスト分析のレビュー完了前にテスト設計に入ることが何度かありました。そのせいで、テストケースに漏れや大きな手戻りがありました。
最後の勉強会はなかなか時間を作れなかったので、数回しか実施できていなかったですが、いつもと違う人と組んでもらいテスト設計の演習問題をやってもらいました。また、プログラムの挙動について、ゆもつよメソッドの「論理的機能構造」を使って説明をしたりといろいろな情報をメンバーに共有していきました。
4．改善点
- 実行者のフォローに時間がかかり、設計者の作業に遅延が発生することがあった。
- 実行者から設計者へのアクションが見えづらくOJTに近くなっていた
- レビューチェックリストやテスト観点を用意しておく
- 勉強会の課題のボリュームが大きすぎた
フォローをするための時間は確かに必要です。しかし、それが大きくなってしまうと相手の負担になってしまい、それが明らかになってくると自分が負担になっているのではないかと思い始めることになります。この辺のフォローは難しいですね。
実行者から設計者や私への要望は少なく、話を聞いてみるとテスト設計にいっぱいいっぱいになってしまってそれ以上のことを考えられないとのことでした。この辺は改善しなくちゃいけないですね。自分がどれだけレベルアップしているのかが見えないためにどうなっているかの変化を捉えられないってことですもんね。
あらかじめ、こういうところに気をつけてなどの観点を用意しておいてあげれば第一歩としてわかりやすかったのかな・・・
また、勉強会の課題の規模が大き過ぎてみんなダレてしまう結果になったのは残念でした。せいぜい2時間くらいのボリュームを考えておかないといけませんね。
5．次やるときに
当初の狙いである2番目は十分に達成できた。
しかし、1番目が不十分で、設計者の教育も必要なのが分かった。
例えば、現場では以下のようなことがチラホラありました。
- 1時間近く説明をしているが、伝わっていない
- 途中で説明をあきらめてキーボードを奪う
- 設計者が忙しくて、レビューがリアルタイムにできない
- レベルアップのチャンス
要点を絞った説明ができない、相手に考えさせる、タスク整理や時間の使い方がうまくできていない等の設計スキル以外の部分がネックになることが多かったです。開発者に求められるのは幅広い知識や経験が必要ですが、土台にはこういったスキルが必要になることが改めて実感しました。
相手のわからないことを組み取ったうえで、説明しようとするわがメンバーの理解力には尊敬します。私は全部を説明せずに、少しだけ説明して後はやってみな！ただし、わからなかったらすぐに質問すること！を徹底していたので、そんなに時間を使っていないかったです。
なんだかんだで、どれだけ説明したとしても本人にやる気がない場合はどうしようもないのだなというのを強く感じました。自分のやったことのない範囲をやるわけなのでいろんな感情を持つと思います。飛び込んで欲しくても飛び込めない場合は残念な結果になります。もっと飛び込んでも大丈夫という空気を作ってあげれなかったのは大きな反省点でした。
6．次なるペアテストの現場を求めて
現状テストエンジニアが不足してます。では、どうやって仲間を増やかのかを考えた時、一つの教育の形としてペアテストがあると思います。今後も続けて行きたいと思います！
テストエンジニアが増えてきた時にはモブテストとかもやってみたいです♪
それでは、今回はペアテストの結果レポートをお届けしました！
