Scrum Fest Osaka @Online の盛り上がりがスゴい! #scrumosaka

先日、Scrum Fest Osakaがオンラインで行われることが発表されました。

www.scrumosaka.org

今回のイベントの特徴として約20個のマルチトラックが用意されています!

オンラインイベントで発表場所の制限が無いからこそ実現したのだと思ってます。

各トラックのkeynoteも豪華!まだ公開されてないけど、楽しみで仕方ないです!

さらに今回は各トラックで色々と実験的なことをやると思うので、色々とフェスな感じで盛り上がるのでは?と期待しています。

私も「新潟トラック」で運営と発表をする予定です。*1

新潟トラックのkeynoteは既に川口さんのツイートで公開されているので、ここでも紹介!

keynoteはなんと、書籍『実践アジャイルテスト』『More Agile Testing』そして『Agile Testing Condensed』を書いたJanet&Lisa!

2人がAgileTD2011で発表した内容を放映したいと考えています。*2

その他、新潟トラックでは主にAgile Testingを中心とした構成になっています。

興味がある方は、ぜひScrum Fest Osakaに参加登録して新潟トラックに来てくださいー!参加登録は公式ページからお願いします!

*1:私自身は新潟に行ったこともないけど、縁あって新潟トラックの運営になりました!

*2:もちろん、既に2人には許可を貰ってます

受け入れ基準の設定時などに役立つプラクティス「Example Mapping」を翻訳したので紹介します

はじめに(Example Mappingを紹介するに至った背景)

このブログで何回かお伝えしたように、先日『Agile Testing Condensed』の日本語翻訳本を出版しました。

leanpub.com

この書籍の中で、実例マッピング(Example Mapping)が紹介されています。

このプラクティスは大変素晴らしいものだと感じているのですが、残念ながら日本ではあまり知られていません。また、書籍の中では軽く紹介している状態です。

そこで、プラクティスの詳細の説明をするべきだと感じ、実例マッピングの記事の著者であるMattにも許可をもらい、英文を翻訳する形で紹介します。

なお、原文のページはこちらです。

cucumber.io

これ以降は元記事を翻訳したものになります。ただし注釈部分は、訳した時に必要だと感じた補足説明なので、元記事にはありません。


受け入れ基準設定時の課題感

ユーザーストーリーを開発が取り込む前に、受け入れ基準を明確にして確認するための会話をすることが重要です。

バックログリファインメントやプランニングポーカーセッションの時に行うチームもいます。他にも、スリーアミーゴス*1が参加する仕様ミーティングや仕様ワークショップディスカバリーワークショップなどを行っているチームもいます。

この会話を何と呼ぼうと、多くのチームが難しいと感じています。その結果、構造化されておらず、時間がかかりすぎて退屈になり、定期的や一貫して行われないか、あるいは完全にあきらめてしまうかもしれません。

私はこの会話を短く、強力で生産的にするためのシンプルでローテクな方法*2を発見しました。私はこれを実例マッピングと呼んでいます。

実例マッピングのやり方

具体的な例を用いることは、問題領域を探索するのに非常に有効な方法であり、受け入れテストのための素晴らしい基礎となります。しかし、これらの例について議論していると、会話の中では他の話題も出てきますが、それらの話題も把握する価値があります。

  • 多数の例を要約するルール、またはストーリーのスコープ(範囲)に関するその他の合意済みの制約を表現するルール。
  • 会話に参加している誰も、何が適切なアウトカム(成果)なのかを知らないシナリオについての疑問点。 もしくは、進めるにあたって私たちが置いている仮定。
  • 私たちが発見またはスライスしたが、スコープ外に延期した新しいユーザーストーリー。

実例マッピングでは、4色のインデックスカード(付箋)*3といくつかのペンを使って、会話が展開するときに発生するこれらのさまざまな情報を捕まえます。 私たちは会話をしながら、それらの情報を付箋に記載し、マップに配置します。

f:id:nihonbuson:20200304144940p:plain

まず、議論中のストーリーを黄色の付箋に書き、テーブルの一番上に配置します。

次に、それぞれの受け入れ基準または既に分かっているルールを青い付箋に書き込み、それらを黄色い付箋の下に配置します。

