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

モブプログラミング AdventCalendar

はじめに

この記事は謎の集団 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

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

TDD ペアプログラミング

はじめに

先日、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なのか…！

WACATE 2018 夏に参加しました #WACATE

技術 勉強会 wacate

はじめに

6月16,17日にWACATEへ行ってきました。

wacate.jp

遅くなりましたが、今回はそのWACATEであったことを書きます。

目次

ガイドライン作成

今回のWACATEは、新たな試みとして「チームのガイドライン決め」を行いました。

これは、2日間のチームで目指したい雰囲気と、それを達成するための行動を示そうというものです。

まずは1人ずつ、目指したい雰囲気を書くのですが、私は「納得感がある」と書きました。

これは自己紹介の際に、WACATE2回目参加の方が「前回のWACATEはぶっちゃけ何も覚えてない」という発言があったためです。

それを聞いた私は、

  • この人に、今回のWACATEは印象を持って終えてもらおう
  • そのためには、この人自身が腹落ちして進めるのが大事
  • だったら、目指したい雰囲気は「納得感がある」状態だよね
  • これだったら、他の（特に初回参加の）人にも有益だよね

と思い、「納得感がある」と書きました。

BPPセッション

BPPセッションは吉武さんによる2017年度JaSST振り返りでした。

www.slideshare.net

このセッションでは、何しろ吉武さんのインプットの多さに圧倒されました！

そして、このBPPセッションが、今までインプットしていた吉武さんにとってのアウトプットの場の1つなんだろうなと、ひしひしと感じました。

1日目のワーク

1日目は、ユースケース図、アクティビティ図、状態遷移図について学びました。

www.slideshare.net

speakerdeck.com

分かっているつもりになっていたけど、難しい！

特に、状態遷移図では、チームメンバーそれぞれと書かれた図が違っていて、すごい驚きました。

そして、違う部分を見つけて、その違いについて議論し、納得してチームとしての答えを出すのが楽しかったです。

ちなみに、この行動は、2日目のワークに大いに役立つこととなりました。

ガイドラインの見直し

1日目の最後に、チームで定めたガイドラインの見直しを行いました。

ガイドラインの見直し結果についても、チームで納得できるものになりました。

そして、この見直し時間の最中に、誰かがボソッと「これって守り神だ…」と言いました。

その瞬間、「ん？今なんて言った？もう一度教えて！」と私は食いついて確認を求めました。

そして、そのボソッと言った「守り紙」（神ではなく紙にした）を、「ガイドライン」という呼び名に変えて採用し、紙に貼りました。

おそらく、この言葉がチームとしての結束をさらに深める出来事だったと思います。

自分で写真を撮っていなかったので、同じ班だった、たまのびさん( id:tamanobi )のツイートを拝借

夜の分科会

分科会では初心者向けのグループに混じって参加し、今回のワークの悩みなどを聴く役割に徹しました。

その時に、「状態遷移図が分からなかった」という初参加者（Aさん）から、以下のことを感じました。

  • 何が分かっていないのか分からない
  • （初参加者である）自分はどうしても、経験者である皆の足を引っ張ってしまう
    • 結果、ワーク中に質問をできなくなる

なので、私は以下の2つのプロセスを踏みました。

「何が分かっていないのか分からない」を脱却する

まず、Aさんに対して、その思考プロセスを聴くことにしました。

その時は以下のような問いかけをしました。もしかしたら、少し意地悪に感じるぐらいにわざとらしく。

  • 今回の問題って、どんなことが書いてあったっけ？
  • 具体的に、どんな命令をしたら、次のアクションにできたんだっけ？
  • それらの考えを、おそらく無意識に頭の中で考えていたうえで、紙にはそれをまとめた内容を書いたんだね。
  • 今言っていた細かいことも、どんどん書いていいんだよ

ここでのポイントは、「私の方からは何も答えを言っていない」ということです。

あくまでも、質問を答える人（Aさん）が考えていたということを強調させました。

Aさんは、私の少々意地悪な質問に対してもまっすぐ答えてくれました。ありがたかったです。

「質問できない」という状況を脱却する

Aさんへの問いかけが終わった後に、その様子をずっと見ていた他の参加者に「このやり取りを見ていてどう思った？」と聞きました。

すると、色々な意見が出てきました。

「こういう風な思考を元に自分はやっていたんだ」と思い返してくれた人もいたようです。

そして、Aさんに以下のアドバイスをしました。

  • Aさんが質問することは、他の人に対してこんなにも良い影響を与えてくれていた。
  • だから、チームメンバーに質問することは決して無駄なことじゃない。お互いのためにもなると思う。

Aさんが、2日目には、もっと積極的にチームに加われていれば幸いです。（他チームだから様子は分からなかったけど）

2日目の朝イチセッション「受けてみようUMTP認定試験！」

