Scrum Fest Niigata 2022 発表資料です。 https://confengine.com/conferences/scrum-fest-niigata-2022/proposal/16449
Dan North: “BDD Is Not About Testing" https://www.youtube.com/watch?v=6nSwRSbc27g
アジャイルリーダー視点で考える、我々はなぜ、テストをするのか？
View Slide
川口 恭伸かわぐち やすのぶTwitter: @kawagutiアギレルゴコンサルティング株式会社 シニアアジャイルコーチ株式会社ホロラボ シニアアジャイルコーチ一般社団法人スクラムギャザリング東京実行委員会 代表理事一般社団法人 DevOpsDays Tokyo 代表理事
Dan North:“BDD Is Not About Testing"
Dan North:“BDDはテスティングではない"
私がテスト駆動開発ではなくビヘイビア駆動開発について話し始めた理由の一つは、テスティングが本当の目的ではないという考えがあったからです。
BDDについて話し始めたのは2003年のことです。2006年には記事を書きました。
よく耳にするのは、テスターがアジャイルに取り残されているように感じるということです。
プロジェクトマネージャーは2日間の宿泊クラスに参加して、スクラムマスターになって戻ってくることができますよね。そうすべきでないことはわかっていますが、彼らはそうします。また、ビジネスアナリストは別の2日間のクラスに参加し、プロダクトオーナーとして戻ってきて、全員が認定されるという素晴らしいものです。開発者はクリーンコードやTDD、ブートキャンプなどに参加し、テスト担当者はテスト担当者の声を聞くことになりますね。
BDDとは何かというと、自動化されたシナリオのことで、それをBDDと呼んでいます。そして、何百、いや何千ものBDDがありました。そして、そのBDDが隅っこの山で腐っているのは、ちょっと残念でした。
オートメーション・テスターとは何なのか、私にはよくわかりませんが、文字通り、自動化されているかどうかをテストする人のことです。(中略)この役割が何なのかわかりません。
1.プログラマーはテストを理解していない2. アジャイルはテストを理解していない3.テスターはBDDが好きだ4.BDDはテスティングではない
さて、「BDDはテスティングではない」という建設的な話をするためには、テストの話をする必要があります。さて、なぜテストがあるのでしょうか？
私は人々に、なぜテストが必要なのかと尋ねると、さまざまな理由が返ってきます。しかし、一番多い理由は「やらなければならないから」です。SDLCやプロセスドキュメントなどに「テストを行う」と書かれていると、「よし、テストを行うぞ」となりますよね。
私はこれを「4本足の論理」と呼んでいます。すべての牛には4本の脚がある、だから4本脚の動物はすべて牛が好きだ。これは間違った論理であり、論理的誤謬を含んでいます。プロジェクトマネージャーはテストをリスクの原因と考えています。
誰が気にするの？投資して卓越せよ差別化ビジネスに決定的パリティパートナーにアウトソース
私が見てきた組織では、3年ごとに「何でも買います」「何でも外注します」と振り子のように行動し、その結果を見ていました。
私が研修で「テストの目的は何か」と聞くと、25人の受講者から30通りの答えが返ってくるんですよ。
数年前に、Stack Overflowで「ユニットテストはどれくらい深くやっていますか」という素晴らしい質問がありました。
そしてケントが返信したのですが、ケンは何と言ったと思いますか？「私はテストではなく、動くコードに対して報酬を得る」と言っていました。
私はできる限り最小限の作業、最小限のテストしかしません。
一部の人たちはメルトダウンしてしまったのです。聖なるケント・ベックの回答の下にあったコメントですね。「でも、TDDではそんなことは言えませんよね」みたいな。マスターができるだけ少ないテストを書こうとするので、人々は明らかに存在の危機に陥っています。興味深いのは、彼が「一定の信頼度に達するためには」と言っていることです。
テストの目的とは、証拠によってステークホルダーの信頼を高めることだと思います。
私がソフトウェア製品を作っているとしたら、私のステークホルダーは誰でしょう？私のユーザー、ステークホルダーです。うん。他には？プログラマー自身がステークホルダーです。未来のあなたは、現在のあなたが行っている作業のステークホルダーです。
私の好きなUXの専門家の一人であるMark McNeillという人は、ステークホルダーは「あなたが触れる人の人生」と言っています。ステークホルダーとは、あなたが仕事をすることで人生に触れる人たちのことです。peoplewhose livesyou touch
では、自信を高めるとは？どれくらい増加するのか、ということですね。そう、増やすには何が必要なのか？そして、彼らは何に対して自信を持つ必要があるのでしょうか？もし私がセキュリティ担当者なら、何が私に自信を与えてくれますか？
信じてください、私が書いたんです。最高ですよ。正直なところ、それは私の評判次第でうまくいくかもしれません。Stack Overflowで100万以上の質問に答えていれば、人々は私を信じてくれるかもしれませんが、どうでしょう。でも、実際には根拠があってわかるわけですよね。他の種類の自信はいらないんです。証拠が欲しいのです。
よいテスターは3つの超能力を持っていると思います。
まず第一に、他人の頭の中に入り込むことができなければなりません。誰かが自信を持っていることを考えるには、その人と同じように考えることができなければ、その人の靴の中を歩くことができなければなりません。なるほど、つまり私に必要なのはまず共感ですね。その人がどんな人なのかを理解する必要があります。
次に必要なのは、証拠を得ることです。その証拠を得るためには、データベースの中をスクロールする必要があります。画面の隅にアイトラッキングカメラを設置して、あなたや私がどうやって証拠を手に入れるのかを確認することもできるでしょう。
そして3つ目に必要なことは、現実的であることです。私には無限の時間も、無限の資源も、無限のお金もありません。つまり、安心してこの製品を出荷するためには、当社のポートフォリオや利害関係者の世界全体で十分なレベルの信頼性を得る必要があります。
まず第一に、プログラマーはテストを理解していないということです。
そうですね。私のデータによると、私のクラスでは誰もそのような答えを出しませんでした。彼らはテストが他人のためのものであることを理解していません。自信の問題だということも理解できない。根拠を示すまで、それが証拠であることを理解しないのです。
これは2003年に書いたものです。この記事は10代の頃のものですね。
アジャイルは主にプログラマーが作ったものです。Snowbirdで出会った17人の中年の白人男性、そして2001年には全員がプログラマーでした。
彼らがテストに関心がなかったわけではありません。つまり、テスターがテストについて考えるような方法でテストについて考えていなかったということです。つまり、暗黙の了解ということですね。
そして10年後、あるいは15年後くらいには、明確なテストが行われるようになりました。ジョージ・ディンウィディ、ジャネット・グレゴリー、リサ・クリスピンといった人たちが、スリー・アミーゴズのようなアイデアについて話しています。そこではテスターを明確に参加させていますが、彼らはとても大きな空間の中の小さな小さな声です。
ビヘイビア駆動開発は2003年に始まったのですが、言ってみれば、TDDで開発者をコーチするための方法として始まりました。私はこれをメソッドやモノとしてデザインしたわけではありません。ただのコーチングツールだったのです。
私たちはプログラマーです。だから、私たちはテストを書きません。そのためにテスターがいるんです。廊下の先にいる彼らの給料は安いんですよ。
BDDは、ケントとウォードがTDDでやっていることを正確に説明しようとしたものです。テストという言葉を使わずに、exampleやspecification、behaviorなどの言葉を使い始めました。他には何も変わりませんでした。
今、私が見つけたものは、私にとっては常にソフトウェアを書くための方法でしたが、それだけではありません。チームのメンバーが協力して、人々のために役立つソフトウェアを作るための方法なのです。
役に立つものを作っていなければ、どれだけ優れたものを作っていても意味がないということですね。では、テスト担当者にとって魅力的なのはなぜでしょう？まず第一に、複数のステークホルダーを明示的に認めていることです。
スクラムにはプロダクトオーナーがいます。初期のアジャイル手法の多くには、製品について何でも教えてくれる全知全能の存在というものがありますが、私はそうは思いません。(中略)私はいつも、少なくとも15人以上の利害関係者がいて、それぞれが異なることを望んでいるようなプロジェクトで仕事をしてきました。
私たちは、最初から明示的に受け入れ基準を議論しています。「7つの習慣」のように、まずは「終わりを念頭に置いて始める」ことから始めます。
すべてはステークホルダーの視点からアプリケーションの動作を記述していますが、テスターたちは、「これはすごい。それが私たちの仕事です。」と言います。そして実際、私たちは証拠によってステークホルダーの信頼を高めていることがわかります。
BDDが言いたいのは、テストは単なる管理上の制約ではなく、差別化要因であるということです。
チェッキングとは、フィードバックを得るために自動化された作業を行うことです。テスティングは人間が行うもので、洞察力と知識と方法を必要とするものです。
私が考える良い自動テストとは、以下のようなものです。まず必要なのは、名前を明らかにする意図です。つまり、ここで検証しているのが何なのかを知る必要があります。このテストが実行されたとき、あるいはこのテストがパスしたとき、私はどんな動作についてより確信を持つことができるでしょうか？
失敗したとき、私はそれがどのように失敗したのか知りたい。なぜ失敗したのかを知りたい。理想を言えば、それに対して何をすべきかを知りたいのです。
良いシナリオは必ずしも良いテストではありません。つまり、BDDはテストのためのものではないのです。しかし、しかし、テストはBDDを補完するものです。
BDDは、価値あるものを強調するための素晴らしい思考フレームワークです。まず、ステークホルダーを強調し、次に、彼らに自信を持たせる方法を強調することができます。
品質管理が日本の製造業で重視されてきたのはなぜか？
戦後、日本製品の品質を高めなければ国際競争力が得られないという危機意識から生まれた
そして、品質管理の目標も産業の発展にあわせて変化していく。
狩野モデルないと話にならない。あればあるほどよい。なくても困らないけど、好き。持っていたい。当たり前品質一元的品質魅力的品質業界の競争の基準が変わる
例えば自動車の歴史走る。曲がる。より速く。より遠く。エアバッグやABSで安全。安心。当たり前品質一元的品質魅力的品質３０年の変遷
https://hbr.org/1986/01/the-new-new-product-development-game新製品開発におけるゲームのルールは変わりつつあります。多くの企業が、今日の競争市場で優位に立つためには、高品質、低コスト、差別化という基本的な要素だけでは不十分であることに気づいています。また、スピードと柔軟性も必要です。(野中、竹内 1986年)Scrumの源流も語る。
また、物理的な世界に存在すると考えられている産業のバリューチェーンの多くをソフトウェアが担っています。今日の自動車では、ソフトウェアがエンジンを動かし、安全機能を制御し、乗客を楽しませ、ドライバーを目的地に案内し、各車をモバイル、衛星、GPSネットワークに接続しています。車好きの人が自分で車を修理できた時代ははるか昔のことですが、それは主にソフトウェアの内容が充実しているからです。現代 - ソフトウェアが世界を食べているhttps://www.wsj.com/articles/SB100014240531119034809045765122509156294602011年マーク・アンドリーセン
kawaguti
mitsuaki96
tarappo
mixi_engineers
lamrongol
zakiyama
taro_nanairo
marikashiotsuki
trycycle
nabedge
miyake
k6s4i53rx
yuya4
swwweet
dougneiner
sonatard
iamctodd
dotmariusz
jmmastey
maltzj
chriscoyier
philhawksworth
mza
scottboms
destraynor