※以下の記事は研修の内容を伝えることを意図したものではなく個人的な感想と学んだことを記載したものです。

Agile Testing for the Whole Team 研修

3/1~3/3の3日間で、アギレルゴコンサルティング主催のオンライン研修「Agile Testing for the Whole Team」に参加してきた。

www.jp.agilergo.com

講師は Janet Gregory（@janetgregoryca）さん。『実践アジャイルテスト』の著者の一人で、最近では『Agile Testing Condensed』という書籍も執筆している（こちらについても既にブロッコリーさん（id:nihonbuson）による邦訳がある）。

実践アジャイルテストテスターとアジャイルチームのための実践ガイド (IT Architects' Archiveソフトウェア開発の実践)

作者:Janet Gregory,Lisa Crispin
発売日: 2009/11/28
メディア: 大型本

leanpub.com

また、Janet Gregory さんは先日開催された RSGT2021 でも基調講演の1つを務められていた。動画を以下に貼っておく。

RSGT2021 - Janet Gregory - What’s Testing Got to do with Quality?

研修の概要については、冒頭のアギレルゴコンサルティングのWebサイトの他、Agile Testing Fellow のWebサイトで研修概要のPDFファイルがダウンロードできる。

前置き

なぜ開発者である自分がこの研修に参加したか

~~会社がお金を出してくれ(ry~~

自分は、開発者の立場でアジャイルに関心を持って勉強してきて、前職時代から自分の仕事に学んだことを活かそうとしてきた。前職では自分の力不足もあってアジャイルのプラクティスを実践に投入できる機会は多くなかったが、現職のチームではイテレーション開発を採用し、ペアプロやCI、その他のアジャイルプラクティスを適用しながら仕事をしている。

しかし、テストという部分を見てみると、開発チームとQAチームとの関係は（決して険悪ではないが）密接とはいえず、「開発チームが作ったものをQAチームに回す」という流れになっている。バグによる手戻りが多くて困るということはそんなにないものの、仕様の把握とシステムが仕様通りに動いていることの確認という2点において、開発チームとQAチームが重複して仕事をしてしまっているなど、改善の余地があると感じていた。そういった背景もあり、冒頭で言及した書籍『Agile Testing Condensed』も、邦訳が出たときにすぐに買って読んでいた*1。

また、別の観点からは、TDDやDDDの方面からATDD・BDDにも関心があり、つい最近はきょんさん（id:kyon_mm）と東口さん（@hgsgtk）による雑談を聴いたりしていた。

ATDD再考 2021

そういうわけで、この研修の存在をTwitter経由で知って「面白そうだな、参加してみたいな」と思っていた（会社Slackのtimesチャンネルにも投げていた）ところ、ありがたいことに会社で声をかけてもらい、同僚の開発者・QAメンバー数名と一緒に参加することになった。

研修のフォーマットなど

このご時世なので、当然オンライン開催で、3日間8:00~12:00の合計12時間の研修だった。これとは別に、事前に資料と動画（研修後にみることを想定したおさらい編も含めて全部で5時間ほど）が配布されていて、座学になる部分は極力事前予習で済ませ、当日の研修の時間ではさまざまなグループワークを行うことに時間が割かれた。

講師は英語話者だが、日本語の通訳者がついており、Zoomの同時通訳機能を使って、参加者の方で聴きたい言語（英語 or 日本語）を選んで聴くことができるようになっていた。この通訳の方がすばらしく、通訳を待って話のスピードが遅くなるという体験はほぼしないで済んだ。また、アギレルゴコンサルティングの川口さん（id:wayaguchi）が共同トレーナーとして臨席されており、参加者からの質問に対して補足説明を加えるなどしてくださって理解の助けになった。

研修の内容について

「チーム全体」で品質を考える

タイトルに「Agile Testing for the Whole Team」にあるように、研修のコアメッセージは「品質のことをチーム全体で考えよう」というものだったと思う。ここでいうチームとは「デリバリーチーム」であり、役割としてはテスター、開発者に加え、プロダクトオーナーのようなビジネスサイドのメンバーも含まれている。このメッセージは研修を通じて一貫したもので、当日に行ったワークショップでもPO、開発者、テスターというそれぞれの観点に立って意見を出してみるとしばしば促された。

研修の主な受講者として想定されていたのはテスターであったと思われるが、テスターに対してもマインドセットの転換を要請していた。開発プロセスの最後にバグを見つけることにテスターの役割を限定せずに、「そもそもバグを作らないで済むようにする」ことなどを通じて、「ソフトウェアを成功裡にデリバリーする」ための行動をテスターに取るように求めていた。

当然、その裏返しとして、開発者に対しては、品質を作り込むことを強く求めていた。研修中に出た印象深い発言として、「テストをする気がなく、品質について考えようとしないプログラマーがいたら、『コーディングを止めろ！（"Stop coding!"）』と言ってやりなさい」というものがあった。これを含め、テスターをエンパワーするような発言が随所にあり、（自分はテスターではないが）参加していたテスターの人たちには非常に心強かったのではないだろうか。

ワークショップから

先述の通り、研修当日（3日間）の時間は多くがワークショップに割かれた。かなりたくさんのワークショップを行ったので、いちいち内容に言及することは避けるが、ワークショップを通じて印象に残っているのは、「仕様について勝手に自分で判断せずに質問する、質問することで共通理解を形成する」ことの重要性である。自分はかなり「理解力」的なものを尊んでいて、「一を聞いて十を知る」的なあり方に憧れてしまうのだが、チームでものづくりをしているときには自分の頭で勝手に補うことが非常に危険であると実感することができた。

また、今回の研修のワークショップの多くは、ストーリーにイテレーションで取り組む前の段階にフォーカスしたものだった。講師の言い方では「ストーリー準備ワークショップ（story readiness workshop）」、スクラム的な言い方をすればバックログリファインメントで有効活用できそうなプラクティスを多く学ぶことができた。研修の趣旨からすると、この段階でチーム全体での共通認識の形成が、（バグの混入など）ソフトウェアのデリバリーを妨げる事象の発生の防止に重要ということなのだが、個人的にはストーリーを小さくスライスする具体的な方法が今まで良くわかっていなかったので大きな学びだった*2。

ATDD, BDD, SBE

個人的には一番関心があった部分。『実践テスト駆動開発』（通称GOOS）は読んだが、実務ではATDDは取り入れておらず、BDD（Behavior Driven Development）やSBE（Specification by Example）は概要を知っている程度で本は未読だった。

講師はATDD（Acceptance Test Driven Development）が最も包括的な用語だとして説明していた。ATDDといえばGOOSで、GOOSは技術的な側面にフォーカスした本なので、自分の理解も（『テスト駆動開発』付録Cの表現を借りると）「外側のループ」をTDDに足したものという捉え方をしていたのだが、この研修では自動化の前段階で、チーム全体で共通認識を作り、ストーリーのスコープを把握するためのものとしての側面を重視していた。

イテレーションで実際にストーリーの実装（テスト&コード）に取り組む前に、ATをチーム全体で考える。ATを記述するフォーマットとしては、BDDスタイル（Given/When/Then）や、表形式（Tabular）など複数の書き方があるが、Given/When/Thenは自然言語で記述するのでわかりやすく、表形式では具体的な値を使って考えるのでより踏み込んだ議論を促してくれるということだった。これは実際にワークショップで体験したが、確かに表形式で記述しようとすると具体的な入出力をイメージしやすく疑問が出やすかった。

その他、研修で言及のあったもの

上記のトピックの他に、一部を挙げると以下のようなトピックが取り上げられた。

テスト自動化ピラミッド
- なるべく下にテストを押し込んでいく
- それぞれのテストがどのレイヤでできそうかを考え、マッピングしてみる（もちろんチーム全体で！）
- 真ん中のレイヤ（API・サービス層）のテストはビジネスサイドの人も読めるようにする（Living Documentation！）
アジャイルテストの四象限
- 第四象限おそろかにしがち問題
- 上半分のテストはビジネスサイドの人も読める
バグトラッキングシステムの必要性
- 新規フィーチャーの実装では、ゼロトレランス方式*3を採用するため不要
- レガシーシステムの場合、本番環境で発生する不具合などの傾向を分析することが更なるバグの防止のために重要なのでしっかりとバグは管理するべき
テスト計画
- 長々と書いてもそれぞれの人が読みたいところしか読まないので簡潔に
- テストマトリックスはとても役立ちそうだなと思った
- 参考：アジャイルテストでの計画・管理のツール：Test MatrixとTest Mindmap - 千里霧中

まとめ的な感想

今回の研修を通じた最も大きな学びは「ストーリーをいかにReadyな状態にするか」に関わる具体的なプラクティスだった。ストーリーを十分に小さくしてReadyな状態にすることは、短いタイムボックスでインクリメンタルにソフトウェアを開発してフィードバックを早く得ることを旨とするアジャイルにとって極めて重要な営みであるはずだが、自分はあまりその部分を勉強してこられていなかったので、今回の研修を通じてようやく「ああ、こうやるのか！」と得心がいった部分が多かった。ただ、うまくやらないとストーリーをReadyにする営みにかなり多くの時間をかけてしまいそうで、そこは難しいところだと感じた。

他の感想としては、研修の語り口からすると、テスターを主な参加者層として想定しているようだったが、プロダクトオーナーや開発者にも役立つことの多い研修だったと感じる。「エラーをみつけるつもりでプログラムを実行する過程」としてのテストの技法についてはあまり言及がなかった分、自分のような開発者ロールで働いていて、テストに関する知識がそこまでない人間にもとっつきやすかった（裏を返せばその部分に関する学びは少なかった）。ただ、アジャイルという考え方についての説明や、TDDやCI/CDといった技術的プラクティスについての説明は少なかった（ある程度わかっている前提だった）ので、一定以上のアジャイルについての前提知識は持っていた方が理解しやすい研修だったのではないだろうか。

今回、同僚の開発者やQAメンバーと一緒に参加していたので、研修が終わった後、今後の実務にどうやって生かしていこうかという対話を始めている。研修で教わった内容をそのまま適用するのは難しいが、目指す一つの方向としてモデルを持てたこと、組織の課題を語るための共通言語を得られたことは価値があると思っている。この記事を読んで、「次回開催されたら参加したいな」と思っている人がいれば、ぜひチームのメンバーみんな（できればプロダクトオーナーも！）で参加すると良いと思う。

おまけ

Agile Testing Fellowshipについて

なお、この研修の副賞的なものとして、Agile Testing Fellowship のメンバーになることができるというものがある。研修受講後にオンラインでのアセスメントを受験して、合格すれば会員として迎え入れられるというシステムだ。自分も研修が終了したその日に受験し、無事に合格した。合格すると、PDFの会員証がもらえるほか、会員で構成されている Slack workspace に参加することができる（名称からして「認定なんちゃらer」ではないし、むしろこちらのコミュニティでの交流・相互支援に重きがあるようだ）。

なお、この Agile Testing Fellowship への入会は、研修を受けなくても可能で、120ドルを支払うことでアセスメントを受験し、入会することができる。『Agile Testing Condensed』の邦訳を手掛けられたブロッコリーさんはこちらの方式で昨年の時点で入会されている。

nihonbuson.hatenadiary.jp