それぞれのルールについて、ルールを説明するために1つ以上の例が必要になるかもしれません。 私たちはそれらを緑の付箋に書き、それらを関連するルール(青い付箋)の下に配置します。

これらの例を議論しているうちに、参加者全員が答えられない疑問点が出てくるかもしれません。 そのような疑問点を赤い付箋に記録し、会話を続けます。

ストーリーの範囲が明確であるとチームが納得するまで、または時間切れになるまで続けます。

以上です。簡単ですね!

即座のフィードバック

会話の流れに合わせて、目の前のテーブルの上に視覚的に表現されたものを素早く作ることで、ストーリーに対する現在の理解度を反映させることができます。

  • テーブルが赤い付箋(疑問点)だらけになってしまった場合は、このストーリーについて学ぶべきことがまだたくさんあることを示します。
  • テーブルが青い付箋(ルール)だらけになってしまった場合は、このストーリーが大きくて複雑であることを示します。 おそらく、このストーリーは分割できるのではないでしょうか? 別の黄色の付箋(ストーリー)に記載して、分割したストーリーをバックログに入れます。
  • 1つのルールに対して、多くの緑の付箋(例)がある場合、ルールが複雑すぎるかもしれません。 複数のルールがあって、別々に分ける必要があるのではないでしょうか?

例が全く必要ないほど明白なルールもあることに気づくでしょう。 会話をしていると、誰もがルールを理解していることは明らかです。 すごい! BDDに洗脳されたオートマトンのように無理に例を出さなくても*4、どんどん先に進めることができます。

タイムボックスの中で考える

少人数のアミーゴであれば、約25分でよく理解された十分なサイズのストーリーを作成できるはずです。

それができない場合、このやり方のコツをまだ得ていない(これは問題ありません)、ストーリーが大きすぎる(間違いなく問題あり)、またはまだ不確実性が大きすぎるかのいずれかです。 だとしたら、ストーリーを分割するか、製品担当者に持ち帰ってもらい、後日、別の実例マッピングセッションで再びそのストーリーを扱うまでの宿題としましょう。

Cucumberのプロジェクトでは、25分後に簡単な親指投票*5を使用して、ストーリーが開発に入る準備ができているかどうかを判断します。 いくつかの疑問点が残っている場合でも、あなたが進むにつれてそれらを解決できるほど十分に小さいと思うかもしれません。 グループでの決定をしてください。

利点

実例マッピングは、ストーリー内の最小の動作にズームインして注目するのに役立ちます。 マッピングすることにより、ルールを分解し、必要な動作の核心を見つけ、残りの部分は後回しにすることができます。 この程度の精査で、実例マッピングはフィルターのような役割を果たし、大きなストーリーがスプリントに入り込んだり、デモの3日前の土壇場でのサプライズで爆発するのを防ぐことができます。

また、時間を節約できるため、忙しい製品担当者のプロセスへの関心を維持するのにも役立ちます。

ツイート訳:私たちは今、2、3か月からアミーゴの時に実例マッピングを行っており、一連の時間を大幅に短縮しています!

多くのチームは、スリーアミーゴスがこのセッション中に受け入れテスト(例えばCucumberのシナリオ)を書き、誰かが正式なgherkin記法*6でシナリオをIDEに入力し、その間、プロジェクターの近くに座っているものと想定しています。 それに価値がある場合もありますが、一般的には良くない考えだと思います。 実は、会話の本当の目的がぶれてしまっているかもしれません。

人々がこの間違いを犯す理由は簡単です。この作業のわかりやすい目的は、いくつか事前定義された受け入れ基準を持つユーザーストーリーを取って、受け入れテストに変えることができそうな例を考え出すことだからです。

しかし、私が考える本当の目的とは、ストーリーが完成するためには何が必要なのか、共通の理解に達することです。 ローテクのままでいることで、この目的に向けてはるかに素早く進むことができます。

友人のエピソード

したがって、本格的な正式なGherkinシナリオを使用する代わりに、「友人のエピソード」の命名規則を使用して、おおまかな例のリストを作ってみてください。

f:id:nihonbuson:20200304145202p:plain

