JaSSTでアジャイル的なテストの話を聞いた-その2

先日、JaSSTについての感想のエントリを書きました。
その時は、基調講演の話だけで力尽きてしまったので、今回、その続きとして、

・チュートリアルならびにライトニング・トークスの感想

また、結論としてフォローしきれていなかった

・「品質」をつくりこむことにもアジャイルの考え方は有用
・テスターはだんだんと滝の上流に向かおうとしている

という点について、書きたいと思います。すごく長くなっていましました。

<チュートリアルでアジャイルな振る舞いについて考える>
基調講演に引き続き、Johanna Rothman氏(以下、Rothman氏といいます)のセッションに参加しました。
タイトルは『Becoming an Agile Tester in a Waterfall World』といい、日本語にすると「ウォーターフォールの開発においてアジャイルなテスターになる」というところでしょうか?
このタイトルを見て、

ウォーターフォール(以下、WFといいます)の開発において、テスターがアジャイルに振舞うにはどうするか
また、WFの開発において、どのようにアジャイル的なテストを導入してゆくか

などの手法、アプローチの方法が学べると思っていました。
しかし、話の主題はむしろ、

テスターがagileに振舞うことがどのようプロジェクトに影響をあたえるか

ということを座学とワークショップを通じて学ぶ、というものでした。

期待とは外れた内容でしたが、それでも多くのことを学ぶことができました。

◆WFは理想の形では終わらないことは深刻なこと
これは、Rothman氏のお話を聞いていたとき出てきた話題です。
ソフトウェア開発に携わる人間であれば、誰もが共感を覚える言葉だと思います。
事実、ソフトウェア開発に携わる人であれば、要求定義、内部設計、外部設計、開発、テストなどの各フェーズの作業が、当初の計画通りに終了することが稀であることを知っています。
計画通りでない、という点においては、スケジュールの前倒しと超過、という2つの場合が考えられます。
が、現実はたいてい後者であり、その遅れを取り戻すために、超過勤務をおこなう、ということもしばしばあります。
苦笑いを浮かべて「そうそう」といいたくなるのですが、改めて考えるとWFがいびつな形でしか行えない、という事実は深刻な事態です。

テストの視点から、スケジュールの超過が問題となるのは、

テストがリリースの時期を越えてしまう

ひどい場合になると

リリースにあわせてテストの時期を削る

という事態を引き起こすことです。
両方共に、前段のフェーズにおけるスケジュールの超過の影響を受けて、品質が「確認不十分」のままソフトウェアを出荷してしまうことになるのです。

WFにおいては、現時点の作業が常に後段の作業のボトルネックとなります。
ある段階の作業がすべて終わらない限り次の段階の作業には進めない、という制約を設けることは、その段階において最大の問題、一番、解決するのが難しい問題をボトルネックとして据えることを意味します。

各段階の作業にも、簡単に解決、消化される作業もあり、解決が難しく、消化されづらい作業もあります。
このとき、解決が難しく、消化されづらい作業、すなわち、最大の問題となる作業をボトルネックとして据えてしまうこと自体には、過ちにはなりません。
むしろ、最大の問題となる作業が終了する時点にあわせて、すべての作業を終わらせることが、無駄を省く良い手段になりえます。
しかし、それは、すべての作業の終了計画を柔軟に変更できる、という条件を満たす限り、すなわち作業すべきを量や時間を適宜、調整できる限りです。
ようするに、必要なとき、必要な分だけ届ければよい、という開発プロジェクトであれば問題にはなりません。

しかし、ソフトウェア開発プロジェクトは、定められた納期を遵守して製品を提供しなければなりません。
こうしたときには、
いかに作業を前倒して、早く作業を消化するか
が重要です。
この場合は、難しい作業が終わるまで、終了した簡単な作業とそれに続く作業を放置し続けることは、単なる無駄になってしまいます。

ようするに、作業を前倒しで進めてゆく、納期遵守のプロジェクトにおいて、最大の問題となる作業をボトルネックに据えてしまうと、

消化可能な作業もリリースができない状態で抱え込む、すなわち仕掛在庫になってしまう
最大の問題となる作業が超過すればするほど後段の作業が削られる
結果、最終段階のテストの時間が削られる/超過する

という事態を招きます。

