ValidationとTDDについてのメモ
-
- いいね！0
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
@goyoki ValidationとTDDは相容れないものだと思いますか？ [うさみみ＊´×｀＊エンジニア]
2012-03-17 17:24:50
goyoki
@goyoki
@kyon_mm ATDDとかありますしそうは思ってないです。普通のTDDでも、完全に一緒にすると効率落ちますが、重ねられる部分はありますし、その部分を広げる工夫もそれぞれで可能だと考えています
2012-03-17 17:33:17
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
@goyoki なるほど。僕はValidationは要求を作り出す行為に近いと思っていて、それらの行為は設計であり実装補助手段であるTDDとは相性が悪いと思っていました。相性を決めるラインがどこかというのは難しい話ですね。 [うさみみ＊´×｀＊エンジニア]
2012-03-17 17:48:29
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
@goyoki (僕が誤解している可能性が高いのですが)Validationはシステム下におけるUATと、システム表層におけるUX評価という要素が含まれていると思っています。後者が「要求を作り出す行為」になりえると思っていて、（続く [うさみみ＊´×｀＊エンジニア]
2012-03-17 23:34:11
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
@goyoki 後者の行為の中で以前とは異なるUXが生み出される事で、システム下におけるUATで考慮していたことがなくなる可能性があると思っています。なので、Validationをする中で新たな要求と設計が生まれることがあり、（続く [うさみみ＊´×｀＊エンジニア]
2012-03-17 23:36:21
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
@goyoki それらは実装補助手段であるTDDとは相性が悪いのかな。って思っていた。ということです。 [うさみみ＊´×｀＊エンジニア]
2012-03-17 23:36:26
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
Validationについて本当になにも知らないのです。気になったので聞いてみたのです。あの、変な内容だったらバシバシつっこんでください。@goyoki [うさみみ＊´×｀＊エンジニア]
2012-03-17 23:38:30
goyoki
@goyoki
@kyon_mm まず僕のバリデーションの捉え方ですけど、バリデーションの定義は結構幅がありますが、自分は基本的に要求に対する妥当性確認と言う意味で使っています。
2012-03-18 00:06:31
goyoki
@goyoki
@kyon_mm システム・バリデーションなら、システムの要求を達成しているかを判定する試験です。またプロセス・バリデーションなら、プロセスに対する要求（IEC62304やFDA 510k等の法規制が代表例）を達成しているかを判定する試験になります。
2012-03-18 00:07:25
goyoki
@goyoki
@kyon_mm きょんさんのいうようなユーザ要求に対するバリデーションあら、自分の定義ではシステムバリデーションか、さらに後のユーザ受け入れ試験になります
2012-03-18 00:08:25
goyoki
@goyoki
@kyon_mm で、その前提での話ですが、きょんさんの「システム表層におけるUX評価」は、バリデーションというより、要求獲得・要求定義の話のような気がします。Vモデル左側です。その捉え方の差異が、TDDの位置づけの差異につながっていると感じました
2012-03-18 00:10:52
goyoki
@goyoki
@kyon_mm ただきょんさんが間違っている訳ではありません。最近はWモデルとかATDDとか、要求分析の段階からテストを考慮したり、テストファースト前提で要求定義したりと色々方法論が認知されつつあります。また実際、ユーザに見せて変更要求がごろごろ発生するのも珍しくないですし
2012-03-18 00:12:49
goyoki
@goyoki
@kyon_mm そこではもしかしたらバリデーションが要求分析の手段になると判断する人ももしかしたらいるかもしれません。ただ自分の定義だとシステム・バリデーションの段階では試験方法も試験基準も既に明らかで、明らかにすべき未定義の要求は残っていない、という感じです
2012-03-18 00:15:42
goyoki
@goyoki
@kyon_mm 本題ですが、Vモデル右側に位置づけられるバリデーションの意味でなら、TDDやその他検証で、バリデーションの試験項目を部分的に重複実施できるので、TDDとバリデーションは重ねられる部分があると言及しました（ただバリデーションをTDDで代替できるというのは別の話）
2012-03-18 00:19:15
goyoki
@goyoki
@kyon_mm 一方きょんさんのいう、要求分析や要求定義の方法（Validationは要求を作り出す行為）としての意味なら、その通り標準的なTDDは相性良くないと自分も思います。
2012-03-18 00:22:48
goyoki
@goyoki
@kyon_mm そこでは要求や仕様が流動的なので、TDDで力入れて高品質なコードを書いても無駄になる可能性が高いですから。以下に軽快にプロトタイピングを行ってユーザが満足するものを見せられるかの方が重要なので、きょんさんの意見と同意です
2012-03-18 00:24:43
goyoki
@goyoki
@kyon_mm ただ「Validationは要求を作り出す行為」というのは自分的には違和感あります。「要求に作り出す余地がありバリデーションの中でそれを明らかにする」というのは、最初から試験基準なんかが曖昧でValidationの形をなしていないような印象を受けたので
2012-03-18 00:30:41
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
@goyoki goyokiさんのは厳格に定義された要求に対して実施できるものがValidationということですね。僕が考えていたのはVの右側でのValidationを行うために必要な要求に対する行為もValidationと捉えていました。 [うさみみ＊´×｀＊エンジニア]
2012-03-18 01:05:02
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
@goyoki 自分のは言ってしまえばテスト要求分析とテスト実施をいっしょくたに考えてしまっているのに近いのですね。ある極一部ではそれはありえるかもしれないけど、それは本質的に行為としては異なるし、わけたほうがよいと僕も思います。 [うさみみ＊´×｀＊エンジニア]
2012-03-18 01:08:26
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
@goyoki そういう意味だと自分の捉え方は少し「わかりにくい」かもしれませんね。なるほど。いろいろわかりました。丁寧に説明いただいて本当にありがとうございます！ [うさみみ＊´×｀＊エンジニア]
2012-03-18 01:09:52
goyoki
@goyoki
@kyon_mm 厳格というよりも、定義が曖昧でも「定義された存在する要求」に対する試験はバリデーションになるだろうけれど、「存在しない要求」に対する試験はバリデーションになり得ない、なんて考えです。
2012-03-18 01:43:58
goyoki
@goyoki
@kyon_mm あと念頭に置いているテストプロセスのフェーズが僕ときょんさんで違ってるっぽいですね。自分はバリデーションの実行も含めて考えてたんですが、きょんさんはバリデーションの分析や設計フェーズを念頭に置いてるのですね。
2012-03-18 01:46:31
goyoki
@goyoki
@kyon_mm テスト計画や、テスト分析・テスト設計のテストの上流工程ならきょんさんの考えも問題ないと思います。まさにWモデルやATDDの話ですし、旬のClean Coderでも「受け入れテストとは、要求の完了を定義するために〜書くテストの事である」なんて触れてますよね
2012-03-18 01:48:43