MagicPodの自動テストをチーム全員で作成出来る状態にした話

はじめに

私たちのQAチームではMagicPodで作成した自動テストを運用しています。
これまで自動テスト導入にあたってはチーム内の一部のメンバーで推進してきましたが、最近はチームメンバー全員が自動テストの作成・保守ができる状態を目指しています。

今回はそのための施策のひとつでもある、「ぺアプロ風の進行でテストケースを作成している話」 を紹介します。
自動テストをチーム全員で作成・保守できる状態に近づくためのアイデアの一つ、ぐらいとして読んでいただけたら嬉しいです。

ペアプロとは

一般的にペアプログラミングとは、一台のPCを二人で利用してプログラミングする手法です。
「ドライバー」と「ナビゲーター」の役割に分担して、業務を担当します。

役割	やること
ドライバー	実際に手を動かしてコードを作成する人
ナビゲーター	コードを見ながらドライバーに指示する人

実施前のチーム内の事情

• 元々、導入からこれまで特定メンバーのみで作成・運用・保守まで対応していた
• 自動テストは手動テストの属人化を取り除いてくれたが、運用面の属人化は残っており以下問題が発生
  • 担当者以外、自動テストケースを作成できない（動作性・安定性・可読性・効率性・可変性まで考慮したもの）
  • 担当者以外、MagicPodでのテストケースを普段見慣れないため問題が発生した時にケースの見方が分からない
• テストケースのレビューが作業合間の対応となる。その中で、「3.レビュー実施」がボトルネックとなってしまい、完成までに日を跨ぐことも多々あり時間が掛かっていた
  • 1.テストケース作成
  • 2.レビュー依頼を投げる
  • 3.レビュー実施
  • 4.レビュー後の修正
  • 5.再レビュー実施

このように、自動テストは運用できているものの一部の人しか対応できない状態で、チーム全員で対応できる状態を目指すにあたり教育が必要でした。その時に後述するメリットもあると知り、ペアプロの仕組みを活用すると良さそうだと思い、今回取り入れてみました。

ぺアプロ進行で期待したこと

ペアプログラミングのメリットは各サイトにより様々挙げられていますが、今回は下記を特に期待していました。

1. 教育的効果
疑問を解決しやすくなるため、新人のスムーズな成長を期待できます。

2.レビュー時間の削減
完成するまでのプロセスや、実装や設計の問題をリアルタイムで指摘してもらえるため手戻りが減ります。

ぺアプロ風進行でやってみた

役割定義

まず、今回私たちは以下のような役割定義で作業を行いました。「コーディング」を「テストケース作成」に置き換えています。

役割	やること
ドライバー	実際に手を動かして テストケース を作成する人
ナビゲーター	テストケース を見ながらドライバーに指示する人

進行の流れ

前提： 三か月先までスケジュールを入れる

狙い
１.毎日少しづつでも前に進めるため （新しいチャレンジは後回しになる可能性が高い）
２.事前にスケジュールを入れておくことで、元々各自が持っているタスクの調整をスムーズに行うため

1. Zoomを繋いで、ドライバーが画面を共有する

「一台のPCを二人で利用する」というのが一般的な方法ですが、「同時に確認する」という状態はZoomの画面共有機能でも再現できます。また、書き込み機能を使えば、口頭だけでは何を指しているのか分かりにくい時に、操作して欲しい場所をペンで指定しながら指示することもできます。

2. ぺアプロ実行

時間	やること	補足
5分	作成したい項目やゴールを考える	計画表に基づいてどこまでを自動化するか両者間の認識をすり合わせます。
1分	役割を決める	ドライバーかナビゲータかどちらが行うか決定するための時間ですが、暫くの間は新人がドライバー固定で進めています。
60分	テストケース作成	理想的な進め方は以下です。１ー３を繰り返すイメージです。 1.ドライバーからテストケース構成の共有 2.テストケース実装 3.テストケース実行 3-1.修正がある場合は修正 3-2. 修正が無い場合は小さな振り返り
10分	振り返りとネクストアクションの決定	ここではドライバーから勉強になったことなどの「気づき」を発信してもらうようにしています。 また、自動テスト用のテストデータの整理なども行います。

ドライバーの心得