WFにおいて、テスト不十分のままでソフトウェアがリリースされる、という背景の1つには、ソフトウェアベンダーはリリースしないとお金がもらえない、という経済的な背景があります。
ですので、ソフトウェアベンダーにとって、このとき最悪なのは、顧客と取り交わした納期に開発が間に合わず、すべての作業が仕掛在庫として無駄になったまま捨てられる、という事態です。
当然、顧客からの信用を失いますし、作業に投下した分の費用が回収できずに、赤字になってしまいます。

顧客としても、WFにおいて最終フェーズに位置するテストが終わらない限り、発注した機能が手にはいらない状態となります。
ですので、納期を守って製品を納品してもらおう、とします。
というのは、納期は、大抵、ビジネス的な制約から決められるからです。
たとえば、顧客が、「Webサイトからの製品購入ができるようにします」とプレス・リリースしてしまった場合、この期日を守って顧客の顧客にサービスが提供したい、と考えます。
(ま、開発前にプレス・リリースを流すようなマネはしないとおもいますが。。。)
また、社内システムでも、「この日までには、その機能がリリースされます」と約束する場合もあるでしょう。
このような場合、納期までにテスト十分されず、品質評価が不十分でも、顧客としては自分たちがサービスを提供する人々への約束を守るため、しぶしぶその製品のリリースを許可することもあるのです。

また、ソフトウェアベンダーにとって、このとき最悪な事態は、顧客にとっても最悪な事態です。
ソフトウェアベンダーとともに、自らが投入したリソースに見合うサービスが、まったく受けられないことになるのです。

こうした観点からは、アジャイル開発は有用な点があります。
それは、

1つのイテレーションが終了すれば顧客にとって優先順位の高い機能が提供されている可能性が高い

という点です。
アジャイルは、1週間、2週間ないしは1ヶ月といった一定期間をイテレーションと呼び、そのなかでシステムの一部の機能(といってよいのでしょうか?)をリリース可能な状態にするよう作業します。
このため、ソフトウェアベンダーと顧客にとって、リリースできない不完全な作業、すなわち仕掛在庫となるような作業は少なくなります。
また、イテレーションの中には、TDD(テスト駆動開発)やIC(継続的な統合)というプラクティスを導入することによって、

常にシステムをリリース可能な状態に保つ

という思想があります。
これを実践できれば、前段の作業の遅れによって削られてしまった時間の中で、納期にあわせるため駆け込み的にテストを行う、という事態は避けられます。
ひいては、品質確認がまったくなされていないソフトウェアを出荷しないで済むようになります。

今までの商習慣であれば、実はWFにおいても、作業が膨らめば顧客との話し合いによってリスケジュールが行われてきました。
しかも、顧客がリスケジュールによって追加してかかる費用を負担してきた、という歴史があります。
ようするに、なんとかしてWFをいびつな形に終わらせない、という努力を顧客とソフトウェアベンダーの双方してきたのです。
ですが、昨今は、両者の話が折り合いがつかず訴訟問題に発展する場合も、見受けられます。
双方の努力が限界を迎えつつある、ということのように私には思えます。

WFが理想の形で終わらない、という言葉には、ソフトウェア開発が抱えてきた問題が多く含まれている、そのように考え、受け止めるべきだと、あらためて思いました。

◆ワークショップは難しすぎた
Rothman氏のお話につづき、8人程度でチームをつくって大人用、子供用の2種類のモビールをつくる、というワークショップを行いました。
プロジェクトマネージャが1人、オブサーバーが1人、その他の人たちは開発者とテスターに分かれて、作業を行います。
一定時間(たしか、10分)がすぎたら作業を止め、作業の進捗と今後の作業にかかるであろう見積もりを報告する、これを3から4回(すみません、うろ覚えです)繰り返すというものです。
ようするに3~4回のイテレーションで、2種類のモビールを作ってみましょう、という課題です。
ちなみに、オブサーバーは、ワークショップの観察者で、ワークショップの中で参加者がどのような行動をとっていたか、という記録係を果たします。