2日目の朝は、今回から実行委員になった岡内ワニさんの発表でした。

www.slideshare.net

今回のテーマであるモデリングを、WACATE後にどのように活かしていくかについて説明してくれました。

モデリングに対して、冷静に見つめ返す良い機会になった気がします。

2日目のワーク

2日目のワークは、あるお題に対してグループで成果物を出すというものでした。

このワークでは、いくつか工夫して進めていきました。

工夫その1「意見を極力拾っていく」

今回は、チーム内で一番参加回数の多い自分が方針を決めるのではなく、みんなの意見を拾って、一番納得度が高い部分を抽出して選んでいく方法にしました。

なので、ワークで扱う図についても、みんなの話を聞いて決めていきました。

工夫その2「自信のない人！」

ワーク中は、以下のStepで進めていきました。

  • Step1. 個人ワーク
  • Step2. 全員で見せ合ってすり合わせ

その際に工夫として、すり合わせの最初に「じゃあ、自信の無い人！」という声かけをしていきました。

そうすることによって、「自分はここまで完璧なものを描けてないから、自分の内容は無視して進めて…」みたいな意見を出させないようにしました。

グループワークは、グループのメンバー全員が参加者です。そこに、参加回数とか経験年数は関係ありません。

みんなが参加し、みんなで意見を出し、みんなで納得するように心がけていきました。

工夫その3「違いを見つけることに集中する」

1日目で、「皆さんの意見は少しずつ違うものだ」ということに気付きました。

そこで、私は特に参加者皆さんの意見を聞き、意見に違いが無いか探すことに集中しました。

言葉で話していると違いは見えづらいです。

しかし今回のモデリングのように、図を使いながら説明していることで、より違いに気づくようになりました。

工夫その4「納得してない顔を見逃さない」

最初のガイドライン（守り紙）で書いたように、「納得感がある」ということを目指すにあたり、納得してない顔を見逃さないように心がけました。

もちろん、「納得している（と思ってた）」という人もいます。

しかしそういう人も、納得してない人を前に、あの手この手で説明するうちに、「あ、自分も実は納得してなかったんだ」と気付くことができます。

私の班の場合、納得してない表情を示すのが上手かったのが、たまのびさんでした。

成果物

上記のような取り組みで行った結果、私のチームの成果物は、すべてのチームの成果物で一番少ないものとなりました。

しかし、私のチームの発表者を含め、おそらくメンバー全員が「この部分は重要」「この部分は苦労した」と言った内容が殆どズレない状態になっていたと思います。

余談の感想

たまのびさんは、自身のブログでこんな余談を書いています。

このWACATE 2018夏で知った手法を会社に持ち帰って、活かそうとするのは良い心意気だと思いました。 だけど、僕がこのWACATEで理解したのは、「何が問題か」「どこが重要か」見極めることです。 勇み足にならないために、ゆっくりと問題と向き合って、そのとき適切な手法で解決しよう。

WACATE2日目の感想 - TAMALOG

この余談って、すごい大事なことだと思います。

私自身もワークをしていて実感できたのですが、「どこが重要か」を見極める、適切な手法を見極めることの大切さがあると思っています。

今回は、ユースケース図、アクティビティ図、状態遷移図の3つでしたが、それぞれが独立であるのではなく、1つの図のアウトプットが別の図のインプットの手がかりになったと実感できました。

招待講演「原因結果グラフとWACATEは僕に何を教えてくれたのか」

招待講演は加瀬さんによる原因結果グラフについての講演でした。

www.slideshare.net

加瀬さんは、一つ一つ具体例を用いて説明してくださったので、すごい分かりやすかったです！

また、秋山さんのお話しなど、多岐にわたってお話ししてくださいました。それらの話も非常に興味深かったです。

クロージング（ポジションペーパー賞の発表）

さて、このWACATEでは毎回、クロージング時にポジションペーパーに関する賞が発表されます。

ポジションペーパーとは

WACATEの参加者が、参加表明時に提出する紙のことです。

2日間、この紙を使って自己紹介などをします。

ガイドライン作成の章にあった、「前回のWACATEはぶっちゃけ何も覚えてない」という話も、ポジションペーパーに書いた内容を元に話していました。

ベストポジションペーパー賞

ポジションペーパーは自己紹介のためだけではありません。

同時に賞の対象にもなっています。

そして、その中のベストポジションペーパー賞に私の内容が選ばれました！

f:id:nihonbuson:20180626001253j:plain

ということで、今回「2017年度JaSST振り返り」を発表した吉武さんのように、次回のWACATEで発表する権利を頂きました！

私のポジションペーパー

私のポジションペーパーの内容を公開します。

f:id:nihonbuson:20180626081947p:plain

製品開発を見ていると、いがみ合い・戦いの末に出来上がっている製品が非常に多く感じています。

