「TDD」と「テスト戦略からテスト実装」はどのように関わるのか

SHUJI🐊 @shuji_w6e

2日でユニットテスト66件か。訓練を積んで50件/日くらいのスコアが出したいところだな

SHUJI🐊 @shuji_w6e

先にユースケースを書く方が結果的に効率が良いということは再認識。早く動くものを作りたい衝動と戦わなければならない

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

TDDとテスト戦略に関する考察がほしい。

SHUJI🐊 @shuji_w6e

1. ユースケースと画面モックを作成 2.ユースケースをグループ化 3.グループ毎に低レベルレイヤーから実装（ユースケース/レイヤーで１チケット） という流れがベストかなー

SHUJI🐊 @shuji_w6e

@kyon_mm テスト戦略ってどの辺りのテスト？

あひさめ @a_hisame

@kyon_mm テスト戦略とは？

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

.@shuji_w6e @a_hisame テスト戦略は何を中心にテストを組み立てるかという方針です。流れとしては、テスト戦略、テスト分析、テスト計画、テスト設計となります。なのでさっきのツイートはちょっと不適切ですね。言いたかったのはテスト設計までの流れとTDDについてです。

SHUJI🐊 @shuji_w6e

@kyon_mm だとすると、TDDは開発手法に近いからテスト戦略とは切り離すのが理想。ただ、ステークホルダを納得させるためにやや強引に関連づける事が現実だと思う。

あひさめ @a_hisame

@kyon_mm 自分はTDDでは「まずできる事から」テストを作っていって、GREENを確認しながらテストのリファクタリングを進めて行きますね。あと、TDDのテストは設計対象の使い方を考える事も強いメリットであると考えてるので「どの様に使いたいか」を考えてテストを書いてます。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

テスト戦略、テスト分析、テスト計画、テスト設計、テスト実装、テスト実行、テスト報告。。。が一連の流れだと思う。それぞれかぶっていたりする部分があるとは思うけど。

かわにし @tosikawa

@kyon_mm その辺のはなしはとちぎテストの会議なので色々議論されたりしていて、まだ定説はないというか、これから色々まとまってくるかんじだとおもいますよ。

かわにし @tosikawa

@kyon_mm 一応こんな感じ http://bit.ly/18vQY9

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@shuji_w6e そこが悩みどころというか、さっきのお話につながって、ユースケースはやっぱり最初にあると思うんです。ある程度のストーリー。そこがテスト設計に関わってきたりするんじゃないかと。（どうやって観測するのかとか）

あひさめ @a_hisame

@kyon_mm TDDだと結構真逆かも。テスト実装＞実行＞(自動的な報告)＞(場合によっては網羅性の追加)、テストのリファクタリングによる「開発者のための」テストを対象にするので。コード保証のためのテストは、被ってる部分もあると思いますが、自分は(今の所)別物と考えてます。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@a_hisame まさしくそれがTDDだと思います。自分でドッグフーディングすることで設計の質を高めて行く。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@tosikawa やっぱりそうなんですねー。去年の栃木テストにすっごくすっごくすっごく行きたかったですw

かわにし @tosikawa

@kyon_mm まあ定説がないってことなんで、「きょんきょんメソッド」の発表が待望されている分野であるともいえます。

SHUJI🐊 @shuji_w6e

.@kyon_mm ユースケースがテストに関連付くのは自然ですね、システムテストや結合テストという形で。テスト駆動を適用するならば、ユースケース記述レベルからシステムテスト項目をブレイクダウンして、レビューを通してから実装となるのでしょうが、コストとのトレードオフかも。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@a_hisame たしかに。ただTDDって実装したいユースケースはありますよね？そこの兼ね合いかと。テスト戦略からテスト設計までは「どうやってテストすることが最もいいのか」を考える段階です。そこがあってTDDに流れて行くのが自然かなーって思ったり。よくわかってないですがw

SHUJI🐊 @shuji_w6e

.@kyon_mm どうしても上流でテスト設計するほど難易度が高くなります。要求仕様が固まる＝受け入れテストが作れるは理想ですが、まず無理。ユースケースレベルで、システムテストの６−７割を埋めてみようというのは今度のプロジェクトで試したいな、と考えていたり。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@tosikawa ゆもつよメソッドに続くですかwww 西康晴さんをご存知でしょうか？実は西さんの学科に１年だけいたのですよw　そのときはまるで知らなかったのですが、去年？になってソフトウェアテスト業界の大物だと知ってビックリしましたw

あひさめ @a_hisame

@kyon_mm 自分は大きく考えなくてもTDDはできると思っているので、むしろユースケース設計時にTDDを(紙の上で)実践するのも良いのではないかと。結局「どの様に使うか」を考える事がそのままTDDに繋がるのではないかと期待してます。使い方が難しい＝テストが難しい、なので。

SHUJI🐊 @shuji_w6e

今度のプロジェクトが取れれば、テストがたんまり出来るので、色々とチャレンジしたいな。特に早い段階でテスト設計をすることが開発全体に与える影響は知りたい。

あひさめ @a_hisame

まー、まだ働いた事のない若輩の意見ですがが。

かわにし @tosikawa

@kyon_mm あ、にしさんの講義をうけていたのですねw では大丈夫。