テストエンジニアはどのような思考でペアプロ・モブプロに参加しているのか #WACATE

はじめに

この記事は、モブプログラミングアドベントカレンダーの24日目の記事です。

前日も私がモブプログラミングをやっている人にレビューについて語ってもらった話 #JaSSTReviewというタイトルで書きました。

今回は、WACATEというイベントでのモブプログラミングの体験談と、モブプロ実施時の私の思考をお伝えします。

同じ題材、同じ時の開発者目線の思考は、かりあどさんが既に記事にしています。

kariaduu.hatenablog.com

目次

前段1:WACATEとは

公式ページはこちらです。

wacate.jp

公式ページによるとWACATEとは、

Workshop for Accelerating CApable Testing Engineers:内に秘めた可能性を持つテストエンジニアたちを加速させるためのワークショップ

だそうです。*1

今回のWACATEで学んだものについては、別記事を書いているので、そちらを参考にしてください。

nihonbuson.hatenadiary.jp

前段2:テストエンジニアがモブプロをやってみると…

私は以前にも、ペアプロ・モブプロを様々なところで試しています。

nihonbuson.hatenadiary.jp

nihonbuson.hatenadiary.jp

また、実際の業務でも試していますが、それはまた別の機会にブログに書きます。

モブプロ体験会@WACATE を開催

WACATEでは「夜の分科会」という、WACATE参加者の一部が自由にテーマを持ち寄って、他のWACATE参加者が興味のあるテーマに参加するというセッションがあります。

そこで今回私は、以下のようなモブプログラミング体験会を開催しました。