例えば:

  • 顧客が領収書を忘れた場合
  • 製品が破損していた場合
  • 製品が15日前に購入されていた場合

不確実性が潜んでいると、本能的にもっと具体的にしたいと思うことがあるでしょう。 しかし、まだGiven When Thenの厳格な構造に頼る必要はありません。

f:id:nihonbuson:20200418192611p:plain

結果(Then)が不明確な場合、例がなく、疑問点だけがある状態です。

「知らない」を知ること

このような会話がループするようになるのは、十分な情報がないためです。 おそらく誰かが会話に参加していないか、ユーザー調査やスパイクが必要かもしれません。

f:id:nihonbuson:20200418192740p:plain

適切なアウトカムについて全員に話してもらうのは避け、さっと疑問だけを捉え、先に進みます。 おめでとうございます!無知の無知(unknown unknown)*7から、無知の知(known unknown)*8に変えられました。 それは大きな進歩です。

多くの人々は、この実例マッピングの1つの側面だけで、彼らのディスカバリーワークショップがつまらなくとりとめのない状態から、きびきびとした生産的で心が通い合った状態に変わったと私に言います。

誰が参加するべきですか?

最低限必要なのは、開発者、テスター、製品担当者(スリーアミーゴス)です。 ただし、これは最低限のことです。 ぜひ、運用者、UX(ユーザーエクスペリエンス)の人々、または議論されているストーリーに関係のある人を招待してください。 新しい疑問を発見したり、会話中に疑問を決定に変えたりできる人は誰でも役に立ちます。

このテクニックを学んでいる間、誰かが正式にファシリテーターの役割を担ってくれると助かります。その人の仕事は、話していることがすべて付箋に記録されているかどうかを確認することです。 実例や疑問が部屋の中を飛び交います。今なにが話されているのかがわかるように、話題を捉えて記述するには訓練が必要です。

それで、いつGherkinを書くのですか?

この記事を見て混乱しないでください。Gherkinを一緒に書くことは、特にプロジェクトの初期には非常に価値があります。 そこでユビキタス言語を開発します。チームの全員が信じられる方法でシナリオを表現することが重要なのです。

しかし、そのように実例を表現するには、実例がスコープ内にあるかを判断し、その根底となるルールを明確にすることとは異なる思考モードが必要です。

かなり成熟したドメイン言語を使用して稼働しているチームの場合、私はよく製品担当者に実例マッピングのセッションで時間と労力を費やしてもらい、実際のGherkinの執筆は他の2人のアミーゴ(開発者とテスター)に任せます。 Gherkin記法での仕様の草案が作成されたら、製品担当者はフィードバックを提供します。

これは私がここまでに書いたやり方と同じでしょうか?

こうすることは、製品担当者の知識を他のアミーゴに伝達するのに、実例マッピングでの会話がどれほど効果的であったかをテストするチャンスです。

どのくらいの頻度でこれを行うべきですか?

製品担当者はたいてい忙しいです。 製品担当者が完全に注意を向けることができるようにこれらをスケジュールするようにして、製品担当者の時間を尊重してください。

いくつかのチームが実際に仕事をしているのを見た経験から私がオススメするのは、頻繁に実行することです。1日おきのリズムが良いです。 ストーリーを1つ選んで25分間だけ注意を払い、その後は仕事に戻ります。 大きなバッチでより多くのことをしようとすると、エネルギーを消耗するだけです。

しかし、私のチームは分散しています!

これについては革新的なハッキングをすでに見ました。Googleドキュメントをシェアすることで、箇条書きを使用する人もいれば、色付きのセルを含むスプレッドシートを使用して付箋を表現する人もいます。 マインドマップを使用することもできます。 重要なのは、すばやく簡単に操作できるようにして、会話に集中できるようにすることです。

最後のTips

実例マッピングを使用する前に、ルールとサンプルの違いを明確に理解することが重要です。 これを教えるための楽しいエクササイズがあり、今後の投稿で共有します。

この会話の全体的な目的は、まだ知らないことを発見することです。 だから、くだらない疑問はありません。 楽しんで、問題を実際に調べてください。

