パネルディスカッション「QAの過去から現在・現在から未来」(後編) #DeNA_QA_Night

前編はこちら

nihonbuson.hatenadiary.jp

目次

登壇者

奈良 隆正(以下、奈良さん)

西 康晴(以下、にしさん)

河野 哲也(以下、河野さん)

講演資料

www.slideshare.net

※p8以降

昔からあるツールで今でも使い物になりそうなものについて

f:id:nihonbuson:20190310002908p:plain
今回の講演資料8ページより

  • 河野さん

    • 奈良さんはなぜすべて○を?
  • 奈良さん

    • みんな口が悪いね?
    • どれも参考にはなると思う
      • ただし、具体的なプラクティスを教える人がいない
      • なので、本を読んでほしい
  • 河野さん

    • 基礎知識として知っておけということですね

品質管理手法

  • 河野さん

    • にしさんは◎/×という付け方になっていますが、どういう意味ですか?
  • にしさん

    • 何も考えずにランダムにつけたんですけど(笑)
    • 考え方は知っておいたほうが良いが、実際に使う機会に出くわさない
      • 大量生産をする、統計を使う場合のみ有効
        • 本当の統計を使ってないので機械学習で役に立たない
  • 河野さん

    • コンサルが来たときにだまされないようにするため○にした
  • 奈良さん

    • すごい納得

品質管理図

f:id:nihonbuson:20190307110514p:plain
奈良さんの講演資料24ページより

  • 河野さん

    • にしさんは×にしてますが、その理由は?
  • にしさん

    • いつ何がリリースされて、いつ何がテストされていて…みたいなのもわからない状況で使っても意味がないのでは?
  • 河野さん

    • 10日間とか、リリースごとで使うと良い
    • 3日間とかだと意味がない
  • にしさん

    • スプリントの性質による
    • 他のサービスと横並びして比較するのは意味がない
  • 奈良さん

    • Microsoftのツール(Microsoft Project)を使えば簡単に作れるのでは?
    • 会場の皆さんは、この絵を見て、瞬間的に見てテストがどこまでできているのか答えられるの?
  • 河野さん

    • 普段書いている人?少ないですね。
  • 奈良さん

    • テストが終わりそうかという質問にどこまで答えられるのか?
    • 明日デートいけないですよ?
  • にしさん

    • どんな場合でもデートできる状況を作るのが大切じゃないの?
  • 奈良さん

    • 説明できる状況ならどんな方法を使っても良いと思う

V&V

  • 河野さん

    • にしさんはV&Vが◎の理由は?
  • にしさん

    • これが仕事ですから
    • 「V&Vが大事なんです!」というだけの人は信用できない
    • 全体を考えてやっているならすごい大事
  • 河野さん

    • 実際の状況、具体論で考えられるのが大事
  • 奈良さん

    • レビューはなんでやるの?と言ったときに、V&Vの考え方が分からなければ上手くできない
    • 似たような考え方でV字モデルがあるが、開発でもちゃんと知るべき。
    • 開発者にとっておまけではなく、コードを書くのと同じように知るべき。
  • にしさん

    • 自動化できてるところ、自動化できてないところ、これからしたいところ、人間が考えるべきところをちゃんと区分けするため
    • そうしないとSETがTDDからCIで組み込んだあとに、SETが孤立するかQAが孤立する

探針と信頼度成長モデル

f:id:nihonbuson:20190307110635p:plain
奈良さんの講演資料27ページより

  • 河野さん

    • 探針と信頼度成長モデルは知っておいた方が良い?
  • 奈良さん

    • 今だと、こういう管理をしなくて良いのですか?
    • 私の場合は「テストがいつ終わるのか」を知るために使っていた
    • 組織の特性などによって適用する曲線は使い分けた
    • 最近のテストってこうなってるのかな?
  • 河野さん

    • なってないですね
  • 奈良さん

    • 期間が短いからできない感じ?
  • 河野さん

    • 期間が3ヶ月とかだと役立つかもしれないが、今だとブレブレになる
    • 探針もそう
    • 私が○にしている理由は、これもコンサルに騙されやすいものだから
    • にしさんは、信頼度成長曲線について言いたいことは?
  • にしさん

    • 信頼度成長曲線の言葉を少しでも言うぐらいなら今日の質問の投稿をするべき