・役割が不明確になると現場は混乱する?
第1イテレーションでは、開発者/テスターの役割を明確に分けて作業を行おうとしました。
しかし、テストを行おうにもその対象がないために、テスターの人は完全に手が空いてしまいます。
ですので、テスターの方もモビールの材料作り、飾りとなる色紙を切ったり、木の棒と輪ゴムでモビールの骨組みを作ったりという作業に参加することになりました。
こうすると、現場は、誰が、何をやっているか、ということが把握しづらくなります。
そのため、自分が今、何をやるべきか、という点が不明瞭になりがちです。
理想としては、開発者が早く材料を作り、作られた材料の品質チェックを随時、テスターが行う、という流れが作られるべきだったのでしょう。
しかし、材料作りが進みづらいために、テスターが材料作りに参加してしまい、結果、材料の品質チェックが十分に行えない、という状況が出来てしまったと思います。
これは、おそらくRothman氏が意図した状況ではなかったと思います。
とはいえ、クロスファンクショナル、という考え方においては、テスターが材料作りに参加する、という状況は正しかったのではないか、とも思っています。
単に、その状況下で、品質をチェックする、という作業をうまく組み込むことができなかっただけなのかもしれません。

・度胸が足りない
実は、私の参加したチームには、英語圏の方がメンバーとして2名、参加されていました。
が、この方たちとチームでまったくコミュニケーションが取れませんでした。
プロジェクトマネージャを担当された方のみが英語ができたので、その方のみが英語圏の方々とお話しする、という状況になっていました。
私はコミュニケーションを取ることにしり込みしてしまい、まったくお話ができませんでした。

言語の壁を越えて多くの人々とコミュニケーションとることを目的に、英語を勉強しよう、と考えているにもかかわらず、いざその機会を迎えてしり込みするのですから、なにをかおいわんや。

英語能力うんぬんではなく、自分のコミュニケーション能力を見直したほうがよいのではないか、と反省しました。
初対面の人と話すのは、大半の人は「怖い」という気持ちを抱きがちです。

相手がどんな人か分からないから、怖い
相手がどんなことをしてくるか分からないから、怖い
相手にいやな思いをさせて嫌われてしまうことが、怖い

こうした恐怖心を乗り越えるのは、簡単なことではありません。
しかし、「怖い」と思っているのは相手も一緒です。
だとすれば、まず自分から「怖い」という気持ちを捨てて話さないと何も始まりません。

この「怖い」という思いを捨てる度胸を身につけるために、英語を勉強するのでしょう。
だとすれば、洋書を読む、という以外にも英語圏の人たちと話す、という体験が必要になるはず。
そういう努力も今年はしたいと思います。

・クロスファンクショナルってなに?
なにより、面白いのは、結局、テスターも材料作りに参加してしまう、ということです。
というのは、作業が開始された時点では、品質チェックするものはなにもなく、どうしても手が空いてしまうためです。
ようするに、手持ち無沙汰な状況がすぐに生まれてしまうので、「なにかやらなきゃ」という気持ちが生まれ、部品の作成作業にかかわろう、という気持ちもまた、生まれるのです。
これをソフトウェア開発に、照らし合わせてみると、テスターという人にたちがWFでいうところの上流工程や開発工程に携わる、ということです。
そして、携わり方もクロスファンクショナルな、携わり方だった、といえるのではないか、と考えています。

私はテスターという立場で仕事をしたことがないので、想像でしかないのですが、テスターは、上流工程や開発工程から携わるとしても、平行して行うことが可能なテストを行っているのではないか、と思っています。
携わる工程や品質評価の対象がかわっても、やることはテスト作業だけ、というのでは、やはりクロスファンクショナルとは言いがたい、と思います。
私自身、最初はクロスファンクショナルとは、ある工程に複数の職責の人間が関わることだと思っていました。
ですが、Rothman氏の講義を受けて、クロスファンクショナルとは、工程などという大枠ではなく、

ひとつの成果物を生み出すために複数の能力をもった人々の視点を利用する

ということなのではないか、と思うようになりました。

詳細設計書を書く、というときに、テスターは詳細設計書の内容をチェックするチェックリストを作るのではなく、詳細設計書自体を書く。
そして、コードを書く、というときに、その時点のコードの内容をチェックするのではなく、テスターはコードを書く。
こうしたことをクロスファンクショナル、というのではないか、と思うようになったのです。

あるドメインのスペシャリストを集め、その人たちが自分のドメインについてのみ作業を行うことは悪いことではないでしょう。
しかし、それ以上にそのスペシャリストたちが、自らのドメインを超えてお互いの作業に関わりあうことがより、高い価値を生むのではないでしょうか。
それは、仮に、一人ひとりがスペシャリストでない場合を想定すれば、ドメインを超えてお互いの作業に関わりあうことで、複数の視点を利用して、作業の穴をふさぐ確率を上げることができる、と考えられるからです。
スペシャリストが参加した場合でも、その穴の指摘がより高次なレベルなだけ、なのだと思います。

