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+モブプログラミングを体験できる場を提供しました。

詳しくはまた別記事で書く予定です。

(主に)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なのか…!

WACATE 2018 夏に参加しました #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人しかいないので、評価も自分で作っている
    • レベル分けしている
      • テストオペレーター
      • テストリーダー
      • テストマネージャー
    • 最初はセントラルで
    • その後、各プロダクトへ
  • 柿崎

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

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

  • 安納

    • テーマが難しい
    • どうやって作るんだっけとか、作るまでの過程を考えて、その準備ができた人から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個紹介していて、読みきれなかった
    • メトリクスをいっぱい取りたいと思うかもしれないが、それを伝える品管が必要なのではないか
  • 柿崎

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

感想

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

Web Service QA Meeting June-2018 第1部参加レポート #WebQA

はじめに

先日、以下の勉強会に参加してきました。

lifull.connpass.com

第1部では事前に決めていたお題を3つ、第2部では会場から募った質問に答える形式でした。

私は都合により、第1部しか参加できませんでした…。

※酒が入った状態で書いたので、途中、話した内容と違う可能性があります。その場合、指摘いただけると嬉しいです!

目次

お題1「0からQAチームを立ち上げるまで」

登壇者

モデレータ
  • 米山 允章(以下、米山)
パネリスト
  • 山本 健(以下、番長)

    • スライドの画像は韓国旅行のときにサングラスをかけた写真
    • 実際は怖くないです
  • 鶴岡 洋子(以下、鶴岡)

    • ビールが好きです
    • 緊張するんでビールを飲みながら話します

テーマを決めた経緯

  • 米山
    • JaSSTで質問を集めたときに、もっとも投票が多かった質問
    • ただし質問にたどり着かなかったため、今回行う

QAを立ち上げた経験は?

  • 番長

    • 最初のQAとして1人で入ることが多くて、出来上がったチームに入ったことがない
  • 鶴岡

    • 今いるユニファは0から立ち上げるところに関わった

立ち上げ当時の状況やロードマップはあるか

  • 鶴岡

    • 入社時の社員数は20名ぐらい、サーバーサイドのエンジニアが4名、CEOもプレイヤーでした。
    • プロセスの把握、改善点を見つけてカイゼンしていった
    • QAってどういうお仕事を説明した。
      • キャッチコピー「かゆいところに手が届くQA」と言ってた
    • チケットを書いてた
    • 定期リリースにしたい!と言ったりした
    • 要求分析していなかったので、想いを言ってた
    • 「QA」ってこんなもんすよと説明した
    • 社長がMTGしてたら、「話聞かせて」といったり
    • JIRAのステータスの管理をしたり
  • 番長

    • 会社の10人目、はじめてのQAスタッフとして入った
    • 海外赴任していたスタッフがQAのイメージを既に持っていた
    • 最初は既存のフローに入って、どんな価値観でやっているか把握した
    • どういうカイゼンをすればよいか考えた
    • 文化がない状態なので、何をしていくべきか考えてた
    • 立ち上げ時には要求されることがコロコロかわる
      • それに対応するようにしてた
    • ロードマップの話は難しいな
  • 鶴岡

    • ロードマップの話は特にしてなかった
  • 米山

    • 0から立ち上げるのは不安なのかなと思ってた
    • これを聞いてみんな安心するのではないか

立ち上げ時に意識するべきこと。最初の一人に求められるスキル、人間性、経験

  • 鶴岡

    • QAとは何をするべき人なのか色んな人に伝える
      • QAはエンジニア以外にもかなり多くの人とかかわる
    • QAの価値を伝える
  • 番長

    • QAに対する意識がバラバラ
      • 以前に良いQAとか関わっている人は良い
      • 悪いQAに関わった経験がある人は「何だよ」と思って接してくる
    • フレンドリーに接することが大事
    • 最初は良い印象を持っている人と仕事していくことで、「なんだ、QAがいるあのチームいいじゃん」と周りが気づき始める
  • 鶴岡

    • 困っている人を見つけて、どんどん助けていく
  • 番長

    • プレスリリースを書いたりもした
      • リリースされたものの要件を知ってるから書きやすい
      • 既に出ていたプレスリリースを真似して書いた
  • 米山

    • プロダクトがローンチしたあとに入った場合は?
    • ローンチしたあとに入ると辛いのでは?
  • 番長

    • 遅らせる=悪となってしまうので、スピードは大事
    • これぐらい時間がほしいです、という話を予めしておくようにした
  • 米山

    • 2人目のQAはどういうタイミングでどういう人を選ぶ?
  • 鶴岡

    • 自分一人で回らなくなったタイミングで
    • 自分と真逆の人を選んだ
  • 米山

    • 真逆の人だと働きづらいのでは?
  • 鶴岡

    • 全然そんなことない
    • 自動化とかやってくれて助かってます
  • 番長

    • スキルとかばらして集めたほうが良い
    • ただどんなスキルであれ、献身的な態度の人が良いと思う

