ひよっこ。

I want to…

xDDについて考える2

Posted by hikaruworld : 2010 3月 27

このエントリは前回の続きです。

xDDの背景

では、なぜこのような多様な駆動開発が提唱されているのでしょうか。

ひとつの理由としては、いくらTDDのみ実践して問題ないことを保障しても、
前提部分で問題があった場合に、テスト自体が意味がなくなることが多々あるためだと思います。
「うまく設計できた、実装は終わった、テストは問題ない、但し顧客が求めている機能ではなかった」
というケースですね。

つまり、駆動する基準(求めているもの)がシステムを作る上で流動的に変化していくことを
把握し対応出来ていないため、アジャイル的な方法にあわせてより大きいレベルでの
駆動が求められているようになってきているのではないでしょうか。

「求めているもの」、つまり設計時に何を考慮しテスト時に何を保証したいかは
実践アジャイルテストに『テストの四象限』というものが定義されています(以下の図参照)。
この図はテストを整理するのにとても参考になります。

これはソフトウェアを構築するに当たって、どのような観点でテストを
行う必要があるかを4面性で分割したものです。

この4象限は、xDDのそれぞれの手法によって多角的に補足しているのではないかと思います。
逆説的に言えば、それぞれのxDD(駆動開発)はそれぞれのフィールドを
満たすための解決方法と考えることも出来るのではないでしょうか。

4象限によって保障されるもの

前述したように、この4象限を保証するために
それぞれ異なる手法が用いられます。

そうすることで、ことなるテスト品質の属性を担保することが出来るのではないかと、
考えるようになりました。
品質の属性はここがわかりやすいと思います。

では、具体的に領域別に用いられる手法や、保証される属性を考えていきたいと思います。

自動(単体テスト・コンポーネントテスト)

TDDによって設計、実装が行われる領域です。
TDDによって設計されたコードは、十分な設計や、利用者を考えたクラスの設計が行われるので、
柔軟性・保守性・試験性などが高いコードになると思います。

自動と手動(機能テストなど)

BDDによって設計される領域です。
基本的な振る舞い、前提条件の検証、イレギュラーケースの検証などが行われるため、
相互接続性、移植性、堅牢性などが注視されると思います。

手動(シナリオテストなど)

SDDによって設計、および評価が行われます。
ユーザニーズを満たしているかを中心とした受け入れテストなどに重点をおいてテストされるため、
主として、使用性が中心として設計されると思います。

ツール(性能テストなど)

その他のテストとは少し色合いが違いますが、
システム全体の構成などに関してはDDDの領域で設計・検証が行われると思います。
可用性、効率性、完全性、信頼性、などが検証事項の中心になるのではないかと思います。
※DDDに関しては自身なし。ただこのレベルじゃないと保証しても意味が無いかなと思います。

というわけで、妄想は次回に続きます。

以上です。

コメントを残す

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

WordPress.com ロゴ

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

Twitter 画像

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

Facebook の写真

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

Google+ フォト

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

%s と連携中

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