ルールによって、ストーリーをスライスするための自然な断層ができていることに気づくでしょう。 スライスするのをできるだけ先延ばしにして、快適にスライスできるまで待ちましょう。そうすれば問題の核心を解決することに集中できます。 後でもっと洗練された(そして複雑な)ストーリーを追加することができるでしょう。

Janet Gregory, Aslak Hellesøy, Seb Roseのこの投稿へのフィードバック、Theo Englandの忍耐力、そして投稿を後押ししてくれたTom Stuartに感謝します。

*1:【訳注】3つの立場、すなわち開発者、テスター、プロダクトオーナー(ディスカバリーチーム)が集まって、協調的に要件を確認すること。3人の仲良し友達という意味の言葉から。

*2:【訳注】コンピュータに入力しない方法

*3:【訳注】インデックスカードは、図書館の蔵書リストなどを記載するカードです。アジャイルでは一般的に使われるカードですが、日本では色付きのインデックスカードは高価なので、アジャイルの実務の現場では付箋を使うことが多いかと思います。紙のサイズは半分以下に小さくなります。本記事では、以下、カラーのインデックスカードを付箋と読み替えて表現します。お手元にインデックスカードがある方は、読み替えてください。

*4:【訳注】「明白なルールがあったとしても、機械的にGiven When Thenを出すことに時間を使う」ということを表現していると解釈しました

*5:【訳注】「親指を上に立てる(賛成)」「親指を下にする(反対)」「親指を横にする(どちらでもない)」で投票し、その多数決で決める方法

*6:【訳注】「Given」「When」「Then」「And」などを用いて、自然言語でテストシナリオを書くための記法。BDD(振る舞い駆動開発)でよく用いられる

*7:【訳注】「知らない」ことを知らなかった状態

*8:【訳注】「知らない」と知っている状態

テストに対する考え方「Testing Manifesto」を翻訳したので紹介します

はじめに(Testing Manifestoを紹介するに至った背景)

既にこのブログでお伝えしたように、先日『Agile Testing Condensed』の日本語翻訳本を出版しました。

この書籍の中で、テストマニフェスト(Testing Manifesto)が紹介されています。

アジャイルソフトウェア開発宣言(Agile Manifesto)を元ネタにして作ったものだと思います。

この考え方は書籍を購入していない人にもぜひ知ってほしいと感じているので、この記事でも紹介することにしました。なお、記事に載せることについては、この画像の作者であるKarenSamにメールを送り許諾を得た上で掲載しています。*1

テストマニフェスト

翻訳した画像はこちらです。*2

f:id:nihonbuson:20200418161646p:plain

オリジナルの画像等はこちらにあります。

www.growingagile.co.za

また、画像だけでなく文章も残しておきます。

私たちは下記を大切にします。

  1. 最後にテストする よりも ずっとテストし続ける

  2. バグの発見 よりも バグの防止

  3. 機能性をチェックする よりも チームが理解している価値をテストする

  4. システムを破壊する よりも 最高のシステムを構築する

  5. テスターの責任 よりも 品質に対するチームの責任

「開発者が実装してQAがテストする」という考え方とは異なり、「どうやってチーム全体(開発者もQAも含む)でテストしていくのか」を大切にしていることが分かると思います。

宣伝

本記事ではテストマニフェストの概要のみを紹介しました。*3

ただ、このテストマニフェストの考え方を元に、どうやってテストを行なっていけば良いのかというエッセンスは、記事の最初にも紹介した『Agile Testing Condensed』にたくさん載っています!

もし、そのエッセンスに興味がある方は、ぜひ購入をご検討ください!

leanpub.com

また、テストマニフェストの画像を作成した2人は『Growing Agile: A Coach's Guide to Agile Testing』という書籍を出版しています。(こちらは未翻訳)

leanpub.com

この書籍では、アジャイルにおいてのテストのマインドセットを培うためのワークショップについて説明しています。

テストマニフェストの画像はこの書籍の中に書かれているワークが元になっています。

こちらも気になる人はぜひ一度確認してみてください!

*1:書籍『Agile Testing Condensed』では書籍の作者であるJanetとLisaに許可をもらった上で日本語訳をしましたが、ブログ記事に載せる際は話が別です。作者の許諾大事。