f:id:nihonbuson:20181223182907j:plain
モブプログラミング体験会風景(参加者のツイートより

  • お題…自動販売
  • 使用した言語など…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回目はどうなるのでしょうか?」という発言をしました。

最終的に、テストシナリオ名をより良いものにできたと実感しています。

おわりに

今回は、モブプロ・ペアプロを行う時に、テストエンジニアである私はどのように考えているかという話をしました。

冒頭に紹介したかりあどさんの記事にも以下のように書いている通り、テストエンジニアはもっと開発コードに近い形で入ることも重要かと感じています。

そうした中で同じチームにテストエンジニアに入ってもらい、一緒に働くことで早い段階からテストエンジニアの観点を持って開発することができます。

テストエンジニアの観点を持ってテスト書いていくぞな話 - かりあどぷらねっと

今回はその一端を見せることができた気がしました。

おまけ

今回は開発コードに対してどのようにテストエンジニアが入り、協業して開発するかという話でした。

一方で、テスト設計、テスト実行に対して開発者が入る方法として、モブテストがあります。

それについては、ちょうど昨日、マンガも踏まえて紹介している記事がアップされたので、リンクを紹介しておきます。

testerchan.hatenadiary.com

*1:私は未だに覚えられません

*2:なぜCucumberを選んだかというと、シナリオの部分がプログラミングに慣れていないテストエンジニアにも抵抗が少なく入れるのではないか?という予測と、最近自分がやっていて楽しかったことが理由です。

*3:なにげに、シナリオその2でのPOの言葉よりも曖昧な表現にしています

*4:これは元々無意識でしたが、レビューやモブプロを考えた時に、そうしているなと感じたことです

*5:モブプロ体験会時はPO役だったので何も口出しをしていませんでしたが、延長戦はPO役は取り払ってフリートークしていたので、内容の指摘に入っています

モブプログラミングをやっている人(及部さん)にレビューを語ってもらった話 #JaSSTReview

はじめに

この記事は、モブプログラミングアドベントカレンダーの23日目の記事です。

前日は martin_lover_se さんの モブプロが大好きなので熱い想いを言語化する です。

今回は、JaSST Reviewというイベントに、モブプログラミングの人(及部さん)を招待して、レビューについて語ってもらった話を書きます。

目次

JaSST Reviewとは

JaSST Reviewについての説明の前に、JaSSTの説明から。

JaSSTとはテストを題材に扱っているシンポジウム*1です。公式ページはこちら

2003年から毎年全国各地で開催しています。

f:id:nihonbuson:20181222084053p:plain
出典:JaSST Reviewオープニングより

そんなテストのシンポジウムでなぜレビューを取り扱うのか。それは、レビューとは静的テスト技法の一つだからです。*2

なぜJaSST Reviewにモブプログラミングの話をしてもらうのか

一見すると、モブプログラミングはレビューと無縁の存在のように見えます。

そんな中、本シンポジウムのプログラム構成を考えた私が、今回及部さんに発表を依頼したのは2つの理由があります。

理由1:レビューの内容と共通点があるのではないか

及部さんが以前から発表で伝えていた通り、レビューというプロセスは存在しません。

しかし、一般的にレビューのMTGで話す内容とモブプログラミング中に話す内容に共通する部分があるのではないかと考えました。

この考えは、今年の6月にあったJaSST’18 Kansaiで私が発表した頃から思い続けていた考えです。当時の資料にもその考えが載っています。

f:id:nihonbuson:20181221185103p:plain
出典:「超」やさしいレビュー ~開発とQAに壁はない!~(JaSST Kansai)より

理由2:純粋に指摘についての話が聞けるのではないか

一般的にレビューの発表というと、以下のような議論になりがちです。

  • 適切なレビュー MTGの参加者構成について
  • 適切なレビュードキュメントの読み方について
  • 適切なレビュー MTGを行うタイミングについて

一方で、私自身興味があるのは、レビュー時にどのような指摘をしているのかという点です。

なので、レビューMTGが存在せず、レビューMTGの形式について議論する余地がない、モブプログラミングでの場合を聞くことにしました。

以上の理由で、モブプログラミングを積極的に行なっている及部さんに講演を依頼しました。

講演を聞いた感想

私からの依頼を受けて、及部さんは素晴らしい発表をしていただきました。

内容については、発表スライドと及部さんのブログをご覧ください。

speakerdeck.com

takaking22.com

実は、私は講演を聞いて「狙い通りだった部分」「狙いとは(いい意味で)違った部分」の両方がありました。

狙い通りだった部分

忖度が発生するという話は、レビューで起きがちな問題で、それをモブプログラミングと比較することで明示してもらえたのは非常にありがたかったです。

f:id:nihonbuson:20181221184319p:plain
出典:「レビュー再定義」p48より

また、講演後のパネルディスカッションの時には、さらにレビューの指摘についての話が色々と聞けました。*3

  • リスクに気付くのは経験によるところが多いので、属人化は仕方ないものではないか。暗黙知暗黙知のまま伝えれば良いのではないか
  • 人にフォーカスしてレビューする。発言者の自信がなさそうな部分を見つけて深掘りしてみる
  • 時間軸を意識して気になる点を伝える。現時点では良くても将来気になる点があったり。
  • そもそも「指摘する」ということはあまりなく、質問をすることで深掘りしていくことが多い

狙いとは(いい意味で)違った部分

「レビューの必要性を感じてきた」という話は講演を依頼した私自身、非常に驚きでした。

f:id:nihonbuson:20181221184533p:plain
出典:「レビュー再定義」p58より

モブプロやレビューを行う意味を、3つの観点に分けた以下の図は大変新鮮でした。

f:id:nihonbuson:20181223143510p:plain
出典:「レビュー再定義」p59より

また、「あなたの言うレビューは本当にRe(再び)View(見る)なのか」という問いは、ハッとさせられました。

f:id:nihonbuson:20181221184628p:plain
出典:「レビュー再定義」p64より

この話は、モブプログラミング(モブワーク)という、レビュープロセスが元々存在しないからこそ見出せたものかなと思います。

おわりに

今回はJaSST Reviewというレビューについてのシンポジウムで、敢えてモブプログラミングの経験を伝えてもらいました。それによってレビューについてもう一度考えてみました。

JaSST Reviewに参加してモブプログラミングに興味を持った皆さん、登壇していただいた及部さんに本当に感謝します。*4

そして、皆さんがこれからも(レビューというプロセスがあるなしに関わらず)指摘・相談・質問する行為の時に活かせる内容になっていれば幸いです。

おまけ

このイベントの次の日に、モブプロの体験会を実施しました。

その時にテストエンジニアがどのような思考をしていたかについても別記事に書きました。そちらもどうぞ。

nihonbuson.hatenadiary.jp

*1:JaSST=Japan Symposium on Software Testing

*2:JSTQB シラバス参照

*3:一部、及部さんが話した内容ではないかもしれませんが、及部さんを含めた登壇者全員が同意した内容を含みます

*4:参加者の中で、ブログを書いてくださった方も出てきて、実行委員としては嬉しい限りです。

fortegp05.hatenablog.com

kdnakt.hatenablog.com

モブプログラミングにおける交代のタイミング

はじめに

この記事は謎の集団 Zenelo Advent Calendarの19日目の記事です。

前日は atom4lightning さんの Webフロントエンドにおける品質の可視化と向上を目指して(エラー監視編) でした。

モブプログラミングをしていく中で、様々な交代のタイミングを経験したので、今回はそれを紹介していきます。

目次

方法1:7分1分制

7分で強制的に終了し、次の1分間で「ドライバーをやってみた感想」「次のドライバーに引き継ぐ内容」などを伝える方法

オススメの現場

  • モブプロの体験をとりあえずしてみたい
  • ドライバーになることにまだ若干の抵抗感がある

実際に行なっていた場所

メリット

  • 1分のインターバルがあるため、そこで考えを整理できる。
    • 実況しながら手を動かす、というドライバーの役目に慣れていない人に有効

デメリット

  • 1分間のインターバルにナビゲーターが甘えてしまい、7分間のモブプロ時間内に集中しないことがある

方法2:7分制(10分制なども同様)

7分で強制的に終了し、次のドライバーにすぐ交代する方法

オススメの現場

  • 参加者全員がモブプロへの意欲がある現場
  • 時間内でドライバーを全員に経験させたい現場

実際に行なっていた場所

メリット

  • モブプロの本質である、みんなで取り組む姿勢が出る
    • さらに集中させる方法として、ドライバーが1名、ナビゲーターが1名、オブザーバーがその他全員というやり方もある。
      • ドライバー…キーボード操作をする人。ナビゲーターの指示なしで勝手にキーボード操作をしてはいけない
      • ナビゲーター…操作を指示する人。
        • この方法で行うと、ドライバー以上にナビゲーターの緊張感が高まる。なぜなら、唯一のナビゲーター全ての指示をすることになるので。
      • オブザーバー…ナビゲーターが助けを求めた時のみアドバイスをする人。ナビゲーターの代わりに指示をしてはいけない。
        • この場合、オブザーバーは基本的に「観察すること」が主業務になる。もしも観察をきちんとしていないと、ナビゲーターになった瞬間に「何をすればいいんだっけ?」となり、ナビゲーターを務められなくなるので。

デメリット

  • 中途半端な状態での交代になる可能性がある*1

方法3:1Step制

サイクルの1Stepごとに交代する方法。例えば、TDDにおけるRed -> Green -> Refactoring のそれぞれで交代したり。

オススメの現場

  • 区切りの良いタイミングまで1人で行いたい現場
  • TDDなどのサイクルを意識させたい現場

実際に行なっていた場所

メリット

  • 区切りの良いタイミングでの交代なので、次に何を行うのか分かりやすい

デメリット

  • サイクルの1Stepが長い場合、なかなか交代にならないことがある
    • 一番よくありえるのは、TDDでなかなかRedからGreenにならないパターン*2
  • 次にドライバーになるタイミングが1サイクルよりも大きい場合、そのサイクルが集中できない可能性がある
    • 例えば、TDDのサイクルでやっていた場合、次のドライバーになるタイミングが4人目以降だった場合、Red -> Green -> Refactoringの1サイクルでドライバーになれるのは3人だけのため、今回のサイクル内は集中しない可能性がある*3

方法4:我が家方式

コントトリオ「我が家」のように、代わりたいタイミングで「代われ!」と宣言し、ドライバーに自分からなる方法。

オススメの現場

  • どのメンバーもモブプログラミングに対して理解があり、かつ意欲的な現場
  • ドライバーになることもナビゲーターになることも嫌だと感じていない現場

実際に行なっていた場所

メリット

  • 時間やサイクルに縛られず、自分達が考える区切りの良いタイミングで交代できる

デメリット

  • 発言力やスキルに差がありすぎると、ドライバーになる時間の差が大きくなり、そのスキルの差を埋めにくくなる可能性がある*4

おわりに

今回は、今まで経験したモブプログラミングを交代のタイミングに着目して分類分けしてみました。

おそらく、これが正解!というものはなく、チームの成熟度によって変わっていくと思います。

もしもモブプログラミングがうまくいっていないチームがあれば、交代のタイミングについて見直してみるのもいかがでしょうか。

アドベントカレンダーは次の日の yuinchirn さんの 受け入れテスト駆動開発(ATDD)で簡単なiOSアプリを作ってみたにお繋ぎします!

*1:その交代がデメリットと感じている場合は、まだモブワークになりきれていない証拠かもしれないが

*2:逆に、それを利用することで、「交代してないということはRedが長くなっているから、一旦リバートしようよ」といった、改善に繋がる話ができる可能性あり

*3:そんな人はいないと信じたいが…

*4:ドライバーがきちんと実況しつつ操作できればスキルの伝達はできるかもしれない

WACATE 2018 冬に参加してきました! #WACATE

はじめに

この記事はソフトウェアテストアドベントカレンダーの17日目の記事です。

前日はおーだんさんのASTER-テスト設計コンテストのすゝめでした。

おーだんさんはテスト設計コンテストというイベントについてでしたが、私はWACATEというイベントについて書きます。

目次

WACATEとは

公式ページはこちらです。

wacate.jp

公式ページによるとWACATEとは、

Workshop for Accelerating CApable Testing Engineers:内に秘めた可能性を持つテストエンジニアたちを加速させるためのワークショップ

だそうです。*1

5,6名で1グループを作りワークショップ形式で行う1泊2日の勉強会です。半年に1度行われます。

「とりあえず話を聞いてみよう」という感じの勉強会ではなく、ワークも多いため、結構ガチです。ただ、それだけ得るものも多いです。

WACATE 2018冬の概要

WACATE 2018冬は、12/15,16に行われました。

今回は「C’mon baby ジドウカ」ということで、招待講演にt_wadaさんもお招きし、自動化も扱う回となりました。

ですが自動化だけでなく、プロセスやチェックリスト、ソフトスキルなど多岐に渡る内容でした。

ここでは、私のグループで起こった出来事を紹介しつつ、各セッションを紹介していきます。

BPPセッション

このセッションは、色々な経緯で私が発表者でした。*2

そこで、過去の勉強会などでの経験を通じ学んだ、「テストとは」という問いに対する様々な人の回答を紹介しました。

mentimeterというサービスを使い、聴講者の感想を聞いた結果、以下のようになりました。

f:id:nihonbuson:20181217231747j:plain
BPPセッションで一番響いた言葉

私の狙いとしては、「想い」が伝われば良いなと思ったのですが、それがある程度伝わったかなと感じました。

コマンド&コントロールから抜け出そう!?

概要

「コマンド&コントロール」の反対として「セルフオーガナイズド」という言葉を使って、どちらの思考を持っているかについて話し合いました。

詳しくは、おそらく公開されるであろう資料を参考にしていただければと思います。

グループ内で発生した会話

例えば、

「○○をお願いします」と言われた時に「嫌だ!」と返答するのは「コマンド&コントロール」「セルフオーガナイズド」のどちらか?

という話は、意見が分かれました。

  • コマンド&コントロール派…特に何も考えずに、今までと違う内容に拒絶感をしめして「嫌だ!」と発言している
  • セルフオーガナイズド派…自分の意思を持って、「嫌だ!」と発言している

個人的には、どちらの話が出ても良いと思っていて、重要なのは人によって感じ方が異なることを明示化できたことだと思っています。

JSTQB TA テスト技法の紹介

概要

タイトルの通り、JSTQB TAのテスト技法の解説及び演習の実施でした。

演習では、クラシフィケーションツリーを扱いました。

www.slideshare.net

グループ内で発生した会話

クラシフィケーションツリーの演習の結果、模範解答となる6ケースが導出できた人が2人いました。

ですが、その思考過程が異なっていたのが興味深かったです。

  • 思考過程1:最初にすべてのケースを導出し、そこから間引きできるものを削っていった
  • 思考過程2:どの部分を最初に考慮すれば効率化できるか考え、そこから調整しながら作成した。

どちらの思考過程でも良いと思っています。

ただし、その思考過程を共有できたのはWACATEのワークショップならではでした。(普段の業務だと結果しか共有されないことが多い)

プロセスを図にしてみよう!!「その仕事の地図を書くのは君だ!!」

概要

プロセスを示すことの重要性を解説し、プロセス図の一つであるPFDについてのワークを行いました。

グループ内で発生した会話

ワークを行った際に、以下のような結果を書いた人(Aさん)がいました。

f:id:nihonbuson:20181217231934p:plain
PFD(改善前)

これだと、inputが何も無いにもかかわらず、プロセスが発生しています。

そこで、以下のような会話をしました。

  • 私「これってどうしてinputが無いの?」
  • Aさん「だって、スケジュールを相談することで、スケジュールは作成できるから…」
  • 私「そしたら例えば、『テストを2日でやって』と言ったらそれでできる?」
  • Aさん「いや、それは流石に無理です!」
  • 私「え?どうして無理なの?だって、テスト実行のスケジュールはそれでできるじゃん」
  • Aさん「だって、テストの量が多くて、そんなの正しいスケジュールになりません」
  • 私「なるほど。それじゃあ、これって、テストの量が判断材料になるから、このプロセスのinputになりそうだね。」

f:id:nihonbuson:20181217232125p:plain
PFD(改善後)

これならば、inputがある状態の正しいPFDになります。*3

PFDを初めて書く人にとっては、inputが無いPFDになりがちです。

もちろん初めから書けるとは思っていません。

しかし、それも会話を通じて納得した状態で理解していけるのならば良いかなと思ってます。

組み込みマニュアルテスターだった私が、Web系自動テストエンジニアに!?💦テストエンジニアに求められるスキルと今後のキャリア💪🏻

概要

転職した時に感じた話を発表していました。

ワークはありませんでしたが、参加者に1年目が多かった今回のWACATEでは、広い視野を持つことの大切さを理解できるセッションだったのだと思います。

夜の分科会

概要

いくつかのテーマから自分が興味を持ったテーマに行き、話し合う時間でした。

私は、BDD+モブプログラミングを体験できる場を提供しました。

詳しくは別記事に書きました。

nihonbuson.hatenadiary.jp

(主に)Agile Testing Days 2018 参加レポート

概要

ソフトウェア技術に関する国際会議についての紹介でした。

私のグループでは、私以外誰も、カンファレンスに行ったことがないようでしたので、外の世界を知る良い機会になったのではないでしょうか。

本当に初心者の方に送る「そもそも自動化とは何か。自動化するために必要なスキルとは」について話すセッション

概要

タイトルの通り、自動化のとっかかりを伝えるセッションでした。

既に資料は公開されていますが、自動化に触れたことがない人にとっては本当にオススメの資料です。

www.slideshare.net

グループ内で発生した会話

「普段、身の回りで起こる業務の中で、自動化できるものは無いか?」というワークを行いました。

そこでは、「勤怠関連の自動化」という意見が多く出ていました。

そんな中、私が書いたのは「昼食時間を伝えるアラーム」です。*4

ここから連想しましたが、例えば「朝の目覚まし」も、毎日同じ時間に設定されており、これも一種の自動化なのでは?と感じました。

コードカバレッジを知ろう!

概要

ユニットテストの大切さと、それを測るものの一つとしてのコードカバレッジについての解説・演習を行いました。

speakerdeck.com

グループ内で発生した会話

私のグループでは、開発寄りの業務を行っている人が少なかったこともあり、なかなかワークで苦戦しました。

そこで、カバレッジに関する理解を深めるという以前に、どういうアルゴリズムなのか、解説することに重きを置きました。

しかし、結果的に後述する招待講演である程度の効果をもたらしたと思います。

自分のためのチェックリストを作れるようになろう

概要

良いチェックリストとはなにか、どのようにすれば上手く活用できるのか解説するセッションでした。

グループ内で発生した会話

チェックリストを見直すワークでは、その人が持っている背景の差異によって、見直した後のチェックリストの内容が違うものになっていました。

(ちょっと業務的な話が絡んでいる可能性があるので、ブログ上には詳しくは掲載しません)

50分で講師になれそうな気になるASTERセミナーテキスト

概要

ASTERセミナー標準テキストの紹介と、これを講座として活用するにはどうしたら良いかの解説・ワークを行うセッションでした。

www.slideshare.net

グループ内で発生した会話

ASTERセミナー標準テキストはJSTQB FLに準拠した内容です。

しかし、私のグループではJSTQB FLの取得者が一人もいなかったため、なかなか「ASTERセミナー標準テキストで教える側」という立場が想像できていなそうでした。

そこで、普段の業務で困っていることを聞き出して、そこから使い道を考えるワークにしました。

これも詳しくは業務に関わる話なのでここでは書けません。

ただ、「(特に自分の身の回りの人が)普段、何に困っているのか」と起点に考えると、何のために講座を行うのか考えやすそうでした。

ライブコーディングでわかるテスト駆動開発

概要

t_wadaさんによる、TDDのライブコーディングでした。

また、最後にはテストエンジニアがどのようにTDDのような活動に関わるかの話もしていました。

おわりに

今回は私のグループ内で発生した会話を交えつつ、各セッションの内容を簡単にですが紹介しました。

ここまで見て分かってもらえるように、WACATEは本当に濃厚な2日間でした。

次回は半年後(2019年6月)開催予定なので、興味を持った方はぜひ、WACATEのtwitterアカウントWACATEのページをチェックしてみてくださいね!

*1:私は未だに覚えられません

*2:詳しくはこちらの記事を見てください。

nihonbuson.hatenadiary.jp

*3:名前が「テストの量」としているのはネーミングセンスが無いですが、そこは一旦スルーで

*4:私は集中しすぎるあまり、昼食を忘れる傾向にあります

マツコの知らないテスト勉強会の世界

この記事はソフトウェアテストの小ネタアドベントカレンダーの3日目の記事です。

記事を書くきっかけ

社内でテストの勉強会についての話をすると、「え、テストの勉強会なんてあるんすか?」という反応を多く貰うので、おそらくマツコも知らないであろうテストの勉強会について紹介していく。

なお、以下の3つの観点で紹介する。

  • 開催頻度…どのくらいの頻度で開催しているか。頻繁に開催しているイベントほど、気軽に参加できるかもしれない。
  • 参加者数…どれくらいの参加者がいるか。大人数の方が、あまり勉強会に参加したことがない人も溶け込みやすいかもしれない。
  • 話題…どんな話題を扱っているか。大きく分けて「テスト設計」と「自動テスト」の2つに分かれそう。*1

その他、簡単な概要も併せて載せる。

今回紹介する勉強会一覧

f:id:nihonbuson:20181204001709p:plain
勉強会一覧

JaSST

公式ページ

JaSSTソフトウェアテストシンポジウム

イベントの特徴

  • 開催頻度 ★★★★★ (年9回)
  • 参加者数 ★★★★★ (最大のべ1500名)
  • 話題 テスト設計が多め

概要

日本最大級のテストシンポジウム。

毎年、全国9カ所で開催している。

毎年2〜3月あたりに行われるJaSST Tokyoは2日間でのべ1500名前後の参加者がいる。セッションも最大5トラック程度まで分かれており、まさにテスト勉強会の祭典といった雰囲気。

WACATE

公式ページ

wacate.jp

イベントの特徴

  • 開催頻度 ★★★☆☆ (毎年6月と12月)
  • 参加者数 ★★☆☆☆ (最大60名)
  • 話題 テスト設計が多め。ただし、今月の開催回は自動テスト中心

概要

同じメンバーでグループワークを2日間行うので、参加者同士も知り合いになれる。

毎回素晴らしい招待講演者をお招きしている。

今月行われる回は t_wadaさんが招待講演者。*2

wacate.jp

SQiPシンポジウム

公式ページ

www.juse.jp

イベントの特徴

  • 開催頻度 ★★☆☆☆ (毎年1回)
  • 参加者数 ★★★★★ (3日間のべ1500名)
  • 話題 テスト設計が中心。

概要

JaSSTが「テストシンポジウム」なのに対し、SQiPは「品質シンポジウム」。

JaSSTよりも参加費が高いこともあり、参加者層は年齢が高め&スーツ率が高め。

基調講演者、招待講演者が毎回バラエティに富んでいる印象。

Ques

公式ページ

quesqa.com

イベントの特徴

  • 開催頻度 ★★★☆☆ (毎年2回)
  • 参加者数 ★★★★☆ (200名前後)
  • 話題 開催回によって異なるが、テスト設計などを活用した事例が多め。

概要

三者検証のヒューマンクレストが運営する勉強会。

毎回、テーマを変更して行っている。先月あった第12回ではAIを、第11回ではIoTなどをテーマにしていた。

NaITE

公式ページ

nagasaki-it-engineers.connpass.com

イベントの特徴

  • 開催頻度 ★★★★☆ (2ヶ月に1回程度)
  • 参加者数 ★☆☆☆☆ (20名前後)
  • 話題 テスト設計が多め

概要

長崎IT技術者会という有志の団体が運営している勉強会。

長崎で行うこともあるが、東京開催が多い。

テーマはテストだけに限らず、開発系も取り扱っている。

テスト自動化カンファレンス

公式ページ

testautomationresearch.connpass.com

イベントの特徴

  • 開催頻度 ★★☆☆☆ (1年に1回)
  • 参加者数 ★★★★☆ (200名前後)
  • 話題 自動テスト中心

概要

テスト自動化研究会が運営している勉強会。

自動テストについて知見を持つ様々な人が発表している。

次回開催は今週土曜日(12/8)で、まだ募集しているが、既に応募数がすごい多い状態になっており、今から登録しても参加することは難しいかも…。

テスト設計コンテスト

公式ページ

aster.or.jp

イベントの特徴

  • 開催頻度 ★★☆☆☆ (1年に1回)
  • 参加者数 ★★★☆☆ (100名前後)
  • 話題 テスト設計中心。

概要

ASTERが主催しているイベント。

一つの共通した題材に対して、出場チームがテスト設計を説明し、その優劣を競うというもの。

普段のテスト設計事例だと、「自分が扱っている製品と状況が違うから…」となってしまうかもしれないが、このイベントでは同じお題に対して議論しているため、チームごとの特徴が分かりやすい。*3

なお、テスト設計コンテストの決勝戦は1日だけだが、各地方予選、U30クラス、チュートリアルなど、関連するイベントは多い。

Web QA Meeting

公式ページ

webqa.connpass.com

イベントの特徴

  • 開催頻度 ★★★☆☆ (毎年2回程度)
  • 参加者数 ★★★☆☆ (100名前後)
  • 話題 テストエンジニアの働き方の話など

概要

あるテーマに絞って、Web業界のテストエンジニアが議論する形式のイベント。

テスト設計などの技術的な話というよりは、働き方などの話が多い印象。

DeNA QA Night

公式ページ

dena-qa-night.connpass.com

イベントの特徴

  • 開催頻度 ★☆☆☆☆ (先日初開催)
  • 参加者数 ★★★☆☆ (100名前後)
  • 話題 テスト設計の話が中心

概要

先月に初めて行われたDeNA主催のイベント。

DeNAのテストイベントは、後述する Test Nightの印象が強いが、これからはテスト設計寄りの話も多く聞けるかも。

Test Night

公式ページ

testnight.connpass.com

イベントの特徴

  • 開催頻度 ★★★★★ (年10回弱開催)
  • 参加者数 ★★★☆☆ (100名前後)
  • 話題 自動テストの話が中心

概要

DeNA主催のイベント。

iOS NightとAndroid Nightで分かれている。

自動テストの話がほとんど。

AQA POP TALK

公式ページ

mercari.connpass.com

イベントの特徴

  • 開催頻度 ★★★☆☆ (不定期だが毎年2回程度)
  • 参加者数 ★★★☆☆ (100名前後)
  • 話題 自動テストの話が中心

概要

メルカリ主催のイベント。

海外カンファレンスの報告会が中心で、Agile開発の話や自動テストの話が多い。

お弁当が貰える。

Cybozu Meetup

公式ページ

cybozu.connpass.com

イベントの特徴

  • 開催頻度 ★★☆☆☆ (不定期だが、テスト関連の回は毎年1回程度)
  • 参加者数 ★★★☆☆ (100名前後)
  • 話題 自動テストの話が多いが、テスト設計の話もあり。

概要

Cybozu主催のイベント。

開発やSREなど、様々な回があるが、たまに自動テストの回やQAチームの回が行われる。

語る夕べ

公式ページ

kataruyube.connpass.com

イベントの特徴

  • 開催頻度 ★★★★★ (不定期だが、ほぼ毎月複数回開催)
  • 参加者数 ★☆☆☆☆ (20名前後)
  • 話題 テスト設計を中心としたディープな話題

概要

勉強会ではなく、ただ語りたい主催者と参加者が語るイベント。

講義形式ではないため、ただ教わる姿勢の人には難しいかも…。

テスト酒場

公式ページ

test-sakaba.connpass.com

イベントの特徴

  • 開催頻度 ★★★★★ (毎月開催)
  • 参加者数 ★☆☆☆☆ (10名前後)
  • 話題 ざっくばらん

概要

テストエンジニア同士が集まって、酒を飲むだけのイベント。

ただし、テストの話をすることがやっぱり多い。

おわりに

テストの勉強会をただつらつらと紹介してきました。

ここに載せた勉強会は、私がよく参加する(最低でも1回は参加した)、なおかつ他人にもオススメできるイベントです。

「とりあえず、テストの勉強会に行ってみたいんですけど…」という方は、ここに書いた勉強会を参考に参加を検討してみてはいかがでしょうか?

*1:開発でも設計と実装があるように、テストでもテスト設計とテスト実装があり、特にテスト実装は自動テストについて語られることが多い。

*2:残念ながら参加申し込みはもう締め切られてしまったけど

*3:そもそも「チームによってテスト設計方法は異なる」という前提を共有する必要があるのかもしれない。たまに「QAの人が作ったテスト設計がすべて正しい」と考えている開発者もいるみたいなので…

「実装実施時要検討事項」について自動テストを題材にして考えてみた #テスコン

はじめに

先日、テスト設計コンテストのチュートリアルに参加してきました。

aster.or.jp

aster.or.jp

チュートリアルが素晴らしい内容でした!

上記のリンク先に、チュートリアルの資料や当時のつぶやきもあるので見てもらえればと思います。

にしさんのツイートのおさらい

OPENクラスの講師をしていたにしさんが、テスト設計コンテストのあとにもツイートをしていましたので、その部分だけまとめました。

togetter.com

上記のまとめの中にある「実装実施時要検討事項」について、E2Eの自動テストを題材に再考してみます。

特にここらへんのツイートが深く関わります。

E2Eの自動テストで考える

今回はFacebookのログイン画面を題材にしました。

f:id:nihonbuson:20181029200226p:plain

テストケースを考えてみる

この画面を使ってE2Eの自動テストを作成する場合、どんなテストが考えられるでしょう?

例えば、ある開発者が以下のようなテストケースを考えたとします。

  • ログインIDとパスワードの組み合わせが実在するユーザーの場合
  • ログインIDとパスワードの組み合わせが実在しないユーザーの場合
  • ログインIDとパスワードの組み合わせが退会したユーザーの場合
  • ログインIDに何も入れなかった場合
  • パスワードに何も入れなかった場合

他にも色々と考えられると思います。

テストケースの作成意図を考えてみる

ただし、この画面についてE2Eテストで行う場合、どんな意図でテストを行うのでしょうか?

私ならば、

「ログイン成功ならばマイページへ、ログイン失敗ならば失敗画面へ、というようなページの出し分けを行いたい!」

と考えます。

この場合、テスト観点と実装実施時要検討事項は以下のようになります。

  • テスト観点…結果ページの出し分け
  • 実装実施時要検討事項…ログインIDとパスワードの組み合わせ

最初に挙げたテストケースについて見つめ直してみる

一方で、最初にあげたテストケースをもう一度みてみましょう。

  • ログインIDとパスワードの組み合わせが実在するユーザーの場合
  • ログインIDとパスワードの組み合わせが実在しないユーザーの場合
  • ログインIDとパスワードの組み合わせが退会したユーザーの場合
  • ログインIDに何も入れなかった場合
  • パスワードに何も入れなかった場合

この場合、先ほどは実装実施時要検討事項に入れていた「ログインIDとパスワードの組み合わせ」がテスト観点のように入ってしまっています。

これが、実装実施時要検討事項とテスト観点を混同した例です。*1

実装実施時要検討事項とテスト観点を分けた時のメリット

実装実施時要検討事項とテスト観点を分けると物事を整理して考えることができるため、色々なメリットがあると思います。

テスト観点を確認するタイミングを議論することができる

先ほどの題材では「ログインIDとパスワードの組み合わせ」を実装実施時要検討事項にしました。

すると、この「ログインIDとパスワードの組み合わせ」はどのタイミングでテスト観点として確認しよう?という議論にできます。

私の場合、これはログインIDとパスワードに関するロジック時点で確認すべきだと思っています。*2

つまり、以下のスライド内で重視すべきと言っている「多段式エラープルーフ」についても整理して考えることができるのです!

speakerdeck.com

しかも、この議論は基本設計時(プロダクトコードを実装する前)に既に議論できるはずです!

仕様・設計の変更にも追随できる

先ほど題材にしたFacebookログイン画面ですが、以下のように、ログインIDとパスワードで1つ1つ入力するページが異なるデザインに変わったとします。*3

f:id:nihonbuson:20181029201039p:plain

ログインIDを入力して「次へ」を押すと…

f:id:nihonbuson:20181029200926p:plain

パスワード入力画面に遷移する

この場合、テストも変更することになります。

そのとき、「ログインIDとパスワードの組み合わせ」をあたかもテスト観点に入れていた場合は困ったことになります。

別ページになってしまったことで、「組み合わせ」の概念が変わってしまい、網羅性も変わってしまうため混乱するかもしれません。

一方、テスト観点を「結果ページの出し分け」としていた場合、多少は結果ページの導線が増えますが網羅性の混乱は少ないでしょう。

おわりに

今回は実装実施時要検討事項とテスト観点の使い分けを、よくあるE2E自動テストを題材に考えてみました。

私は以前から、「テスト自動化にはテスト設計が重要」ということを常々思っていましたが、うまく説明できずにいました。

そこで、この「実装実施時要検討事項」という単語を用いることで整理して考えることができるようになったかなと感じました。

*1:と思ってます

*2:スパゲッティコードになっていてロジック部分で確認できない可能性もあります

*3:Yahooのログイン画面から拝借しました

テストエンジニアがTDDブートキャンプに参加してきました #TDDBC

はじめに

先日、TDDBCに参加してきました。

tddbc.connpass.com

このイベントで色々と学ぶことがあったので書きます。

目次

今回の題材

今回のお題は「自動販売機」でした。

プログラミングのお題: 自動販売機 (設計進化重視バージョン) · GitHub

ペアプロ時の工夫

TDDBCではTDDだけでなく、ペアプロも体験しました。 なお、今回は私(テストエンジニア)が常にナビゲータの立場、相方が常にドライバーの立場でペアプロを行いました。 そんな中、今回工夫した点をこのブログで共有します。

工夫その1:忠実に実装する

まずは、お題1を考えた時の工夫点です。

お題1. ボタンを押すとコーラが出る

ボタンを押すとコーラが出ます。

このお題に対し、コードは以下のように書きました。

public String buy() {
    return "コーラを購入しました";
}

しかし、これでは「ボタンを押すとコーラが出る」ではなく、「購入しようとするとコーラを購入できる」となり、お題の意図以上に業務全体を考えた実装になってしまっています。 なので、「ボタンを押すとコーラが出る」というお題に対して忠実に実装すべく、以下のように変更しました。*1

public String pushButton() {
    return "コーラ";
}

工夫その2:お題を分割する

お題1を終わらせた後、お題2を着手しました。

お題2. お金を払う

100円コインを投入してからボタンを押すとコーラが出ます。

100円コイン以外は投入できません。

このお題をそのまま行うのではなく、TODOの分割に着手しました。

TODOに落とし込むための会話ログ

以下は、TODOに落とし込むために行った会話です。


  • 自分「これって、どんなテストがありますかね?」
  • 相手「まず、100円コインを投入するとボタンが有効になるか(★1)、ですかね」*2
  • 自分「なるほど。100円コインを入れた場合の話ですね。他にはどんなテストがありますか?」
  • 相手「えっと、100円以外のコインを投入しても、ボタンが有効にならない場合ですかね。」
  • 自分「そうですね。ただ、『100円以外』とは具体的にはどんな値が考えられますか?」
  • 相手「例えば、10円コインですかね。」
  • 自分「ふむふむ。ちなみにこれらって、『ボタンが有効になる条件』をテストしていますね」*3

  • 自分「それでは、他にはどんなテストが考えられますか?」

  • 相手「ボタンを押した結果のテスト(★2)をしたいです」
  • 自分「ボタンを押した結果のテストって、具体的にはどんなことを考えてますか?」
  • 相手「ボタンが有効な場合に限り、ボタンを押すとコーラが出るようなテストですかね」
  • 自分「なるほど。それって、具体的なテストを考えると、どういう風になると考えてますか?」
  • 相手「100円コインを投入した後にボタンを押すとコーラが出るテストですかね」
  • 自分「ほうほう。そうですね。それ以外だとどうですか?」
  • 相手「ボタンが無効な場合、ボタンを押すと何も出ないことをテストしたいですね。」
  • 自分「それって、具体的にはどんなテストになりますか?」
  • 相手「10円コインを投入した後にボタンを押すと、何も出ない、とかですかね。」
  • 自分「なるほど。」

TODOを階層構造化する

ここまでを踏まえて、私は以下のように階層構造化して整理しました。

  • ボタンが有効になる条件をテストする

    • 100円コインを投入するとボタンが有効になる(★1)
    • 100円以外のコインを投入してもボタンが有効にならない
      • 10円コインを投入してもボタンが有効にならない
  • ボタンを押した結果のテスト(★2)

    • ボタンが有効な場合に限り、ボタンを押すとコーラが出る
      • 100円コインを投入した後にボタンを押すとコーラを出る
    • ボタンが無効な場合、ボタンを押すと何も出ない
      • 10円コインを投入した後にボタンを押すと何も出ない

階層構造化した文章のうち、青字は相方が思いついた部分、緑字は私との会話で加えていった部分です。

テスト設計の知識と紐付ける

今回行った会話は非常に興味深いです。

前半部分は(★1)のように、具体的な値を思いついて、そこからテストの条件を考えている、つまりボトムアップ型の考え方を行っています。

一方、後半部分は(★2)のように、どんなテストをすべきか考えて、そこから具体的な値を考えている、つまりトップダウン型の考え方を行っています。

実は、このボトムアップ型、トップダウン型という表現は、先日あったテスト設計コンテストU30クラスチュートリアルの資料及び発表でも話しています。

http://aster.or.jp/business/contest/doc/2019_U-30_V1.0.0%20.pdf#page=13

以下のツイートは、テスト設計コンテストU30クラスチュートリアルの発表聴講時のツイートですが、この発言は上記の会話のことを指しています。

工夫その3:Greenのままリファクタリングを行う

最後はお題3での工夫です。

お題3. ウーロン茶追加

押したボタンに応じてコーラかウーロン茶が出ます。

他の飲み物も追加してみましょう。

準備:お題2までのコード

お題2までで、こんなコードが出来上がっていました。(一部抜粋)

private boolean canBuy = false;
public String pushButton() {
    if (canBuy){
        return "コーラ";
    }
    return "";
}

一方、テストコードはこんな感じで書いていました。(一部抜粋)

@Test
public void 100円コインを投入した後にボタンを押すとコーラを出る() {
    VendingMachine vendingMachine = new VendingMachine()
    vendingMachine.insertCoin(100);
    String result = vendingMachine.pushButton();
    assertThat(result, is("コーラ"));
}

@Test
public void 10円コインを投入した後にボタンを押しても何も出ない() {
    VendingMachine vendingMachine = new VendingMachine()
    vendingMachine.insertCoin(10);
    String result = vendingMachine.pushButton();
    assertThat(result, is(""));
}

お題3の方針

お題3を考えると、以下のようなテストコードを考えたくなります。

private static final int COLA = 1;

@Test
public void 100円コインを投入した後にコーラのボタンを押すとコーラが出る() {
    VendingMachine vendingMachine = new VendingMachine()
    vendingMachine.insertCoin(100);
    String result = vendingMachine.pushButton(COLA);
    assertThat(result, is("コーラ"));
}

上記のテストコードを実現するには、お題2で"pushButton()"というメソッドだったのを、"pushButton(id)"というメソッドに変更することになります。

しかし、そのままメソッドの引数を変更すると、今度は今まで通っていた、"pushButton()"メソッドを用いたテストコードが通らなくなります。

新たなテストコードをGreenにするために、既存のテストコードを修正することになるため、新規テストコードのRed→Greenなのか、既存テストコードのRefactoringなのかが区別つかなくなります。*4

どうすれば良いでしょう…?

その時、教わった方法に納得しました。

既存コードをKeepしたまま実装する方法

手順1:別メソッドを作る

まず、別メソッド名で作ります。

private static final int COLA = 1;

@Test
public void 100円コインを投入した後にコーラのボタンを押すとコーラが出る() {
    VendingMachine vendingMachine = new VendingMachine()
    vendingMachine.insertCoin(100);
    String result = vendingMachine.pushButtonWithProductId(COLA);
    assertThat(result, is("コーラ"));
}
private boolean canBuy = false;
public String pushButton() {
    if (canBuy){
        return "コーラ";
    }
    return "";
}

public String pushButtonWithProductId(int id) {
    if (canBuy){
        return "コーラ";
    }
    return "";
}

上記のように、"pushButton()"とは別のメソッド"pushButtonWithProductId(id)"を作り、新規のテストコードは"pushButtonWithProductId(id)"を用います。

その際、"pushButtonWithProductId(id)"のメソッドの中身は、"pushButton()"のメソッドの中身をそのままコピペします。

これで、既存テストコードを変更することなく、Red→Greenにすることができました。

手順2:元々のメソッドを変更する

次に、"pushButton()"の中身を以下のように変えます。

private static final int COLA = 1;
private boolean canBuy = false;
public String pushButton() {
    return pushButtonWithProductId(COLA);
}

public String pushButtonWithProductId(int id) {
    if (canBuy){
        return "コーラ";
    }
    return "";
}

元々、メソッドの中身は"pushButton()"と"pushButtonWithProductId(id)"で全く同じでした。

なので、メソッドを呼び出しても同じ結果なはずです。*5

手順3:呼び出すメソッドを変更する

そして最後に、既存のテストコードで呼び出すメソッドを変更します。

すべてメソッドを"pushButtonWithProductId(id)"に変更したら、"pushButton()"が必要なくなるので、削除します。

private static final int COLA = 1;
@Test
public void 100円コインを投入した後にボタンを押すとコーラを出る() {
    VendingMachine vendingMachine = new VendingMachine()
    vendingMachine.insertCoin(100);
    String result = vendingMachine.pushButton(COLA);
    assertThat(result, is("コーラ"));
}

@Test
public void 10円コインを投入した後にボタンを押しても何も出ない() {
    VendingMachine vendingMachine = new VendingMachine()
    vendingMachine.insertCoin(10);
    String result = vendingMachine.pushButton(COLA);
    assertThat(result, is(""));
}

おわりに:ブートキャンプから学べたこと

今回は、テストコードもプロダクトコードも少ししか書いていませんでした。

しかし、ここで学んだことは、実務でも使える実践的な方法だったと思います。*6

それをブートキャンプの中で学べたのは非常に有意義でした。

*1:変更は、Greenの状態の時にRefactoringとして行いました。

*2:お題1で、業務全体ではなく実装に忠実になることを考えた結果、分割されたこのテストを思いつくのが素晴らしいですし、純粋にスゴイと思いました!

*3:本当は、ここで「コインを入れない場合」を思いついていますが、ここでは敢えて言いませんでした

*4:今回の例だと、同時に直せば良いと思うかもしれないですが、修正箇所が数十箇所あったらどうでしょうか?

*5:もちろん、このRefactoring中にもテストは常に回してGreenであることを確認します

*6:これがKataなのか…!