クロスファンクショナル、という言葉がもつ意味が、私が思っているような意味ではないかもしれません。
また、ドメインを超えて作業に携わりあう、ということは、お互いの仕事に無知であると、単に現場が混乱するだけかもしれません。
なにより、PMや開発者、テスターなど開発に携わる人々が、互いのドメインに携われるスキルセットをもっていないと成立しません。

こうして考えると、クロスファンクショナルというのは理想論なのかもしれません、また、PMが開発やテスト作業をするべきなのか、という疑問もでてきます。
クロスファンクショナルチームがとるべき理想のバランス、それがいったいどのようなものなのか、これは今後も追求して行きたいと思います。

<LTはおもしろい!>
この日、最後に参加したセッションは、LT(ライトニング・トークス)です。
ここでも、コードの共同所有やTDDなど、アジャイル開発となじみの深いトピックスが、TLでも聞くことができました。
また、観客(?)として参加していた方々とお話ししたときも、「WFは限界が迎えていると思っている」という言葉を残された品質評価に関わるベテラン社員の方もいらっしゃいました。
ということで、ますます

アジャイルの流れがきてるなぁ

と都合のよく、品質管理における流れを解釈しました。

なによりも面白かったのは、歌、です。

いままで、多くのLTを見てきましたが、歌を聴いたのは初めてです。
柏原よしえさんの『春なのに』の替え歌で、『バグなのに』という歌でした。
詩の一部には、「バグなのにお別れですか」という一節がありました。
プロジェクトの終盤のテストでバグが発覚したのに、当の開発者はすでに別案件のプロジェクトに投入されている、という状況に直面したテスターの悲哀を歌い上げたものなのでしょう。
ですが、この状況は本当にあるんでしょうか。
だとしたら、誰が修正するんでしょうか。
かなり悲惨な状況ですよね。
自分がその状況におかれたら笑えませんが、そうした状況を歌にして笑い飛ばせるテスター、品質管理の人たちの器のでかさを感じることができました。笑

<気づき>
◆アジャイル的なアプローチで品質を作りこむ
アジャイル開発における、イテレーションという期限を設けたタイムボックスを用いた開発における特徴のひとつが、クロスファンクショナルチームがつくられる、という点にあると思います。
というのは、あるイテレーションごとに、WFでいうところの設計、開発、テストが詰め込まれるためです。
クロスファンクショナルという言葉について、正確な定義は知りません。
ですので、私見になりますが、クロスファンクショナルとは、

ある物事にたいして、複数の知識、視点が提供される

ことが重要なのだと思います。

ようする、チームとして一緒にいること、が重要なのではなく、同じ作業に複数の専門性をもった人びとが関わることが重要なのだと思うのです。
確かに、ある作業によっては、専門的な知識を持ったスペシャリストが行ったほうが早い、正確、という作業もあるでしょう。
また、すべての作業が複数の人間が関与することになると、個人ごとの意識やスキルセットによって、作業の質や方法にバラつきが発生する恐れもあります。
しかし、こうした状況に対処するときにこそ、スペシャリストの専門性が発揮されるべきなのです。
チームメンバーの作業が、早く、正確になるための成長を促すため、自らのスキルとプラクティス、知識を提供する。
また、チームメンバーにとって未知の状況においては、自らの専門性をもって指針となる。
クロスファンクショナルチームにおけるスペシャリストの役割は、そうしたものになると思います。

アジャイル開発では、各イテレーションにおいて開発されたシステムは、「リリース可能な」状態、品質であることが求められます。
この制約の元、各々のドメインにおける最高の知識を提供しあうクロスファンクショナルチームにより開発される製品の品質は、イテレーションごと磨きあげられてゆく、と期待できます。
これは、テスターというテスト、品質確認のスペシャリストが製品が開発される過程のすべてに関わることができている、という状況ができているからです。

WFでは、各段階を経て、最終的にテストが終了した時点で、その品質が「最高」であることが保証されます。
しかし、最終的に品質確認を行う、というのでは、テストは「品質を確認する」というだけの場で終わってしまいます。
品質が悪い点を発見できない、というのではなく、発見できても適切な修正を施せない、つまり、「修正を目的としてテストを行う」ということができない状況を生みがちです。

