-
- いいね！0
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
先に書いておくべきでしたが、ATDDはAccecptance Test DD, STDDはStory Test DDの略になります。 RT @kyon_mm: …ATDDにおけるテストはユーザー要求に対する受け入れテストを先に書いて…。 @YasuharuNishi
2011-11-01 13:21:50
Yasuharu NISHI
@YasuharuNishi
ユーザ要求とユーザシナリオって全社が上位？ RT @kyon_mm: …ATDDにおけるテストはユーザー要求に対する受け入れテストを先に書いて…。 RT: ユーザレベルって、ユーザシナリオの網羅とか、ユーザが間違えやすい業務フローとか、 (via @YasuharuNishi)
2011-11-01 12:46:13
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
言葉の選択がわるいのかもしれませんが、ストーリー(シナリオ)は個々の要求をまとめたものか、要求と1対1になると思っています。RT: ユーザ要求とユーザシナリオって全社が上位？ (via @YasuharuNishi)
2011-11-01 13:31:01
Yasuharu NISHI
@YasuharuNishi
システムのふるまいの下位に、ユーザシナリオがあるんだね。 RT @kyon_mm: STDDはATDDよりも抽象度が高く、システムのふるまいをテストすることになります。ここにシナリオテストなどがはいってくると僕はおもっています。
2011-11-01 12:47:08
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
はい。そのイメージです。システムのふるまいを確認する手段やユーザーの要求を具体化したもののパターンの一つとしてシナリオがあると思っています。 RT: システムのふるまいの下位に、ユーザシナリオがあるんだね。 (via @YasuharuNishi)
2011-11-01 13:33:39
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
@tmtms そういう狙いもあると思います。個人的にはBDDは記述様式と単語を変えたことで、プログラマーのためのテストとカスタマーのためのテストを書けるようになったことが大きいと思います。
2011-11-01 13:57:47
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
検証指向TDDについてはいつか開発者さんが「これが正しいVOTDDです」っていってくれる時期がくると思います。僕が知っている検証指向TDDはソフトウェアテストPRESS総集編から受けたイメージになります。
2011-11-01 14:00:23
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
僕の言葉が間違っている場合はつっこみをくださると嬉しいです。ただコンテキストがあってツイートしているので、ひとつひとつのツイートで説明が欠落している部分があると思います。
2011-11-01 14:07:46
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
@mkoszk 僕の言葉が代表的かはわかりません。むしろすこし不安ではあります。アジャイルやTDDで活躍している方から聞くのがもっと純粋な言葉を聞けると思います。
2011-11-01 14:02:55
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
@mkoszk なるほど。この記事自分としては微妙だったのですが、たぶん同じようにいろんなかたがいろんな定義を探しているのかもしれません。
2011-11-01 14:36:33
Yasuharu NISHI
@YasuharuNishi
仕様書に現れない細かい仕様が、ただ細かく考えるだけで分かるのであれば、非明文化された仕様、って感じでしょう。RT @kyon_mm: はい。実際には細かい(仕様書にあらわれないような実装部分)に関してもテストコードを記述することもあって、その積み重ねになります。
2011-11-01 14:44:00
Yasuharu NISHI
@YasuharuNishi
でも仕様書に現れないところが抜けやすいとか間違えやすいというのであれば、仕様とは別の何らかのテスト観点が必要になります。 RT @kyon_mm: はい。実際には細かい(仕様書にあらわれないような実装部分)に関してもテストコードを記述することもあって、その積み重ねになります。
2011-11-01 14:44:46
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
そのような観点には僕はTDDとペアプロが有効だとは思ってはいるのですが、具体的に表現できていません。 RT: でも仕様書に現れないところが抜けやすいとか間違えやすいというのであれば、仕様とは別の何らかのテスト観点が必要になります。 (via @YasuharuNishi)
2011-11-01 14:53:55
Yasuharu NISHI
@YasuharuNishi
OK。ではこれから、「網羅」というのはそういう意味で使いましょう。 RT @kyon_mm: やはり仕様に対する網羅性だと思います。 RT: 網羅してなくても構いませんよ。もしそのテストケースと似たようなテストケースを増やしていくと、何が網羅されることになると思いますか？
2011-11-01 14:45:19
Yasuharu NISHI
@YasuharuNishi
他に考慮点はありますか？ RT @kyon_mm: いくつもある考慮すべき点のうちの大きな一つだと思います。 RT: まずユーザーを想定して、それからprivateか外部公開か、などを考えるのかな。
2011-11-01 14:46:03
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
先にあげた選択した設計思想との適合度、選択したプログラミング原則との適合度、テスタビリティなどになります。 RT: 他に考慮点はありますか？ RT @kyon_mm: いくつもある考慮すべき点のうちの大きな一つだと思います。 (via @YasuharuNishi)
2011-11-01 14:55:09
Yasuharu NISHI
@YasuharuNishi
そうすると、ストーリーとシナリオは同義語、ストーリーの下位に要求がある、と。 RT @kyon_mm: 言葉の選択がわるいのかもしれませんが、ストーリー(シナリオ)は個々の要求をまとめたものか、要求と1対1になると思っています。
2011-11-01 14:47:48
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
はい。あくまで僕の中のイメージですが、その定義でつかっています。 RT: そうすると、ストーリーとシナリオは同義語、ストーリーの下位に要求がある、と。 (via @YasuharuNishi)
2011-11-01 14:56:01
Yasuharu NISHI
@YasuharuNishi
そろそろ日本でもテストプロセス改善の活動を始めた方がいいんだろうね。TPI(-Next)、TMMi、ISO/IEC33063と駒は揃いつつあるから。
2011-11-01 15:19:34
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
テストプロセスの再定義楽しみです。アジャイルとかドメインとか自動化とかプログラミング言語の進化とかインフラの進化とかが考慮されているとすごく嬉しい。
2011-11-01 15:34:36
Yasuharu NISHI
@YasuharuNishi
テスト観点をきちんと挙げるということは、開発の弱点を挙げることにつながるわけです。RT @kyon_mm: そのような観点…は…具体的に表現できていません。 RT: でも仕様書に現れないところが抜けやすいとか間違えやすいというのであれば、…何らかのテスト観点が必要になります。
2011-11-01 15:01:18
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
はい。具体化できるように頑張ります！ RT: テスト観点をきちんと挙げるということは、開発の弱点を挙げることにつながるわけです。RT でも仕様書に現れないところが抜けやすいとか間違えやすいというのであれば、…何らかのテスト観点が必要になります。via @YasuharuNishi
2011-11-01 15:25:23