そうではなく、如何に皆が幸せな状態のまま製品開発に向かうことができるのか、常に考えながらやっていきたいと思って、今回のようなポジションペーパーを書きました。

おわりに

最近、勉強会や仕事をやっていると「テストって何だろう？」と思い返すことが多くなりました。

そのときに、JaSST Kansaiで見た以下のツイートをきっかけとして、にしさんの講演を見ました。

www.youtube.com

「テストとは納得してもらうことである」

良い言葉だなと思います。

今回のWACATEでは、この納得を実感できたワークになったように感じました。

余談：他にもたくさん、今回のWACATE記事があがってますよ！

今回はブログ記事にしている人が多いなー。

inside.pixiv.blog

tamanobi.hatenablog.com

tamanobi.hatenablog.com

tonono.hatenablog.com

tonono.hatenablog.com

yoshikiito.net

yoshikiito.net

teamomusoba.hatenablog.com

teamomusoba.hatenablog.com

panmania.hatenadiary.com

panmania.hatenadiary.com

qiita.com

tanakalivesinsendai.hatenablog.com

ameblo.jp

devtest.hatenablog.com

QA Meetup 2018 パネルディスカッション 参加レポート #QAMU2018

技術 勉強会

イベント概要

  • 先日、QAについてのMeetupがビズリーチで行われました。

  • 今回はその中の後半にあったパネルディスカッションについて載せます。

登壇者

パネリスト

  • 小林 依光（以下、小林）
    • KLab
  • 安納 達弥（以下、安納）
  • 柿崎 憲（以下、柿崎）
    • サイバード
  • 中野 直樹（以下、中野）
    • LIFULL
  • 江川 さおり（以下、江川）
    • ビズリーチ

モデレータ

  • 山本 健（以下、番長）

明日からのQAの方向性

  • 柿崎

    • 厳しいテーマですね
    • 僕の考え、会社の求めているのは自動化
    • 自動化をまったくやっていないわけではない
      • APIレベルならやっている
    • フロントエンドもテストのインフラがほしい
    • 腕に覚えがあれば
    • フルスタックがあれば
    • サイバードという視点から言えばフルスタックがほしいです

  • 中野

    • LIFULLの人材を募集してます
    • 基本的にはエンジニアリングや開発のことをわかってほしい
    • 各社自動化を取らざるを得ない流れ
    • それも踏まえ、プロダクトのステージを考え、メジャーなプロダクトとスタートアップのプロダクトがある
    • 新規事業で色々と立ち上がっている
    • ステージによって求められるものが違う
      • テスト戦略が求められる
      • テスト戦略をきちんと組み立てる

  • 小林

    • 高速DevOPS
    • 計画があるない、仕様があるないで異なる
    • 不確実性の中から確実性を見つける
    • 求心力を捉える
    • どうやって積極的に取得するか

  • 安納

    • 自分たちがやってる目的を考える
      • ユーザーさんに喜んでもらう
      • 正しく動くとか
    • つまんないゲームってやるんですか？
    • 求められるものが品質
    • その中の一部が自動化
    • 人の感情も担保していくのがアカツキとしての品質
      • 人の感情を動かせるようにする

  • 江川

    • テストアーキテクチャ
    • 手数が足りない
    • 自動化を推進したい
    • 自動化は当たり前になるはず
    • 自動化に興味があれば来てほしい

テストロールの評価（人事評価）

  • 番長

    • テストエンジニアの評価は難しいと思っている
    • どのように評価を行っているのか聞いていきたい

  • 小林

    • まだ品質管理チームを再始動しているので、明確な定義がない
    • メーカーの中にいたころはロールが無かった
    • そういう意識を持ってほしい
    • Web系に転職したら、テスターの方がヒエラルキーが低いのが驚いた
    • ある程度整備できたら、JSTQBで定義している資格のロールに従っているようになると思う

  • 安納

    • 3つある
      • 専門性
      • 自立性
        • 課題解決力
      • チーム力
    • QAだからという区別はしてない
    • 良いものをリリースする時にどれだけ貢献できたのか
    • その中のオリジナリティとしてスペシャリストがいたり
    • 能力とかやりたいことをやっていく
    • あまり固定せずに、売上とかに貢献できたのかを考える
    • そういうところをベースにして取り組んでいる

  • 番長

    • できれば、給料が上がるのか含めて教えてほしい

  • 中野

    • QAエンジニアもエンジニアだから評価は同じ
      • ベースは一緒
    • テクニカル面
    • 業績については、半期ごとの目標に貢献できたか

  • 江川

    • 利益を社員に還元することは良い
    • 1人しかいないので、評価も自分で作っている
    • レベル分けしている
      • テストオペレーター
      • テストリーダー
      • テストマネージャー
    • 最初はセントラルで
    • その後、各プロダクトへ

  • 柿崎

    • プロダクトにどのように与えるか
    • 自動化だけではない
    • 炎上を鎮火することが評価されがちだけど、未然に防ぐことも評価している
      • 外部環境の変化に対応することを重要にした
        • GoogleやAppleのレギュレーションに敏感に反応した社員を評価したり