LOC・FPベースの品質マネジメント

  • 奈良さん

    • ソフトウェアの目方をどうやって測るかで必要なのでは?
  • 河野さん

    • 計測してる組織が少ない
    • 開発者が嫌がるのでは
    • コード行数をマネジメントで使っている人?一部いますね
  • にしさん

    • 自分の書いたコードを行数で測るのはちょっと…
  • 奈良さん

    • 今そういうことをやるのではないのかもしれないが、必要だと思う
  • にしさん

    • 他のプロジェクトと比べたいんですよね?
  • 奈良さん

    • 上司から求められているから
  • にしさん

    • どんなテストするかによって出方は変わるはず
    • LOCとかではなく、「うん、うちらはちゃんとテストできてるね」とみんなで納得できるようにするほうが大事
  • 奈良さん

    • いや、上司との説得で使う必要がある
  • 河野さん

    • 他プロジェクトではなく、自分のプロジェクトの比較で使うことはあるか?
  • 奈良さん

    • この結果のみを使って信じるのは間違い
  • にしさん

    • 他に測る指標があるのでは?
      • Unitテストがあるかどうか
      • Unitテストはあるけどコードをなぞっているだけ
    • コードの規模ではないと思う
  • 奈良さん

    • 皆さんCMMをご存知ですよね?
  • 河野さん

    • いや、知らない人が多いですよ
  • 奈良さん

    • CMMIの中でも、未だに「必要だ。これがないと管理できない」と書いてある
  • 河野さん

    • なんか測ったほうが良いということですかね

メトリクス

  • 河野さん

    • メトリクスはどうですか?
  • にしさん

    • 「ISOをそのまま使えば良い」という捉え方だとまずいけど…
    • GQMにおける測り方のデザイン、把握のデザインは役に立つ
  • 河野さん

    • データに基づく議論が少ないと思う
    • もっと知ろうよ、という意味で○
    • やたらめったら取ろうよ、ではない
    • GQMはフレームワークとして美しいが、非常に難しい
  • にしさん

    • 開発者よりもっと頭を使わないと品質は良くならないよね
  • 河野さん

    • 大学の先生が言うと説得力がありそうですね
  • 奈良さん

    • 上司が取っているから○にした
    • 取っている理由が分かってない人が多い
      • だったら自分でメトリクスを取れば良いじゃない
      • その参考になるのがメトリクス
    • 作業でメトリクスを取っている仕事は辞めちゃえば良いのでは?
  • 河野さん

    • 日々の業務で、意味がない、ちゃんと考えたほうが良いと気付く機会が無いのでは
  • 奈良さん

    • みんな物理的根拠がない状態で働いている
    • 文句を言うなら自分で考えれば?
      • なんかにしさんの隣に座ると口が悪くなるな…

ソフトウェア工学

  • にしさん

  • 河野さん

    • QAの人が業務ですぐに使えるのか怪しいので◎ではなく○にした
  • 奈良さん

    • 私はソフトウェアを開発して飯を食っている
    • どんな仕事をしたら飯が食える?コードを書いたら?
    • コードを書く以外にいろいろある。
      • 見積もり、テストの管理などのその1つ
    • そういうことができない人がソフトウェア開発をしていると言ってほしくない
    • そのためには、ソフトウェア工学を勉強してほしい
  • 河野さん

    • やり始めると噛みごたえのある勉強にはなる
    • 進めるなら輪読でやればよいのでは
  • にしさん

    • 本当は大学でやるべきですよね
      • 自動車工学知らない人がつくった自動車
      • 航空工学知らない人がつくった飛行機
      • 機械学習知らない人がつくった自動運転
      • 乗りたくないよね?
    • だからソフトウェアを開発しているならソフトウェア工学を勉強しよう
  • 河野さん

    • 電通大で夜間に有料講義でやらないの?
  • にしさん

    • 夜働きたくないじゃん
    • トップエスイーという選択肢もある
    • あとは自社内で勉強するのが良い
  • 奈良さん

    • PSP(Personal Software Process)をやると良い
    • …なんか意見が合わないね