アジャイル開発においては、そうした点を念頭に置き、常にリリース可能な状態にシステムを保つ仕組みを取り入れようとしています。
アジャイル開発におけるテストは、「常にリリース可能な状態」を保つために行われるのであり、それは「バグの発見と修正」を目的としているのです。
テストコードを書いてからコードを書く、というTDDを開発に取り入れること。
さらに、CIを取り入れて一定期間で自動ビルドがなされる仕組みを開発に取り入れること。
こうした、常時システムをリリース可能な状態に保つための、テストにたいするアジャイル開発のアプローチは、かなり有効です。
また、イテレーションを組んだり、顧客を巻き込んだりするよりは、WFの開発現場にも取り入れやすいはずです。

私自身も、この点から徐々に社内にアジャイルのプラクティスを導入できるのではないか、と期待しています。

◆テスターが滝を上ろう、としている
開発者として、上記のようにTDDを取り入れたり、CIを取り入れたり、という品質チェックを開発段階に取り入れよう、と考えているのですが、この要請はテスター側からもあるようです。

よくコードのみならず、設計の不具合はすべてが「負債」といわれます。
WFでも要求定義段階や設計段階よりも、開発、テスト段階での不具合の修正が高くつく、といわれます。
それは、前段すべての作業を後戻りして、修正をしないといけないためです。
そのため、バグは早期に発見することが求められます。
早期に発見したほうが作業のて戻りが少なくすむためです。

逆に、バグがプロジェクトの最終段階になって発覚すると、その修正の手間は格段に増えてしまう。
早めに返せば(修正すれば)その分の手間は減り、返すのが遅くなればなるほど、その手間が増える。
こうしたバグの性質を捉えて、バグは「負債」にたとえられるのですが、問題はその負債を返す人が違う、もしくは完全に返しきれない、ということです。
私は、テスターという存在がいるプロジェクトに参加したことがありません。
ですので、実態はわかりませんが、LTの歌のように「バグなのにお別れ」の状態が本当に存在するのであれば、テスターはまったく自分が関与できない段階での負債をすべて背負い込む存在になってしまいます。
これは、本当につらく、精神衛生上も良くありません。
私がその状況に置かれたら、すくなくともPMから開発者まで前段の作業をやっていたすべての人が嫌いになるかもしれません。

なんであいつらのミスを俺がフォローしなきゃいけねーんだよ!

という気持ちが生まれそうです。

少なからずこうした経験をした方がいるのであれば、自分たちが上流工程から作業にかかわり、品質のチェックや改善を行いたい、と思っているのではないでしょうか。
そして、基調講演にアジャイル的なアプローチを推進するRothman氏が招聘されたり、自分が参加していたすべてのセッションでアジャイル開発への期待が聞けたり、という点から、私としてはテスターの人たちも下流工程から上流工程へ積極的に関わりたい、という意識が芽生え始めているのではないか、と思いました。
アジャイルのプラクティスである、TDDやCIを開発段階に取り入れることで、今までより早く、品質のチェック、バグの発見と修正をおこなうことができる。
こうした期待をテスターの方々も持っているのではないか、そのように感じました。

◆アジャイルなテスターを支援するアジャイルな開発者でありたい
アジャイル開発、もしくはそのプラクティスの一部を取り入れることで、よりシステムの品質は向上する、という期待が、私にはあります。
そして、テスター、品質管理に携わる人たちも、その期待をもっていると、JaSSTに参加して感じました。
ですが、Rothman氏いわく、テスターの側からも「アジャイルに振舞うことは、簡単ではない」とのことでした。
これは開発者と呼ばれる仕事をしている私も常々、感じることです。

受託開発に携わる以上、アジャイル開発はどのフェーズに所属する人でも、簡単に導入することはできません。
たとえ、開発組織の長であるPMや組織の長の社長が決断を下したとしても、最終的には、顧客の決断が必要になるからです。
なにより、今までの業務プロセスを大幅に変更する必要がある、という時点で、組織内に大きな影響を与えて、周囲を巻き込む必要があります。

そのような状況を想定して、なお、アジャイルなテスターであろう、という人がいたら是非、その人に協力したい、そのように私は思っています。
それは、アジャイル開発がしたいから、というのではなく、「品質の良い」システムをつくるためには、テスターというテストのスペシャリストが、開発の段階で携わっていて欲しいと感じているからです。
なによりも開発者である私自身が、テストの工程に目を向けて積極的にテストに関わるアジャイルな開発者として振舞いたいと思います。

<やりたいこと>
◆社内LT大会