立ち上げが好き?立ち上げたら次に行きたくなる?立ち上げ中毒?

  • 番長

    • その話は転職芸人で…(笑)
    • さんざん悲劇に襲われていて、仕方ない感じで入る
    • 短くても4年ぐらいはいる
    • 立ち上げ時は、文化や自分が良いと思った体制を組めるのが楽しい
  • 鶴岡

    • その分勉強をする必要がある
    • 自分の理想としているQAができる
    • 私の場合は、立ち上げちゃったら抜けづらくなった
      • 責任感が出てきた
    • 中毒というわけではない

100人規模の大きい組織でQAをゼロから立ち上げるときに意識すべきことは?

  • 番長

    • きっとお金は稼げているプロダクトなので、きっとQA役になっている人がいるはず
    • おそらくQA役となっているであろうディレクターさんに「これは私がやるので」と言ってみる
  • 鶴岡

    • それまでQAがいないということは、QAの価値を上の人が分かってない可能性がある
  • 番長

    • いろいろと社内事情がつらそう…

グローバルの立ち上げで意識したほうが良いことは?

  • 番長

    • 一回関わったが、お互いの国のやり方に触らないようにした
  • 米山

    • 弊社もそうです
  • 番長

    • QAは細かい単位で入らないといけないので、「グローバルで一つの基準を作りましょう」は厳しい

最後に、立ち上げに入ろうとしている人にアドバイス

  • 鶴岡

    • 公の場では言えないことも多いので飲みに行きましょう
  • 番長

    • 辛くなったときにリセットボタンを押して、リフレッシュできるようにしておきましょう

お題2「キャリアプランとビジョンについて」

登壇者

モデレータ
  • 米山 允章(以下、米山)
パネリスト
  • 山本 久仁朗(以下、くにお)

    • いろいろ転職しているが、嫌で転職しているわけではない
  • 柿崎 憲(以下、柿崎)

    • ここにいる3人は転職を多くしている
    • お酒が2本目に突入しているので、いろいろ楽しいことになるかと思う
  • 山本 健(以下、番長)

テーマを決めた経緯

  • 米山
    • JaSSTで質問を集めたときに、キャリアに関する質問が多かったため

QAエンジニアのキャリアパスはどういうものがあるか?

  • 米山

    • QAメンバー → QAリーダー → 品質保証マネージャ → その後は?
    • CQOがまだ浸透していない気がします
  • くにお

    • うちの会社ではCTOになれる人材を作ろうとしている
    • 同様に、QAとかQCとかのスペシャリストができる人を作った上で、トータル的にデキる人を作りたい
    • 自動化などのエンジニアリング寄りもできる人を作りたい
    • ISTQBでもいろいろなドメインがあるので、そういう方向もあると思っている
  • 番長

    • だんだん、位があがっていくと、日本を考えると難しい
    • 自動化は流行っているし、マネージャが一段落した印象
    • いろんなポジションをできるほうが幸せだと思う
  • 柿崎

    • 僕はすでにCQOみたいな位置で仕事している
    • Web系に来たんだったら、キャリアパスって関係ないでしょ
      • てめーでつくれよ
    • いろいろ考えてみたが、どんどんステップアップしていくときって、人に対する影響範囲が広がっていく
      • それが一つのキャリアパスの形
      • マネジメント寄り、ビジネス寄りの話
    • QAエンジニアと名乗る以上は、技術を語れるようになるべき
    • 人数の規模が自分のキャリアパスを構築している
    • テクニカルであれば、新しいテスト技術を作って変えていくという方法もある

今のキャリアを想像していましたか?今後のキャリアプランを教えてください

  • くにお

  • 番長

    • 今は47
    • もともと別の業界を目指していた
    • もともと美術系の大学で、画家になろうと思っていた
    • 面白いものに関わっていきたい
  • 柿崎

    • 今のキャリアは全然想像していなかった
    • 20代後半まではチンピラのような仕事をしていた
    • 初めて品質保証に関わったのはSCEのとき
    • ソフトウェアテスティングの技術を教えてくれた人がいた
      • すごい運が良かった
    • その後はWeb系のテスターに入ったり
    • mixiに入ったあとは良い出会いが多かった
      • 人に会いに行く姿勢を教えてくれた人がいる
      • 今日誘ってくれた人に会うこともできた
    • 出会いの中でできたと思っている
    • 計画的偶発性理論
      • 人のキャリアの8割は偶然起きたことの結果
    • キャリアと考えると10年先とか考えることが多いと思うが、今を考えるべき
    • 新しい機会があったら実現する
      • こういうテスターになると思っていれば、それに強いひとに会いに行けば良いのでは
      • 自分が気づけなかった自分に気付ける
    • 中小企業は後継者不足で潰れることが多い
      • 変な中小企業を買って再建したい

