レビュー時のアプローチを考えてみませんか? #jasstreview

今年もJaSST Reviewを開催します!

jasst.jp

今年のテーマは「レビュー対象へのアプローチ方法」です。

この「アプローチ」についてもう少し考えてみましょう。

アプローチとは何か?

weblio国語辞典には以下のように書かれています。

①ある目的のために人に近づくこと。親しくなろうとすること。

②学問・研究などの、対象に接近すること。また、接近のしかた。研究法。 「歴史的な観点から-する」

レビューについて言えば、「どのように問題点に近づいていくか」を考えることかなと思っています。「問題点に対してすぐに指摘できる」ではありません。

歯医者を例に考える

歯医者さんとのやり取りは、問題へのアプローチそのものだと思っています。

歯が痛くて歯科医院に行った時、歯科医院に着いてすぐに歯を抜くことはありません。

以下のようなプロセスを踏むと思います。

  1. 患者に現在どこが痛むのか聞く
  2. 全体的に歯を見て、どこに虫歯があるのか見つける
  3. 今後の方針を患者と相談して、治療する順番を決める(複数の虫歯があった場合)
  4. 歯のレントゲンを取り、虫歯が神経まで届いているのか確認する
  5. 患者の反応を見ながら虫歯の治療を行う

f:id:nihonbuson:20200722190236p:plain

これにより、32本の歯から徐々に対象の歯を絞っていき、虫歯の状態をだんだん明確にしています。

その際には患者とのコミュニケーションを取ることで、治療の優先順位も決定しています。

これはまさに問題(虫歯)に対して近づいていく(アプローチする)行動そのものです。

このアプローチでは、現在の歯のレントゲンというデータだけでなく、どの部分で患者が痛みを感じているのかなどの反応を見つつ、麻酔が必要かなどを判断していることが分かります。

レビューの場合に当てはめて考える

レビューの場合でも、たくさんのレビュー対象から問題がありそうな部分を絞っていき、問題点をだんだん明確にします。

もちろん、レビュー対象物だけでなく、レビュー対象物の作成者とコミュニケーションを取ることで、解決すべき問題点を見つけたり、優先的に伝えるべき内容を探っていきます。

ただし、歯科医院の場合と違い、どのようなアプローチで問題点を見つけるのか、レビュー対象物の作成者とどのような会話をするのかなどは定かではありません。

このJaSST Reviewというシンポジウムを通じて、レビュー対象へのアプローチ方法について考えていきたいと思っています。

JaSST Reviewでは事例募集をしています!

この「レビュー対象へのアプローチ方法」という話は、まだまだ未開拓の地だと感じています。その一方で、多くの現場ではレビューを行なっていると思います。

そこで、皆さんの現場で行なっている、レビュー対象へのアプローチ方法について事例募集をすることにしました!

締め切りは今月末となります。

参加者の方々と共有して、レビューについて改めて考えてみませんか?

「そんなに新しいことやってないし…」と思っている人へ

大丈夫です。この部分は未開拓の地なので、事例発表をする人なりの言葉で語ってもらえれば、それは他の人にも発見が多いと考えています。

つまり、すでに色々な考え方や技法があるテストや開発の分野に比べて、すぐに新規性のある発表になります!

「事例発表をしたいけど、まだ発表内容が固まってない…」という人へ

まずは「事例発表したいと思っている」と言ってもらえる(ツイート、DM、直接口頭でこっそり教える)と助かります!*1

また、何回も応募して内容をどんどんブラッシュアップして頂いても構いません。

皆様からのご応募をお待ちしております!

*1:運営は「何人応募してくれるのかな…?」と不安でいっぱいです

「テスト駆動開発の『駆動』は誤訳なんじゃないか」と言われて改めて考えた話

先日、社内のSlackでこんなことを言われました。

f:id:nihonbuson:20200628162510p:plain

TDDとかのdrivenを駆動って訳すの誤訳じゃないのかと思うんですけど、どう思いますか?