LTのよさは、時間の短さに加えて質疑応答がないことなんですよ、とある方がおっしゃっていましたが、確かにツッコミがない、というのは気軽に話せてよいのかもしれません。
気軽でかつ、プレゼンの練習にもなるので、是非やってみたいと思います。
とくに社内でやれば気軽で、盛り上がりそうな気がします。

ゆくゆくは「LTに出たい、と思っているけど、なかなか勇気がでない」という方々に集まっていただき、プチLT大会を開くのも面白いかもしれません。

◆『FEARLESS CHANGE』を読む
Rothman氏のワークショップに参加し、英語ができないことの危機感を今まで以上に強く感じました。
また、「どうすればアジャイルな要素を会社やプロジェクトに取り入れることができますか」という質問を、ある方に質問したところ「『FEARLESS CHANGE』を読め」とのアドバイスをいただきました。
そもそも英語については、「読めない、書けない、しゃべれない」という意識が強すぎて、「読まない、書かない、しゃべらない」というのが今の私の状態だと思います。
今の苦手意識、忌避意識を少しでもなくすために、「英語を使う」という行為は一番、効果的だと思います。
そして、『FEARLESS CHANGE』には、自分が英語とは別に持っている問題意識を解決できる知恵が詰まっているのですから、さらに有効です。

本はすでに手元にあるので、少しずつ読み進めたい、と思います。

◆業務時間に勉強時間を組み込む
業務時間に勉強時間を組み込む、という考え方は、基調講演でRothman氏がお話されていたことです。
重要なことは、

定期的な時間として組み込む
業務に関係ない分野でも良い

ということだと思います。

就業後に勉強をする、というのはなかなか心理的なハードルが高い、と思います。
勉強したことが役に立つか否かもわかりませんし、なにより仕事の後はゆっくりとしたいものです。
このハードルを少しでも低くするために、一定の割合で勉強の時間を業務の時間として認めることが重要が有用だと思います。

「勉強したくない」という気持ちはよくわかりますし、現実、早く家に帰らねばならず就業後に勉強する時間が取れない、という状況も人によってはあります。
こうした人たちに業務時間内に勉強時間を用意することで、すこしでも勉強すること、新しい知識や情報を得ることの取っ掛かりになります。
また、業務に関係ない分野でも良い、とするのは、さらに心理的なハードルが下がるはずです。
私としては、それがITに関連していなくてもよい、と思っています。
そうすることで、社員たちは「自分のため」に勉強し始めるからです。
会社が、業務に関係がなければ勉強時間としては認めない、と勉強することに制限をかけてしまうと、社員たちは「会社のために勉強している」という意識を持ってしまいます。
「会社のため」という「やらされている」感覚では、「勉強をする」ということそのものにたいする心理的なハードルの高さはさがりません。
また、知識や情報の吸収の度合いも低くなるでしょう。

会社としても、受託開発をしているのであれば、他業種の業務ドメインの知識が必要になるときは、多いはずです。
会計、経理をはじめとして、小売り、通信販売、医療、法務などの知識を社員が自主的に身につけていた場合、そのドメインのシステムをつくるときには、その知識を利用することもできます。
なによりも、「自分たちのために会社が制度をつくってくれる」と社員たちが感じ取ってくれれば、社員たちは「会社を好き」になってくれるはずです。

こうしたことから、会社にとっても業務時間を一定の割合で社員の勉強時間として割く、というのは有用です。

会社には若干、働きかけてみましたが反応は微妙。
もう少し粘り強く交渉してみよう、と思います。

まぁ、長々と書いてしまいました。
しかも、後半、力尽きました。

うだうだとではなく、簡潔に。
今後は、そのように文章を書きたい、と思います。
自分でも読む気がおきない文章って、どうよ?ってな感じですし。

なお、TDDに関しては、アツい議論がtwitter上で交わされていたようです。
以下のURLでtogetterでのまとめが読めます。
http://togetter.com/li/5878

TDDとテストの関係、TDDは開発におけるテストなのか、はたまた設計なのか。
このエントリで書いた気づきや疑問もこの議論に集約されていくのかもしれません。

◆JaSST公式サイト
http://www.jasst.jp/

ランキング参加中。気に入ったら一押しお願いします!
人気ブログランキングへ

広告

タグ:

コメントを残す

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

WordPress.com ロゴ

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

Twitter 画像

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

Facebook の写真

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

Google+ フォト

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

%s と連携中


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