• 不明点は遠慮せずに質問しましょう。
• 必要に応じてドライバーも意見することで、プログラムの品質を高められる仕組みです。
  • 完全に受け身の役割ではなく、自分から情報を発信もしてみてください。

ナビゲーターの心得

• 作成するテストケースの内容をイメージしながら、適切なコマンド指定して作成を指示しましょう。
• 判断の理由を必ず 言語化 しましょう
  • どう考えてどう判断するのか、その思考プロセスは他メンバーにとって大きな学びになるため、メンバーの成長の助けとなります
• ぺアプロ中に出た観点を後からも見返したときに分かるように、レビュー用の判断基準のチェックシートも作りましょう
  • 仮にナビゲータが変わったとしても、基準が人によってブレるということも防げます

ぺアプロ風進行でやってみた結果

• これはプログラミングにも通じていると思いますが、テストケース作成を学ぶ最も良い方法は、実際に手を動かして作成の数を重ねることだと思います。
  ぺアプロはリアルタイムで不明点の解消やフィードバックがあり、作っていく過程でのナビゲータの思考回路も開示されます。そしてドライバーはどんどん手を動かして作っていきます。そのため、単に講習形式で教えるよりも 高い教育的効果 を感じました。

• また、「１テストケース作成」→「２レビュー依頼を投げる」→「３レビュー実施」→「４レビュー後の修正」→「５再レビュー実施」という流れが、ペアプロにすると２以降一気にその場で進行できるため、実施前に期待していた レビュー時間の削減 の効果も大きく感じられました。

ドライバー視点（教わる側）のメリット

振り返りの中ではドライバー側からこのような意見が上がりました。

• 会話を重ねて作っていくため、一緒に考えて作り上げているということを実感出来て、楽しく作ることができた
• リアルタイムでやりとりしているため、調べる時間や返答待ちの時間も削れるし、頭に入りやすかった
• 成果物を出す面でいえばナビゲータが一人で作成してしまった方が速いが、 育成やコミュニケーションの面を考えると効率が良いと感じた

ノンコーディングツールといえど、非エンジニアからすれば「変数の使い方が分からない」「そもそも変数とは？」「ロケータとは何か？」と言うところから始まります。そのため疑問点が多く出ますが、ぺアプロのようにマンツーマン形式だからこそ質問をしやすかったなどの意見が上がりました。

ナビゲータ視点（教える側）のメリット

今回ぺアプロの目的の大半が教育であったため、ナビゲータにとってはレビュー時間削減などの効率面での効果があるくらいと予想していました。
しかし、ナビゲーター自身「言語化して人に伝える」という形でアウトプットすることにより、 自分自身のスキルの定着と向上 も感じることができました。
また、シームレスなやりとりによって、メンバーがどこでつまずいているのか、どこが苦手そうか、などが伝わりやすいため人や状況に合わせた教育にするなどの調整もしやすかったです。

ナビゲータ視点でもぺアプロを取り入れてみて本当に良かったと思いました。

まとめ

上述したように、今回ぺアプロを取り入れたことによって高い教育的効果がありました。
例えば「レベル１：未経験者」「レベル２：テストケースが作れる」「レベル３：人に教えることができる」とした場合、レベル２まで、 初心者を一定水準まで一気に引き上げることができる と思います。

ただ、チームやメンバーのレベル感によってぺアプロの向き不向きはあると感じました。

レベル	適性
全員レベル１の場合	あまり向かない
レベル１とレベル２or３のペアが作れる場合	向いている ※今回のように、レベル１が一気にレベル２まで上がるイメージ
チーム全員がレベル２、３にいる場合	教育面で考えるとそこまでメリットはない ※スキルの相乗効果は期待できそう

今後の目標としては、ナビゲータ固定をやめ、レベル２になった人にもナビゲータをさせることでレベル３に引き上げることを目指しています。

最後に

ぺアプロは楽しんでやることが一番大事だとよく云われていますが、テストケース作成もぺアプロで進めることによって両役割とも楽しんで進めることができました。それは、秒で回っていく会話や質問などのやりとりの過程で 作りたいものが形になっていく体験が出来た ことが一番大きかったと思います。

ここまで読んでくださって、ありがとうございました。