会場からの質問(1)

  • クソCHAPDコントロールな感じで仕事が面白くないのですが、ここから抜け出すために何を初めにするべきか。
  • またマネジメント層に「クソCHAPDコントロール」にはあまり意味がないことを分かってもらうためにはどういえばいいでしょうか。

  • にしさん

    • 「スキルを付けて会社を辞めろ」が正解です
    • 「会社に残ってここから抜け出す」は結構な難問
    • 自分の周りのチームで「自分のやり方まずいよね」と言って、こっそりやって、上の人には「ウォーターフォールやってます!」と言いつつおこなって、品質が良くなったら隣のチームに広げていくやり方が良い
  • 河野さん

    • 組織を変えるのは難しいですよね?
  • にしさん

    • QAは横断組織であることが多いので、一人の開発者が変えるよりは楽
    • 今どきのクラウドな会社の場合、創業者で技術理解のある経営陣がいる時は変えやすいはず
  • 河野さん

    • 社内政治をするということですよね?
    • ちなみに、こういう努力をすることで転職アピールにも繋がる
  • にしさん

    • なんか、辞めそうですよ?大丈夫?
  • 河野さん

    • 転職アピールは置いといたとしても、こういう話をできない(仲間を作っていけない)人は一緒に働けない
  • 奈良さん

    • こういうイベントを一人で来ても意味がない
      • 「来るんだったら3人でおいで」と言ったりしている
    • どうやって聞いた話を実現するの?
    • 複数で来て、裏で組んでこっそりやる
  • にしさん

    • 1人でしか来れない人は割り切って、自分の会社の中で帰ることとして割り切って、自分のチームで試してみて「見てみて!楽しいよ!」と伝える
      • 会社内でアピールし、社外にもアピールする
    • だんだん分かってきてくれる人がいる
    • 絶対「このクソ会社!」と思っている人がいる
      • その人を探すためにもやる
    • 「そんなことやっても意味ないよ」という人が実は理解者になる可能性のある人
      • その人の愚痴を聞いてみる
      • 愚痴をずっと聞いて、「そんなことばっかり言ってもしょうがないよね」という発言があったら、「こんなことをしようと思っているんですけど」と話す
    • 押し付けないこと、傾聴することが大事

会場からの質問(2)

  • 次の時代のQAが身につけるべきスキルとはなんですか?

  • 奈良さん

    • 質問を見た瞬間に頭をかかえた
  • にしさん

    • 個々で話しているQAはソフトウェアのQA
    • 実現しているのはサービス
    • じゃあ、「サービスの品質とは?」を考える
      • 自動運転の制度ではなく、自動運転が及ぼす影響とか
      • 高齢化、過疎化対策としてサービスを提供しようとしている会社もある
      • 自分のサービスは社会の解決をできているのか評価する必要がある
    • 身につけるべき範囲が広がっていっている
    • 開発者よりも先取りして学んで、もしも自分が適用するなら…を考え続ける必要がある
  • 奈良さん

    • 技術を磨くときに、世の中に通用する技術を磨いてほしい
      • 自分の会社だけで役立つ技術は、なんの意味もない
    • グローバルなり、スタンダードと比較して通用する技術を学ぶべき
  • にしさん

    • 外部のMeetupで話をするのも大事
  • 河野さん

    • 議論するのは大事ですよね
    • SSでも議論をするので興味がある人は来てください
    • 旅行するついでに参加してみてください

パネルディスカッション「QAの過去から現在・現在から未来」(前編) #DeNA_QA_Night

タイトルに「パネルディスカッション」と書いておきながら、実際のパネルディスカッションは後編になります。

後編はこちら

目次

イントロダクション(河野さんの発表)

発表資料

www.slideshare.net

※p7まで

今回のパネルディスカッションの狙い

  • 温故知新がイベントのテーマ
    • 前回の松尾谷さんの発表もテーマは同じ

背景

皆さんが困っていること
  • 品質保証をマネジメントする仕組みと仕掛け(大きな話)
  • ワークさせる固有の技術の理解・習得(小さな話)
    • 小さな話だけやれば良いのではなく、大きな話もする必要がある
  • チーム構築
    • チームの仕組み
    • 品質確保の仕組み
QAの仕組み・仕掛けや道具
  • テストのやり方、ドキュメント体系などを習得すればよいのでは?

過去の経験を活用する

  • 奈良さんの講演資料
  • 奈良さんの書籍
  • これらの内容をベースに話し合いを行う
  • そのまま使ってよいのか?
    • コンテキストが違う
  • どちらかというと過去の話がベースになっている
    • サービス要求
      • 昔…信頼性が何よりも重要
      • 今…スピードも大事
    • QAと開発の形
      • 昔…監査・分業の存在
      • 今…協業の形
    • テスト方法
    • 昔…スクリプトテスト
      • 今…探索的テスト

にしさんへの講演リクエス

  • 過去から現在について
  • 現在から未来について

オープニングスピーチ(にしさんの発表)

発表資料

www.slideshare.net

自己紹介

  • いろんなことやってます
    • テスト方面
    • AIプロダクト(ソフトもシステムもデバイスもサービスも含む)のQA

ソフトウェアTQM

  • 1980年代からソフトウェアの品質は行われていた
  • 汎用機の頃のソフトウェア開発ではうまく作用した
    • 日立などは自社で内製していたりした
    • ネオダマの頃になってどうも怪しくなってきた
  • 奈良さんは汎用機の頃にうまくやっていた一人

かなり昔(汎用機時代、アトランティス時代)

特徴
  • 正社員が内製もしくは子会社の人たちで開発していた
  • ほとんどが紙だった
  • 動作環境も自社製で揃えられた
  • エンジニア意識の強い人が集まった