意味合いは駆動より操縦とか運転なんだと思うんですが

そこで「駆動」の意味を改めて考えてみました。

辞書で調べてみる

goo辞書では以下のように書かれています。

[名](スル)動力を伝えて動かすこと。「四輪駆動」「駆動輪」

書籍から考える

書籍『エクストリームプログラミング』の第2章には以下のように書かれています。

「運転というのはね、車を正しい方向に走らせることじゃないの。常に注意を払って、こっちに行ったら少し戻して、あっちに行ったら少し戻して、そうやって軌道修正していくものよ」

これがXPのパラダイムだ。注意して、適応して、変更する。

なぜ「駆動」が誤訳だと感じてしまったのか

テスト駆動開発(TDD)は「test-driven development」の略であるように、直訳すると「運転」が当てはまる気がします。

書籍『エクストリームプログラミング』の話にあるように、ここでの「driven」は微調整を繰り返すことこそが重要に感じられます。*1

一方で「駆動」だと、「動かす」というニュアンスが強くなり、「微調整を繰り返す」という意味合いが薄くなっているように思えます。

もしかしてリファクタリングが蔑ろにされる理由の1つ?

さらに最近では「テスト駆動開発=テストをきっかけとして開発を行う」という認識の人も出てきているように感じます。*2

昨年のSelenium Confでのt_wadaさんの講演では、リファクタリングが行われなくなってくる理由について、次のように語っていました。(t-wadaのブログより引用)

黄金の回転を構成するひとつひとつの矢印が、単一の目的を持ち、十分な長さを持ち、 きちんとした軌跡を描いて回転している限りは、テスト駆動開発は大きなパワーを発揮し続けます。

しかしテスト駆動開発の回転がもたらすパワーは、矢印のどれかが傷つき短くなっていくことによって、だんだん減っていきます。

では、3つの矢印のうちで、最も打たれ弱く傷つきやすい矢印はどれでしょうか。みなさんは、どう思いますか?

一番弱く傷つきやすいのは、リファクタリングの矢印です。

(中略)

外発的であれ内発的であれ「きれいにしている時間はない」「リファクタリングしている時間はない」などと焦燥感に駆り立てられると、 リファクタリングの時間が短くなったり、リファクタリングが先送りにされ始めます。 リファクタリングの矢印は弱く、折れたり短くなったりしやすいのです。

f:id:nihonbuson:20200706183413p:plain

もちろん、焦燥感によってリファクタリングが行われなくなることは十分ありえます。

ただそれだけなく、「テスト駆動開発」という言葉自体が、リファクタリングという微調整を繰り返す意味を無くしてしまっていることも原因のように思えます。*3

都合の良いように解釈しているだけ?

いや、ちょっと待ってください。

もしかしたら「微調整を繰り返す」という意味を「駆動」という言葉から無くしているのは、都合の良いように解釈しているからかもしれません。

「駆動」の元々の意味は、最初に書いたように「動力を伝えて動かすこと」です。これは「微調整」や「きっかけ」などの場面に限定した意味ではないはずです。

とするならば、いつからか「テスト駆動開発=テストをきっかけとして開発すること」と認識してしまい、そこから逆算的に「駆動=きっかけ」という本来の意味とは少し異なる考えに至ってしまったのかもしれないです。

改めて「テスト駆動開発」の意味を考えてみよう(+宣伝)

私はこの一件で、改めて「テスト駆動開発」というものを意味から考え直すことができました。

皆さんも「テスト駆動開発」とは何か、改めて考えてみませんか?

そもそも「テスト駆動開発」を知らない、やったことないという人は、8/1にTDD Boot Campが久々に開催されるので、そちらに参加して体験してみてはいかがでしょうか?*4

peatix.com

追記

記事を公開したら早くもフィードバックが!ありがたやー。

確かに「driven」と受動態になっている以上、「テストに駆動される開発」と考えた方が良さそうですね。

ただその解釈であっても、「駆動される」タイミングが新しいテストを書き始めた時だけの認識になり、リファクタリングのような微調整を伴う時の認識が薄れているなーという思いは変わりません。*5