*2:辰巳さん、ゆもつよさん、kz_suzukiさん、あきやまさんに指摘をいただき、3番目の文章を修正しました。ご指摘いただきありがとうございました!書籍『Agile Testing Condensed』の画像も近日中に修正反映予定です。

*3:後日どこかで各項目について解説できるといいなぁ…。

『Agile Testing Condensed』を翻訳して出版しました!

2019年9月に出版された『Agile Testing Condensed』を日本語に翻訳してLeanpubにて出版しました!

表紙はこんな感じ。*1

f:id:nihonbuson:20200411005518p:plain

書籍紹介および購入はこちらから。

leanpub.com

現在は電子版のみ提供する形になっています。形式はpdf,epub,mobiの3種類です。

今回の記事では、この本がどんな内容なのか、そしてどんな想いで翻訳・出版に至ったかを書きます。

この本について

出版ページにも書いている紹介文を引用して紹介します。

Agile Testing Condensed』は、アジャイルにおいてどのような考えでテストを行うべきなのか簡潔に書かれています。JanetとLisaは、読者が理解できるように、20年間のアジャイルテストの経験から知識を抽出して表現しました。

  • テストとQAの専門家がアジャイルチームでどのように貢献するか
  • アジャイルサイクルにテスト活動をフィットさせるにはどうすればよいか
  • いつ、誰の責任で、様々なテスト活動を完了させるのか
  • テストエンジニアがアジャイル開発チームの他のメンバーと関わるにはどうすればよいか
  • デリバリーチームの全員が継続的なテストに参加するにはどうすればよいか
  • 視覚的なモデルを使ってテスト活動を計画するにはどうすればよいか
  • 短いイテレーションや継続的なデリバリーに対してテストが「追いつく」にはどうすればよいか
  • テストの有効性を評価し、継続的に改善するにはどうすればよいか
  • テスト自動化で牽引していくにはどうすればよいか

本書は、テストエンジニア、ソフトウェアデリバリーチームのメンバー、プロダクトチームのメンバー、ビジネスの利害関係者、管理者、経営者にとって必携の一冊です。

著者の最初の2冊である『Agile Testing』と『More Agile Testing』では、実際のアジャイルチームが直面しているテストの課題を詳細に例示し、それらがどのように解決されたかを説明しています。この『Agile Testing Condensed』は、多くの場合で有用であったアジャイルテストの実践の概要を紹介します。

また、今回の本でレビュアーになっていただいている川口さんも、自身のYoutubeチャンネルで紹介しています。そちらもあわせてご覧ください。

www.youtube.com

どんな想いで翻訳・出版に至ったか

想いについては、本書の訳者まえがきに書いた内容を、そのまま紹介します。

訳者まえがき*2

「私は本書籍の翻訳に携わることができて本当に嬉しい」

本書籍は、Agile Testingにおけるはじめの1冊として間違いなくオススメします。

著者のLisaとJanetにとってこの本は3冊目です。しかし、どの順番で読むべきか問われたら、間違いなく本書籍から読むように私なら伝えます。それは、本書籍が他の2冊と比べて優れている訳ではなく、はじめの1冊として狙って書かれた本だからです。

以前の2冊も素晴らしい本です。しかし、少しだけテストに興味を持っている人や、Agileにおける品質をなんとかしたい開発者や経営者にとってハードルが高い本でした。ちょっと読んでみるにはページ数が多すぎたのです。

一方、本書籍はタイトルの通り「condensed=濃縮された」本となっています。

しかし注意も必要です。本書籍では、テスト技術やAgileのプラクティスに関する話はそこまで詳しく書いていません。それは、必要な前提としてありつつも、濃縮した話の中でどうしても載せられなかったに過ぎません。

これを勘違いして、「プラクティスやテスト技術は別にいらなくてもAgile Testingはできる」と思い込まないようにしてください。既にプラクティスやテスト技術に関する素晴らしい書籍はいくつもあります。そのような書籍にも興味を持ってください。

冒頭の発言に戻ります。

「私は本書籍の翻訳に携わることができて本当に嬉しい」

なぜ、携わることができて嬉しいのか。それは、今までのTestingに関する書籍には無かった言葉がいっぱい詰まっているからです。

