ひよっこ。

I want to…

xDDについて考える3

Posted by hikaruworld : 2010 3月 27

これは、前回の続きになります。

多層的にxDDを実践する

自分が考えるxDDの連携とは以下のような感じです。

また、こういった風にxDDを実践することの大きなメリットは、
Inputに対して最終的なOutputを早期に返せることだと思います。
※ここでいうOutputは実装された成果物ではなく、要求を満たすテスト仕様のアウトラインのことです。

つまり、「こういう機能が欲しいんだ」というユーザ要望に対して、
「このような仕様で行きますよ」ではなく「この動作が問題なく通れば機能は問題ありませんね」
という方法を提示します。

個人的には、要求に対応するのは実装結果ではなくその要求を満たすテストと考えています(どっかの受け売り気がする)。
具体的な流れとしては以下のような感じです。

1.DDD

どう組み込むかはまだはっきり見えていないのでTODOです…

2.SDD

あるストーリ(機能要求)があったとして、まずはそれを満たすStoryテストを記述する。
このテストはペンディングで構いません。
ペンディングで構わない理由は、GUIのテストは非常に複雑になってしまうこと、
機能要求レベルではUIが確定していないため「実現したい目的」を詰めていきたい、といったことが背景です。
このStoryテストが問題ない場合に、要件に落し込み設計を行います(BDDへ)。

3.BDD

機能要求レベルで合意が取られ、要件に落とし込む段階で、振る舞いの挙動を記述します。
振る舞いレベルで必要なモジュールを作成し、クラス化していきます(TDDへ)。
外部APIとして公開するような機能であれば、SDDと同様にペンディングレベルで確認が必要でしょう。

4.TDD

BDDで考えられたクラスやメソッドレベルの実装をTDDで設計を行いながら実装を行います。
このときテスタビリティのみではなく、デバッカビリティを考慮します。
つまり、TDDをやっていれば、必然的にテストしやすいコードとしにくいコードはわかると思いますので、
そこをインスペクションによって担保できるかを検討する必要があります。

xDDの連携によって得られる恩恵とは

ここでも書かれていますが、テストによってソフトの品質を保証する場合は、
何を重要視するかによって、必ずトレードオフが発生します。

但し、今回のように駆動単位でどの象限を保障し、品質を担保するかを行っている場合、
それぞれのフィールドにおいてお互いに補正することが可能になります。
これは非常に大きなメリットですね。

よく現場で言われる「品質」というバズワードは、こういった様々な目的に応じた
品質の属性を把握して議論できないため、内容が発散してしまっているように感じます。
実際に現場で活用する場合は、相手がどの部分を注視しているかを把握しながら、
交渉をしていきたいものです。

# 聖戦の系譜の外伝でトラキア776というSFCのゲームがあるんですが、
# それの聖戦士の書というのをなぜか連想しました。

参考

最後に@AfterClass

まぁ、なんだかんだいいつつ、すべて実行するのは難しいものですとか。
あと、xDDと命名された駆動開発の手法の多くは、
目的によって意識されやすいように命名されたものに過ぎないのかな、と思いました。

* 4象限をxDDで考えた場合は、厳密に分けられるわけではない。
* 常に特定の品質属性が求められるわけではなく、いつどこにフォーカスを当てるかによって変わる。

以上です。

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中

 
%d人のブロガーが「いいね」をつけました。