どんな開発・QAだったか
  • マシンパワーが高価のため、人間がガンガン改善した
    • 結果が出てくるまで3日ぐらいかかる時代
    • 紙の上で考えざるを得ない
      • 奈良さん「古すぎる話をしてるよ!」
  • 改善するとみんなが儲かる嬉しい状態
  • 全体としての問題が分かっていた
  • 内製なので、組織能力を積極的に高めていた
    • 教育も積極的に行っていた
  • 人間らしい仕事をしていた
  • 奈良さんなどの人に頼っていた時代

ちょっと昔(プロジェクト時代、奴隷時代)

特徴
  • 多重下請け構造に基づいたプロジェクト制だった
  • コマンドアンドコントロールの徹底を目指していた
  • 電子化をしたが、Excel方眼紙なのでメリットがない
    • 規模は大きいが探せない状態
  • 制約によってなんとかできると思っていた
  • サラリーマンエンジニアが多かった
    • エンジニアが雇用の受け皿になっていた
      • コミュ障の大学生は「それならソフトハウスに行きなさい」と就職課の職員に言われる
  • わずか10年前ぐらいまでこういう状態だった
どんな開発・QAだったか
  • 不具合を直すのにもお金がもらえる
  • 人間を取り替えのきく機械のように扱っていた
  • ソフトウェアのQAについてWebで探すと、この時代のQAの方法がヒットすることが多い
    • 結果として、解決できると勘違いしてしまう恐れがある
  • オープンソースの検証を自分たちで力技でやってしまおう、という時代

現在(クラウド時代)

特徴
  • 内製化が進んできている
  • GAFAMのやり方を学ぼうとする企業が多い
  • ソフトウェアが好きな人を集めやすい
どんな開発・QAなのか
  • アトランティス時代と似ている
    • ただし、ちゃんと考えてできているかは分からない
  • 中身をちゃんと理解して納得して作れている?
  • カイゼンのサイクルを短くすることができている?
  • 「QAはリソースが足りないので対応できません」と言ってないですか?
  • 組織能力を高めることができている?
    • スキルの高い人が流動化しているので組織能力を貯めにくいという側面もある

我々はどこに向かえばよいのか?

ちょっと昔(プロジェクト時代)と同じQAをすると概ね失敗する
  • クソCHAPDコントロールによる形骸化
    • Criteria-based control (基準値に従え!)
    • Human resource-based control (人力でなんとかしろ!)
    • Authorization-based control (誰の責任だ!)
    • Process-based control (マニュアル化しろ!)
    • Document-based control (文書!文書!文書!)
アトランティス時代と同じQAをしても的外れ・時代遅れになるだけ
  • 豊富なマシンパワー
  • 安価でリッチな開発・運用環境
昔ながらの良い考え方は取り入れる
  • 現在の状態に合わせて進化させる

自分たちで進化させよう

優れた組織イニシアティブの創出や醸成
  • 経営トップから品質を考えていける組織にする
    • 以下のような発言を経営陣がしていませんか?
      • 早く作れ!
      • リリースはいつだー!
      • 利益がー!
  • 納得感を共感して進めていく
  • 質の高いアウトプットを出すことを正義にしていく
  • QA部門は全員で品質を高める仕組み・文化を進めるように働きかける
    • SETと違う意味で、みんなで品質を上げていく
  • 品質はバグがなくなるだけでなく、人間らしい仕事にしていくことも大事
品質保証戦略を作る
  • 品質保証のアーキテクチャを作る
  • ありありと改善が分かる部分から行っていく
    • QAは主語がでかくしがち
QMSを構築する
  • 品質を上げることを嬉しくなる、評価されるQMSを作る
    • 「QMS?ISO9000でしょ?」という人は無視しよう
  • QMSによって開発の在り方そのものを進化させていく

よくやりがちなワナに気をつける

  • ラクティスファーストを行わない
  • 品質保証戦略のコピペをしない
    • Agileだから〜
    • 他社でやっていたから〜
  • 局所的で循環しない施策はデザインしない
    • クオリティーゲートを言っている人は奴隷時代の人
  • 深く考えずに協力会社に丸投げをしない

まとめ

  • 品質保証は組織を賢くするために行う仕事
  • ある意味経営と同じようなことを考える必要がある

後編(パネルディスカッション編)はこちら

nihonbuson.hatenadiary.jp

テストエンジニアはどのような思考でペアプロ・モブプロに参加しているのか #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

qiita.com

note.mu

panmania.hatenadiary.com

ma-garin.hatenablog.jp

www.aster.or.jp

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

はじめに

この記事は謎の集団 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の人が作ったテスト設計がすべて正しい」と考えている開発者もいるみたいなので…