私は翻訳したことが嬉しかっただけではなく、翻訳中もすごく楽しめました。なぜなら、普段のAgile開発の中で行うべきと考えていたTesting活動が言語化したうえで書かれていたからです!

私はAgile開発の中でのテストに悩んでいる全ての方にこの書籍を届けたいと思い翻訳しました。そして今、このように日本語版の書籍という形になって本当に嬉しいです!

2019年9月に原書が公開されてから約半年で日本語版を出版するにあたり、多くの方に協力していただきました。

ドイツで行われたAgile Testing Days 2019に私と共に参加した伊藤潤平さん、永田敦さん、山口鉄平さん、川口恭伸さんには、イベントの時にAgile Testing Condensedの日本語訳プロジェクトを進めるきっかけをいただきました。このような素晴らしい機会をいただきありがとうございました。また、川口恭伸さんは、文章のレビューだけでなく、原著者とのやり取りについてもアドバイスをいただき、初の翻訳本出版の私にとってはとても心強かったです。本当にありがとうございました。

また、私の妻でもある香央里さんには、普段の生活のサポートだけでなく、拙い私の日本語訳に対して、より良い日本語訳を示してもらいました。ありがとうございました。

そして、この本はLeanpubで発行しています(第1版現在)。スピードを最優先して日本語訳の出版にこぎつけました。*3そのため、まだまだ日本語訳が拙い部分があるかもしれません。日々アップデートしていきたいと思います*4ので、気になる日本語がありましたら、風間宛までご連絡ください。

最後に、この書籍を読んで、Agile開発をしている方々のお役に立てば幸いです。

2020年4月 風間 裕也

さいごに

この本はAgile Testingについてのエッセンスがすごい詰まっており、(自分が翻訳者であるということは関係なく)ホントにホントにオススメの本です!

少しでもAgile Testingに興味がある方はぜひご購入の検討をお願いします!

*1:しれっと私の名前も載せています。

*2:ちなみに、このまえがきが翻訳っぽく見えるかもしれませんが、わざと書き直したのではなく、自分の想いをつらつらと書いていたらこんな文調になってしまいました…w

*3:今回の日本語訳はこの本初の翻訳本だそうです!

*4:一度購入していただくと、updateするたびに最新のファイルを無料で取得できます。

Developers Summit 2020話題賞を受賞しました! #DevSumi

この度、Developers Summitデブサミ) 2020で話題賞を受賞しました!

f:id:nihonbuson:20200323180934p:plain

私を含めた各賞の受賞コメントについては、記事をご覧ください。

codezine.jp

t_wadaさん、安田さん、ryuzeeさん、川口さんという、そうそうたるメンバーと一緒に受賞という、ちょっと恐れ多い感じもありますが、大変嬉しいです。

上記の記事にある受賞コメントに書ききれなかった想いを書きます。

公募に当選

今回、私は公募で申し込んだ結果、発表が決まりました。

懇親会の時にそーだいさんから聞いたのですが、それなりの倍率で、選ぶ方もその中から全体のバランスなども考慮していたとお聞きしました。

今回の発表、そして話題賞の受賞は、そもそも公募の中から選ばれなければ実現しなかったことなので、選考委員の方には本当に感謝しかないです。

開催の判断

今回の発表はCOVID-19の影響で、運営の方々としては開催するかどうかの瀬戸際だったのだと推測します。

デブサミ 2020の2日目である2月14日に、国内での感染をしたと思われる事例が都内で発生しました。

もしも1週間遅くなっていたら、おそらく開催中止を判断していたことでしょう。

色々と感染対策の準備をした上での開催というのは、本当に難しい判断だったと思います。

もちろん、既に警戒していた人もいるはずで、当日来場しなかった人も多かったと思われます。

当日の様子から感じた「テスト」への関心の高さ

そんな中、多くの方に来ていただき大変ありがたかったです!

その結果として、満員+立ち見での講演となりました。どうやら入場制限もかかっていたらしいです。

こんなにも「テスト」について関心を持っている人が多いのだなと、すごい感じました。

また、t_wadaさんの「質とスピード」の講演と一緒に話題賞に選ばれたということも、品質やテストに興味を持つ人が多くいるのかなと感じているところです。