確かにそうですね。「誤認の可能性がある」という方が納得感があります。

ただ、発端となった社内の人の発言は「誤訳」なので、記事のタイトルはこのままでいきます。

*1:書籍の例はXPの話であり、TDDに限定した話を示したわけではないですが、TDDにも通じる話のように思ってます

*2:「テストをきっかけとして開発を行う」はテストファーストな開発ではありますが、テスト駆動開発ではないのでは?というのが私の考えです。

*3:「誤訳」ではないが「誤認をしてしまう恐れがある」といったところでしょうか

*4:自分が参加した時のレポートこちら

nihonbuson.hatenadiary.jp

*5:認識が薄れている理由が「駆動」という単語のチョイスではなく、都合の良いように解釈した結果であることは、元の文章でも書いた通りです。

銀の弾丸には時間軸も存在する

最近、周りで銀の弾丸を提供しようとしている人が散見されたので、思ったことをつらつらと。

銀の弾丸を求めるな」というのは、「どんな場合でも活用できる万能なプラクティスなんて無いんだよ」という話だけではないと思ってます。

普段から同じプラクティスを使っている場合に、「本当にそのプラクティスが適切か常に見つめ直す必要があるんだよ」ということを伝えてるような気もしてます。つまり、「昔も今も未来も同じプラクティスを当てはめている=銀の弾丸」となっていないかと見つめ直すことも大事なのでは?という主張です。

『人月の神話』より

書籍『人月の神話』の第16章「銀の弾などない——ソフトウェアエンジニアリングの本質と偶有的事項」の一節

現代のソフトウェアシステムでこれ以上還元することができない基本的要素に含まれる固有の性質

の1つとして、可変性が挙げられています。

ソフトウェア実体は、つねに変更という圧力にさらされている。

(中略)

大当たりしたソフトウェアはまずたいてい、すべて変更される。行われる作業は2つの工程である。あるソフトウェア製品が役立つと分かると、人々はもともと処理対象としていた領域ぎりぎりもしくはその領域を超えるような新しい使い方を試してみようとする。主として、拡張機能のために変更してほしいという圧力は、基本機能が気に入っていて新しい使い方を考え出す利用者から出される

次に、大当たりしたソフトウェアは最初に書かれた対象である機械機器(媒体)の通常の寿命よりも長く使用され続ける。新しいコンピュータが出てこないとしても、新しいディスクや新しいディスプレイ、新しいプリンタが出てくれば、ソフトウェアは成功する見込みのある新しい機器(媒体)に順応しなければならない。

要するに、ソフトウェア製品はアプリケーションや利用者、慣習および機械機器(媒体)といった文化的マトリックスにすっかりはめ込まれているのだ。そしてそれらは絶えず変化し続けるものであり、その変化がソフトウェア製品に容赦なく変更を強制するのである。

ソフトウェア以外のプラクティスでも同様のことが言える

『人月の神話』ではソフトウェアについて話していますが、それだけでなく常日頃行なっている様々なプラクティスに対しても同様のことが言えると思ってます。

例えば、Daily Scrum。

「前回のデイリースクラムから行ったこと・次回のデイリースクラムまでに行うこと・問題点を15分以内で話し合う」という風に言われてるけど、それって本当に適切なのかな?と疑問を持って良いはずです。*1

例えば、レトロスペクティブ。

「今までKPTでやってました。KPTを導入してみたら我々のチームではうまく行きそうだったのでKPTでやり続けてます。」と言ってたりするけど、それって本当に今でも適切なのかな?と疑問を持って良いはずです。

やっているScrumイベントや、構成しているチームメンバーが変わっていないとしても、適切なラクティスは日々刻々と変わるはずです。

それを無視して「それだったらこのプラクティスを使えば良いよ」と案にプラクティスを薦めるようなAgileコーチがいるとしたら、それはどうなのかなと思ってます。

病院での検診の例

例えば、病院での検診で考えてみましょう。

