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