参加者のフィードバック

多くの方からアンケートによるフィードバックをいただきました。

ある程度、満足度が高いという結果も頂き、すごい嬉しかったです!*1

今回はデブサミ 2020のテーマ「ともにつくる」を意識した発表にしており、当日は聴講者の皆さんも「ともに」参加して、一緒に発表を作り上げました。

そのため、当日参加された皆さんは、後からスライドを見ただけの方々以上の満足度を得られたのではないかと思ってます。

また、ありがたいことに多くの方から感想を頂いたのですが、その中でも以下のような意見が多かったです。*2

  • 開発者では気付けない部分に気付けた。
  • テストの勉強をしたいと思えるようになった。
  • テストの印象が変わった。

特に、「印象が変わった」と言ってもらえたのは、それだけ発表が響いたということなので、すごい嬉しいですね。

もっと多くの人に届けたい!

ただ、先ほど書いた通り、入場制限がかかっていたとのことなので、おそらく聞きたかった人全員に向けてお伝えできなかった悔しさもあるのは事実です…。

なので、この「ともにつくる」発表を今からでも体験したい!という方は是非ご連絡ください! 企業・コミュニティ関係なく、この発表を沢山の方々に届けて、少しでもテストについて理解を深めてもらえたら幸いです!

参考までに、今回の発表資料を貼っておきます。

speakerdeck.com

今回は話題賞に選んでいただき本当にありがとうございました!

*1:ただ、今回のデブサミ2020の発表者はすごいメンバーばかりで、皆さん平均的に満足度が高い!

*2:アンケート結果はそのまま頂けたのですが、どこまで赤裸々に公開して良いのか分からず…。とりあえずざっくりと共通した意見を抜き出して、独自の文章を作成しました。

デブサミの発表聴講諸注意→発表終了&資料公開しました

このブログでの告知が遅れましたが、2/13,14に行われるDevelopers Summit 2020でテストについての発表をします。

f:id:nihonbuson:20200131084318p:plain

event.shoeisha.jp

内容は、いつもの発表内容に少しだけ最新の内容を付け加えたものとなります。

開発系のイベントでの発表は昨年のJJUG 2019 Spring以来で緊張しますが、頑張ります!

諸注意

テストコードの書き方は話しません

セッションタイトル「テストエンジニアが教える テストコードを書き始める前に考えるべきテスト」で表されているように、私が話す内容はテストコードよりも前の話です。

テストコードの書き方の話はしませんので、そのような話を聞きたいと思っていた人は他のセッションに移ることをお勧めします。

ペアワークがあります

私の発表では、ただ聴講していただくだけではなく、隣の人とのペアワークがあります。

基本的にテストのことを何も知らなくても、何かしら話せるであろうお題を用意していますが、どうしても「隣の人と喋るのは無理!」という人がいましたら、他のセッションに移ることを強くお勧めします。

初めて私の発表を聞く人前提で進みます

上記にあるペアワークもそうですが、JJUG 2019 Springで私の発表を聞いたことがある人や今までに私の発表を聞いたことがある人は、同じネタが多くあるため、発表がつまらないかもしれません。

そのような方は、他のセッションに移ることを強くお勧めします。

(2020年2月13日更新)発表が終了しました!

発表資料を置いておきます。

speakerdeck.com

Agile Testing Fellowのメンバーになりました

先月末、Agile Testing Fellowのメンバーになりました。

Agile Testing Fellowとは

Agile Testing Fellowとは「実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects' Archiveソフトウェア開発の実践)」の作者であるLisaとJanetが設立したコミュニティです。

agiletestingfellow.com

まだ全世界で300名弱しかいませんが、Agile Testingについて、お互いに相談に乗る形で運営されているようです。

Agile Testing Fellowに入るためには

入会費を支払い、Agile Testingに関するテストをPassすることによってコミュニティの一員になることができます。

f:id:nihonbuson:20200203192129p:plain
証書の一部

まだ他に日本人がいないので、興味のある方はメンバーになってくれると個人的に嬉しいです。

そして、Agile Testing界隈をもっと盛り上げていきましょー!