「どんな人が来ても、腹痛を訴えてきたら痛み止めを処方して終了」という医者は信用できないですよね?

ただそれだけでなく、「Aさんが来たら、腹痛を訴えた時には痛み止めを処方して終了」という医者も信用できないはずです。

同じ人が訴えているいつも通りの腹痛とは思ってたけど、ちゃんと調べたら実はガンだった、かもしれません。

「いつも通り」という思考停止

変化を見極めず、いつも通りというプラクティス*2を提供するような人は、医者でもアドバイザーでも信用できないと思ってます。 ただし、プラクティスではなく本質的な考え方はあまり変化せずに当てはまることが多いので、その部分は引き続き大切に持ち続けたいものです。(自戒を込めて)

*1:現に、2013年度版のスクラムガイドでは質問内容が改められ、2017年版のスクラムガイドではDaily Scrum実施時のオプションであり、別の方法でやっても良いとなっているようです。参考:スクラムで削除された5つのトピック

*2:思考停止の分類の中の「無意識の思考停止」に当てはまるのかも

Scrum Fest Osaka @Online 開催終了?しました #scrumosaka

6/26,27にScrum Fest Osaka@Onlineが開催されました。

www.scrumosaka.org

イベントは本番前から始まっていた…!

本イベントは開催前からdiscordを用いて運営の話し合いをオープンに公開していました。

そんなdiscordの場で私は、実行委員ではないにも関わらず無邪気に色々と絡ませてもらいました。

具体的には、新潟トラックのトラックオーナーとしてコンテンツ作成に携わった他、「フェスフェス」や「仕事してる」といったリアクションの絵文字を作成したりしてました。

f:id:nihonbuson:20200628154631p:plain
フェスフェス誕生の瞬間

少しでもイベントの盛り上がりに貢献できたのならば嬉しいです。

イベント開催、そして発表

イベント当日には、パネルディスカッションの登壇の他、発表も行いました。

発表資料は既にアップロードしてます。

speakerdeck.com

書籍『Agile Testing Condensed』の中で、特に伝えた方が良いなと感じた部分を中心に紹介しました。

また、以前にこのブログでも書いた「実例マッピング*1を実際に使った事例を、当時の会話込みでお伝えしました。

発表の聴講者からは「良かった」という感想を多くいただき嬉しい限りです!

イベントは終了した…のか?

イベント自体は6/26,27で、この記事を書いている時点ではすべての発表が終了しました。ですが、discordはまだ残っており、引き続き会話が行われてます。そして、講演の内容は動画に収められており、参加登録した方々はイベント終了後もその動画を見ることができます。*2

すべての発表が終わったにも関わらず、イベントが終了した感じになっていないのは独特な感じがします。

この余韻も含めて、Scrum Fest Osaka@Onlineはこれからのオンラインイベントの見本になるような気がしました。

とまあ色々と感じたことを書きましたが、このイベントの感想を一言で言うと「いやー、楽しかったーー!!」でした。

*1:実例マッピングの記事はこちらnihonbuson.hatenadiary.jp

*2:もちろん私の講演動画もあります!

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)が紹介されています。

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

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

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

cucumber.io

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


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

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

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

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

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

実例マッピングのやり方

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

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

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

f:id:nihonbuson:20200304144940p:plain

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

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

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

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

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

以上です。簡単ですね!

即座のフィードバック

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

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

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

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

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

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

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

利点

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

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

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

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

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

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

友人のエピソード

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

f:id:nihonbuson:20200304145202p:plain

例えば:

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

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

f:id:nihonbuson:20200418192611p:plain

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

「知らない」を知ること

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

f:id:nihonbuson:20200418192740p:plain

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

最後のTips

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

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

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

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

*1:よくユーザーストーリーマッピングと勘違いされがちですが、ユーザーストーリーマッピングとは異なるプラクティスです。

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

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

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

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

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

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

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

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

テストに対する考え方「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:後日どこかで各項目について解説できるといいなぁ…。