キャリアパスに正解はないと思うが、どんなふうにメンバーに見せたらいいか悩んでいる

  • くにお

    • 転職繰り返しているので気づいていると思うが「無理をしない」ことが大事
    • 楽しく思える現場で楽しくやるのが一番大事
    • 納得する場所で楽しくやっていれば、下の子も楽しんでやってくれるのでは
  • 番長

    • Webの世界は面白すぎて悩む必要がない
    • 美術だとお師匠さんが引退しないとやれる機会が少ないので…
  • 柿崎

    • エンジニアの場合はゴリゴリプログラミングをやることになる
      • プログラミングをやらないとぼんやりする
    • Webディレクターにも同じような悩みがある
    • テクニカルな解決方法を教えることでキャリアアップになる
    • 内発的動機ができれば、キャリアアップできる
    • 「お前が歩いたところがキャリアパスだ」となる
    • どういう風に見せればよいかというと、一緒に悩む
    • 真摯にテクニックを教える
    • あとは「俺の背中を見ろ」と
  • くにお

    • 来た人には教えるが、来ない人には教えない
      • ROIが悪いので
    • みんなを救う気はない
    • やる気のある人は救いたい
  • 柿崎

    • 自分のところだと運良くみんなやる気がある

エンジニアからマネジメント側に移った時、大変でしたか?

  • 米山

    • 準備しておいたほうが良かったこととかありますか?
  • 柿崎

    • エンジニアとマネジメントはまったく別のスキルセット
    • 「マネージャよろしく」って言った瞬間にみんな潰れる
    • テクニックと別の部分がある
      • ぶっちゃけ、顔も見たくないやつと1on1をしなくちゃいけない
      • 裏でなにか言ってるやつにやらせなくちゃいけない
    • 「モチベーションを上げるとかわかんねえよ」とか言ってる
  • 番長

    • マネジメントに移るときは、部下の評価ができる権限をちゃんと貰ってください
    • 褒めたのに評価が上がらないとかのズレが…
  • 柿崎

    • 今まで、なんかあったんですね…

キャリアに対して悩める志士へ一言

  • くにお

    • 過去のスライドにキャリア3部作を作ったので、それを見てください
  • 番長

    • いちいち悩んじゃいけません
  • 柿崎

    • いろんな人に興味を持って会いに行きましょう

お題3「テストの生産性ってどう見てるの?」

登壇者紹介

