BT

振る舞い駆動開発とはツールではなく対話である

| 作者: Jan Stenberg フォローする 37 人のフォロワー , 翻訳者 吉田 英人 フォローする 0 人のフォロワー 投稿日 2014年5月1日. 推定読書時間: 2 分 |

原文(投稿日:2014/04/24)へのリンク

振る舞い駆動(BDD/Behavior-Driven Development)で重要なことはただひとつ,ツールではなく対話である – 先日のCucumberカンファレンスにおいて,Liz Koegh氏が10年間のBDDの実践に関するプレゼンテーションで述べたことばだ。
独立系のアジャイルコーチとしてJBehaveなどにも貢献のある氏は,私たちが長年にわたるBDD実践において,何か大きな誤りを犯していると考えている。しかしその一方で,私たちの現在の理解状況やここ数年で始まったいくつかの開発に対しては,非常に強い関心を持っている。

2003年にDan North氏が最初に思い付いたBDDのアイデアは,定義としてはTDDに近いものだが,システムに必要な振る舞いを記述することばとして,"テストする(test)"ではなく"すべきである(should)"を使う,というものだった。振る舞いについて,特に実例について語ることが,テストを対象とするよりも有用だということが分かった後の2006年,氏はBDDを正式に公開している。

Koegh氏が初期に犯した誤りは,"すべきである"という言葉を"しなくてはならない(must)"あるいは"するつもりだ(will)"に置き換えることで,システム要件や多くの人々の合意に近づけようとする行動だった。North氏が"すべきである"と言ったのには,実は質問や対話を活性化する意図があったのだ。

BDDを運用するコミュニティが多く犯すもうひとつの誤りは,BDDの実践を主張しながらも対話せず,BDDテストについても語らないことだ。"テストする"sという言葉が目標から取り除かれたと同時に,利害関係者やその領域の専門家に実例や振る舞い,シナリオなどについて問うことを止めてしまっているのだ。
Koegh氏は人々に対して,立ち戻って対話することの必要性を声高に呼びかける。 テストの自動化への傾倒は,あまりにも多くのシナリオ作成を要求し,対話よりもツールを重視することから,結果的に人々をスローダウンさせてしまう。ツールから一歩退いて,システムの振る舞いを広く伝えるための対話がなければBDDの効果は得られない – 氏はそれに気付いたのだ。

氏が非常に興味を持っている新概念は,複雑性を推定する方法としてのCynefinである。不確実性の多いビジネスのシナリオに着目して,そこから結果を見いだすためにBDDを用いるものだ。

氏はBDDの最大の目的でプレゼンテーションを結んでいる。

BDDとは,重要なソフトウェアを(例を使って!)記述するためのものです。

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション

InfoQにログインし新機能を利用する


パスワードを忘れた方はこちらへ

Follow

お気に入りのトピックや著者をフォローする

業界やサイト内で一番重要な見出しを閲覧する

Like

より多いシグナル、より少ないノイズ

お気に入りのトピックと著者を選択して自分のフィードを作る

Notifications

最新情報をすぐ手に入れるようにしよう

通知設定をして、お気に入りコンテンツを見逃さないようにしよう!

BT