キャリアチェンジ・キャリアアップ

  • 安納

    • テーマが難しい
    • どうやって作るんだっけとか、作るまでの過程を考えて、その準備ができた人からQAの部署に極めるとか
    • 行けば良いんじゃないかな

  • 小林

    • キャリアチェンジはいくつかやり方がある
      • プログラムが掛ける人は品質管理に来ることができる
        • 仕組みを知ってるので、スクリプトや自動化を考えられる
    • テストやQAやってると、将来どうなるのか？
      • PMOになる人もいる
        • 全体を知っていることが多いので
      • プロセス的な話として、ルールを作る
        • ソフトウェアプロセスエンジニアリンググループ
      • AgileやDevOPSに対応して、Scrumマスターになったり

  • 江川

    • 一般的には、オペレータ、リーダー、マネージャへ
    • 大事なのは、何になりたいのかをしっかり考えること
    • ビズリーチの場合は、SETの人が良い

  • 中野

    • 開発からQAになりたい
    • 私もそれになった
    • 自動テストフレームワークをやってたら、うっかりQAになった
    • どうやったらなれるか
      • やりたいからやるって言えば良い

  • 番長

    • 踏ん切りがつかないときの体験入社はできない？

  • 中野

    • 契約形態をとって入社とかなら…
    • あとはワークショップとか

各社で採用している技術

  • 柿崎

    • サイバードでは、いろんなプロダクトが平行で動いているので、都度都度ベストな技術を使う
    • UnityやC#をフロントで使っている
      • 勉強会で学んだ
    • バックエンドはPHP
    • AWSを使ってもいる
    • 最近はボイスUIでGCPも使いたいと思っているが、AWSに寄せすぎていて揉めていたり
    • 技術採択は1ヶ月に1回偉い人が集まっている

  • 安納

    • 開発環境で良いんですかね？
    • イマイチ分かってない部分がある
    • ほぼAWSで動いている
    • データベースはオーロラ
    • サーバー側はRuby on Rails
    • フロントはUnityとか
    • 最近はAWSからGCPになったり
    • 私はAWSの価格交渉担当になっている

  • 江川

    • 事業部がたくさんあるのでチームによって違う
      • 基本的にはScala
      • 最近はElm推しの人が入社した
      • 自分たちでキメていける
    • Jenkinsが基本だが変えようとしている

  • 柿崎

    • 各チームでバラバラだと、プロダクトがポシャった時にスライドしづらいのでは？

  • 江川

    • 事業部ごとに違う会社のようになっている
    • プロセスも違う

  • 中野

    • 推しのポイントはない
    • 自分たちで決めてやっている
    • QAは昔Pythonだったが今はRubyになってる
      • 自動テストとか
    • あとは、レコメンドをAIでやってる
    • また、Home'sアプリは、かざして検索ができるようになった

  • 番長

    • 「かざして検索」のテストはどうやって？

  • 中野

    • ETしかやってないので…

  • 小林

    • サイバードさんやアカツキさんと似ていて、ゲームでユニークな技術はそこまでない
      • Unityを使ったり
    • 世の中にあるものの良いものを適宜使っている
    • 機械での自動テストでは、OpenCVで画像認識をしたりしている

テスト・品質管理の肝

  • 江川

    • 柿崎さんがコアバリューとおっしゃっていたのが本当にそうだと思う
    • ユーザーが何を使いたいのかを考えている

  • 安納

    • 我々の製品を使って長く遊んでもらう
    • ユーザーさんにどれだけコミットできるのか
    • 満足度を高めるためにどうすればよいのか

  • 中野

    • 新しい技術を開発が持ってくる中で、他人事と思わずにQA側もどうすればよいのか考えること
    • 多様性の中でどのように進化させるか考える

  • 小林

    • 日科技連では肝を108個紹介していて、読みきれなかった
    • メトリクスをいっぱい取りたいと思うかもしれないが、それを伝える品管が必要なのではないか

  • 柿崎

    • アンテナをめいいっぱい高く張ること
    • GoogleやAppleは技術革新を猛スピードでやっている
    • どんどんプロダクトが死んでしまっている可能性が高い
    • この会場に来ている人は十分高いはず
    • 他の来てない人のアンテナも高くするようにしてあげてほしい。

感想

  • 「この部分ができる人が欲しい」というのが各社ハッキリとしていた印象だった
    • その中でも自動化は当然のように求められているなと感じた
  • テスト・品質管理の肝についてはもっと聞きたかった。