モデレータ
  • 小山 竜治(以下、コヤマン
    • 半年前にfreeeへ
    • 今までは組み込み系とかをやってた
    • イケメン(中野さん)とタメ
    • JSTQBの公認講師
    • テスト自動化研究会でAutomaterのスキル基準のリーダー
パネリスト
  • 柿崎 憲(以下、柿崎)

    • QAテストの力が会社のインパクトに影響するを証明したい
    • サイバードの業績が出ているので、見ていただきたい
    • V字回復している
    • 社長が変わったのもあるかもしれないが、私の力です
  • 菅原 史晴(以下、菅原)

    • 34歳
    • QAテスト歴11年
    • 内製サービスのQAをやってる
  • 中野 直樹(以下、中野)

    • ししゃもが好きです
    • この瞬間まで乾杯を我慢してた。かんぱーい!

テーマを決めた経緯

  • ヤマン
    • 今回の参加者のうち、今年のJaSST'18 TokyoのWebJaSSTのセッションに参加した人は、全体の1/3ぐらい
    • 今回のテーマの質問があったが、投票が少なかった
    • JaSST'18 Tokyo終了後、中野さんも良い質問だと気づいた
      • 気づくのが遅いけど
    • DevOpsでスピードを求められる中で、テストがイケてるか考えると、旧来のだと重すぎる
    • それでもテストをしているというのは、テストに価値があると思っているからやっているはず
    • 何かしらの工夫をしているはず
    • 価値の証明ができないので、プロセスに入れましょう→重くなる、面倒になる
    • Web系ならではの工夫をもって証明しているはずだ
    • 僕が聞きたいんで、この質問を選んだ。

中野さんの場合

  • ヤマン

    • まずは中野さんに聞きたい
    • 何らかのメトリクスや説明資料を使っているのでは?
  • 中野

    • 「イケメン」をいじってるよね(笑)
    • 基本的に計測しているのは、
      • 本番での障害件数
      • 自動テストがきちんと要件を満たした状態で動き続けているか
      • リリース件数
    • Web系はテストを丸受けすることがない
    • テストのプロジェクトはものすごいインパクトがある
    • 技術的な指導だったりする
  • ヤマン

  • 中野

    • とっている
  • ヤマン

    • 金額とか、工数に換算している?
  • 中野

    • 一時やっていたが、今は止めてる
    • ビジネスアウトカムをQAのしごとにしちゃうと、儲かるプロダクトに関わっていれば良いことになってしまう
    • 納品していて、QAのおかげでお金になったとハッキリ分かればよいが、正直遠い
    • 腹落ち感が低いので止めた
    • 自分が携わっているプロダクトの場合、1年周期で波があり、障害件数も波があるので、昨年対比で見ている

柿崎さんの場合

  • 柿崎

    • お金を見てます
    • テストにどれぐらいの工数がかかってとか、プロダクトの比率とかも見てる
    • 単体でだけでなく、プロダクトとしてのコンディションを見るためにお金を見ている
    • サイバードはゲーム会社なので、お金がどれぐらい使われていてというのは今までは見てなかった
    • 欠陥の検出率も重要
      • 社内と本番の比率とか
    • Unitテストのカバレッジも見てたり
    • ありとあらゆるメトリクスを見てる
    • あとからどうやって考えるか大切
      • リリース後の故障発生率を経営陣に示したり
    • 定性的な話で言えば、品質の危機(メンテまつり)とかあって、ポシャったゲームもあった
    • 必ずしも信頼度成長曲線が正解ではないが、それらしいものを見せることができる
    • 今もそれは継続している
    • どっちかというと絶対値ではなく継続してみている
  • ヤマン

    • 柿崎さんらしく真面目な回答ありがとう
    • 売上が上がったって「ゲームが面白いからじゃん」と言われそう
  • 柿崎

    • 純粋に僕がガバナンスを効かせたら、リリース後直メンテに入る状況が止まった
    • 新規リリースの場合、こういう世界が来ますよ、というのが信頼度成長曲線を使って説明できた
    • OKとかNGとかを説明できた
  • ヤマン

    • バグの重要度とかリスクカバレッジとか考えて、リスクの高いものを優先的に取り除くようにしていた?
  • 柿崎

    • メンテ入りバグの変化をとってた
      • 新規リリースしたあと、メンテの事態になるまでの時間
    • メトリクスはシンプルなものを継続的に取るのが大事
    • パーンと数値が跳ね上がるのを気づくのが大事

菅原さんの場合

  • 菅原

    • メルカリだと、3つのプロダクトがある(アメリカ、イギリス、日本)
    • 私は日本のメルカリのオートメーションQAチームに居る
    • 日頃、E2Eの自動テストや、システムテストのインフラ部分を担当している
    • 特に生産性を測ることは具体的には今の所何もしてない
    • 何かを測る時、計測の仕方、入力をするという行為自体が生産性を落としている
    • マネージャのための仕事が一番イヤだなと思っている
    • 日本のメルカリのオートメーションQAではクラッシュ率とかはやってない
    • それをやっているんだったら、自動化とか、そういう勉強をしている
  • ヤマン

    • 捉え方によっては「自分がやっていることが正義」のように聞こえる
    • 対外的にどうやって自動化を説明している?
  • 菅原

    • 考えたことがない
  • 柿崎

    • あのさー
    • メルカリさんはスクラムして、お客さんに価値のある取り組みをやっているはず
    • テストの生産性をテストだけで考えるのはおかしい
    • テスト単体だけでなく、例えばお客さんに刺さる機能を作り上げるのならば、できるだけ多くのことを挑戦しているはず
    • ベロシティをやっていないの?
  • 菅原

    • 今のところではやっていない
    • プロジェクト開発の生産性というか、より無駄なことをしないような取り組みはしている
    • 一般な開発だとプロデューサーとかいろいろな人がかかるが、アサインするということが無駄だなと思っている
  • 柿崎

    • そうじゃなくて、お客さんにどれだけの価値を提供しているか考えるべき
    • アサインは直接的ではない
    • それでチームのアウトプットを考えないと

お題3まとめ

  • ヤマン
    • 続きは第二部や懇親会ということで…
    • まとめると「腹落ち」と「シンプルな指標にすること」は大事だなと思った

感想

  • 立ち上げるにしても転職するにしても、自分なりのQAとしての動き方を持つことは大事だなと感じた
    • それも1つに固執するのではなく、その状況を見ながら。
  • さらにそれを哲学としてではなく、他の人にも説明できることも大事だなと思った。