はじめに
この記事は、モブプログラミングアドベントカレンダーの24日目の記事です。
前日も私がモブプログラミングをやっている人にレビューについて語ってもらった話 #JaSSTReviewというタイトルで書きました。
今回は、WACATEというイベントでのモブプログラミングの体験談と、モブプロ実施時の私の思考をお伝えします。
同じ題材、同じ時の開発者目線の思考は、かりあどさんが既に記事にしています。
目次
- はじめに
- 目次
- 前段1：WACATEとは
- 前段2：テストエンジニアがモブプロをやってみると…
- モブプロ体験会@WACATE を開催
- テストシナリオが出来上がっていく過程
- モブプログラミング体験会延長戦：テストエンジニアはどの部分が気になり、どのように指摘するのか
- テストエンジニアは指摘事項を言い切るべきか
- 話す内容に強弱をつける
- おわりに
- おまけ
- おまけ（その2）
前段1：WACATEとは
公式ページはこちらです。
公式ページによるとWACATEとは、
Workshop for Accelerating CApable Testing Engineers：内に秘めた可能性を持つテストエンジニアたちを加速させるためのワークショップ
だそうです。*1
今回のWACATEで学んだものについては、別記事を書いているので、そちらを参考にしてください。
前段2：テストエンジニアがモブプロをやってみると…
私は以前にも、ペアプロ・モブプロを様々なところで試しています。
また、実際の業務でも試していますが、それはまた別の機会にブログに書きます。
モブプロ体験会@WACATE を開催
WACATEでは「夜の分科会」という、WACATE参加者の一部が自由にテーマを持ち寄って、他のWACATE参加者が興味のあるテーマに参加するというセッションがあります。
そこで今回私は、以下のようなモブプログラミング体験会を開催しました。
- お題…自動販売機
- 使用した言語など…CucumberとJavaを使ってATDDで作成*2
- 役割…
- 私…PO兼モブプロ・TDDの講師役
- WACATE参加者…モブプロのドライバーもしくはナビゲーター
- 人数構成…今回の参加者の内訳は以下です。
- 普段の業務でも開発者でTDD経験済…1名
- 普段の業務でも開発者だがTDD未経験…1名
- 普段の業務ではテストエンジニアでTDDも未経験…8名
テストシナリオが出来上がっていく過程
分科会の中で出来上がったテストシナリオを、その過程を含めて紹介します。なお、実装コードは今回記載しません。
シナリオその1：100円の入金を確認する
まず、私は雛形として以下のシナリオを用意しました。
Scenario: 入金額確認 Given 自動販売機がある When 100円を入金 Then 100円が入金されている
このシナリオが動くように、実際にテストコードを書き、実装コードを書きました。
シナリオその2：入金が2つあっても対応できるようにする。
PO（私）は、次のように伝えました。
「お金を100円入れた後に、50円を入れたら、ちゃんと150円になるようにしてほしいな」
その結果、テストシナリオは以下のようになりました。
Scenario: 入金額確認 Given 自動販売機がある When 100円を入金 Then 100円が入金されている Scenario: 入金額確認 Given 自動販売機がある When 100円を入金 And 50円を入金 Then 150円が入金されている
最初にあったテストシナリオをコピペして、「And 50円を入金」を追加しただけです。POの話を忠実に再現してくれていますね。
その後、このテストシナリオが通るように実装コードを修正しました。コードのリファクタリングも数箇所行いました。
シナリオその3：使いたくないお金はカウントしないようにする
続いて、PO（私）は次のように伝えました。
「1円硬貨は対応したくないです。」*3
その結果、テストシナリオは以下のようになりました。
Scenario: 入金額確認 Given 自動販売機がある When 100円を入金 Then 100円が入金されている Scenario: 入金額確認 Given 自動販売機がある When 100円を入金 And 50円を入金 Then 150円が入金されている Scenario: 入金額確認 Given 自動販売機がある When 1円を入金 Then 0円が入金されている
最初にあったテストシナリオをさらにコピペして、1円を入金した場合に「入金状態が0円になっている＝1円には対応しない」という状態を追加しただけです。
その後、このテストシナリオが通るように実装コードを修正しました。コードのリファクタリングもさらに数箇所行いました。
ここまでで、モブプログラミング体験会の時間（30分間）が無くなってしまったので、終了にしました。
モブプログラミング体験会延長戦：テストエンジニアはどの部分が気になり、どのように指摘するのか
モブプログラミング体験会は、上述のように終了となりましたが、その後に延長戦を行いました。
そこでは、テストエンジニアの思考と発言が話題になりました。
テストエンジニアは指摘事項を言い切るべきか
延長戦では以下のような話が出てきました。
開発者はテストのことが分かってない部分が多いので、テストエンジニアにはもっと言い切りの形で言ってほしい
私は上記の話には半分賛成、半分反対です。
確かに、テストエンジニアはテストの知見が多いので、その頼りに応えるために発言するのは重要です。その一方で、コードを書く主体は開発者だとも思っています。なので、提案はしつつも開発者に最終的な判断を任せることが多いです。
話す内容に強弱をつける
昨日のJaSST Reviewの記事でも、以下のように書いたのですが、モブプロやレビュー時に私からは「指摘」ということはあまりせず、「質問による深掘り」を多く行います。
そもそも「指摘する」ということはあまりなく、質問をすることで深掘りしていくことが多い
モブプログラミングをやっている人（及部さん）にレビューを語ってもらった話 #JaSSTReview - ブロッコリーのブログ
その時に重要視しているのは、優先度をつけて言う・言わないではなく、発言時に強弱をつけて伝えるようにしています。*4
例えば、今回の題材となるテストシナリオ（以下）では、次のような会話をしました。*5
題材
Scenario: 入金額確認 Given 自動販売機がある When 100円を入金 Then 100円が入金されている Scenario: 入金額確認 Given 自動販売機がある When 100円を入金 And 50円を入金 Then 150円が入金されている Scenario: 入金額確認 Given 自動販売機がある When 1円を入金 Then 0円が入金されている
会話内容
- 私「このシナリオって、すべてシナリオ名が『入金額確認』になってますよね。同じ名前はどうかと思うので変えたほうが良い気がしてます。（★1）」
- 開発者「なるほど。そしたらこんな感じですかね。（テストシナリオを編集する）」
Scenario: 1回のコイン投入 Given 自動販売機がある When 100円を入金 Then 100円が入金されている Scenario: 2回のコイン投入 Given 自動販売機がある When 100円を入金 And 50円を入金 Then 150円が入金されている Scenario: 使いたくないコイン投入 Given 自動販売機がある When 1円を入金 Then 0円が入金されている
- 私「なるほど。ちなみに、2つ目のテストの意図ってなんですかね？（★2）」
- 開発者「これは、コインを1回だけではなく、2回投入した時にもちゃんと動くか確認したいという意図です。」
- 私「なるほどー。そしたら、『2回のコイン投入』と書いていますが、3回目はどうなるのでしょうか？（★3）」
- 開発者「3回目は2回目と同じく、加算されていく仕組みなので、ロジック上は大丈夫です。」
- 私「ということは、気にしているのは2回のコイン投入ではなく、複数回のコイン投入なんですね。（テストシナリオを編集する）」
Scenario: 1回のコイン投入 Given 自動販売機がある When 100円を入金 Then 100円が入金されている Scenario: 複数回のコイン投入 Given 自動販売機がある When 100円を入金 And 50円を入金 Then 150円が入金されている Scenario: 使いたくないコイン投入 Given 自動販売機がある When 1円を入金 Then 0円が入金されている
会話における発言の意図
…いかがでしたでしょうか。
この会話は、★1、★2、★3で私の発言の強弱が変わっています。
★1「同じ名前はどうかと思うので変えたほうが良い」
この発言は、完全に指摘に近い提案になっています。これは誰が見ても直したほうが良いと思うからです。
★2「2つ目のテストの意図ってなんですかね？」
この発言は、開発者に思考を委ねています。
これは、自分が考えているテストの意図とは違った場合に私の提案は見当違いになることが多く、その時点で提案しても意味がないと判断しているからです。
あくまでも開発者自身にテストの意図を考えてもらうことが大切です。
★3「『2回のコイン投入』と書いていますが、3回目はどうなるのでしょうか？」
この発言は、私の考え「2回目も3回目も同じ仕組みなのでは？」も含んだ上での質問になっています。
「コインを1回だけではなく、2回投入した時にもちゃんと動くか」という開発者が発言したテストの意図は、以下の2通りのテストの意図に分けられます。
- コイン投入が1回だけでない（複数回投入した）場合
- コイン投入を2回（特定の回数）の場合
そして、私は「コイン投入が1回だけでない（複数回投入した）場合」というテストの意図の方が、今回のテストシナリオで考えているものだと感じました。
なので、確認の意味も含めて「『2回のコイン投入』と書いていますが、3回目はどうなるのでしょうか？」という発言をしました。
最終的に、テストシナリオ名をより良いものにできたと実感しています。
おわりに
今回は、モブプロ・ペアプロを行う時に、テストエンジニアである私はどのように考えているかという話をしました。
冒頭に紹介したかりあどさんの記事にも以下のように書いている通り、テストエンジニアはもっと開発コードに近い形で入ることも重要かと感じています。
そうした中で同じチームにテストエンジニアに入ってもらい、一緒に働くことで早い段階からテストエンジニアの観点を持って開発することができます。
テストエンジニアの観点を持ってテスト書いていくぞな話 - かりあどぷらねっと
今回はその一端を見せることができた気がしました。
おまけ
今回は開発コードに対してどのようにテストエンジニアが入り、協業して開発するかという話でした。
一方で、テスト設計、テスト実行に対して開発者が入る方法として、モブテストがあります。
それについては、ちょうど昨日、マンガも踏まえて紹介している記事がアップされたので、リンクを紹介しておきます。
おまけ（その2）
2019年3月14日に本記事をもとにした発表を行いました！
