『実践アジャイルテスト』第07章のコメント・疑問

第7章 チームを支援する技術面のテスト (P.107)

「第1象限は...チームを支援する技術面のテスト」。（山本）

7.1 アジャイルテストの基礎 (P.108)

P.108 「チームには、正しいツールとプロセスが必要で、それらによって、開発方法をガイドする技術面でのテストを作成して実行します。」 ここでのツールとは、バージョン管理システムや、自動ビルドの為のツールの事ですね。プロセスはCIやTDDが該当しますね。 (Ｙｏｕ＆Ｉ)

7.1.1 第1象限のテストの目的 (P.109)

第1象限のテストでは、ビジネス価値が提供できるかどうかという高次の議論ができるように、基本的な品質を確保します、という理解であってますか？（ヤマモト）

⇒ここでは「内部品質」という表現が使われていますね。（岩井）

P.109 「チームがTDDを実践すれば、以後に発見されるバグの数は最小化されます」 TDDをやらなかった時と比較すればバグの数は減りますが、最小化するかどうかそこまで影響しないと思います。ただ、実装してからテストするまでの時間を短くする事で、より早く不具合を修正するというのは分かります。 (Ｙｏｕ＆Ｉ)

アジャイル開発に限らず、テストを書くことで仕様に関する気づきを得たり、仕様上の矛盾や漏れを発見することがあります。

TDDでは、それを最初からやってしまおうと。（岩井）

7.1.2 インフラによる支援 (P.109)

単体テストの自動化、継続的インテグレーション、自動ビルドは、どのような開発スタイルであっても有用である、と。（ヤマモト）

P.110 「適切なツールや経験もなくコーディングをしている以上、～」 アジャイル開発をした事がないテスターの話だと思っていたのですが、コーディングだったりプロセスの話だったりと何の話をしているのか意図が分からない。 (Ｙｏｕ＆Ｉ)

〃 同じく、対偶表現すると、「タイムリーに高品質のコードを提供するには、適切な経験やツールが必要」となり、至極当たり前の表現となる。具体的な適切な経験やツールとは何だろうか。それがTDDと主張しているのだろうか。ウォーターフォールでもTDDでコーディングすれば問題ないといっているのか。（あな）

7.2 なぜこのテストを書いて実行するのか (P.110)

「単体レベルの欠陥をみつけることに、時間を簡単に費やす」のは惜しい、と。（ヤマモト）

7.2.1 より早く、より多くやりましょう (P.110)

P.110 「楽な方法を取れば、技術的な補完をしなければならず、いずれにしても期日に間に合わないでしょう。」 手抜きをしたら後になってしわ寄せがくるという事？それを補う為には技術的なものでカバーするという事？ (Ｙｏｕ＆Ｉ)

「テストファースト開発 vs. テスト駆動開発」 テストファースト開発の方が定義が緩いということでしょうか？（岩井）

7.2.2 テスターの仕事を簡単にする (P.112)

「なぜこのテスト（TDD？）を実行するのか」の下にこの章はあるので、「テスターの仕事を簡単にする」はその理由か手段にだと思われるが、この章の文章ではそれがよくわからない。

文章中にテスターという言葉がでてないのはなぜ？

テスターの仕事を簡単にするにはどうすればいいのかもわからない(あな）

7.2.3 テストを考慮した設計 (P.113)

P114コラム中ほど 「コードベースが階層間に密接に結合されている場合、・・、自動化テストの多くは統合テストで行うことになります。・・・統合テストは複雑ですばやくテストできません。」

時間がかかっても自動化できるのなら、それこそ有効では。（あな）

「多くの場合、システム全体が稼動することのみでテストが成りたちます」・・これって動けばOKというだけのテストしかしないという意味かしら（あな）

「また、ビジネス層は既存のデータベースへのアクセスを避けて擬似・・に対してテストされます。」・・・ 単体テストなら擬似でテストでいいと思うが、ビジネス層のロジックって例外処理が多いので擬似だですむのだろうか？ シナリオテストで×になってから、単体テスト項目を追加するのだろか（あな）

P.115 「新しいプロジェクトで、テストファーストのコード方法はより理解しやすいものです。」 レガシーコードとは異なり、新規の場合にはテストを前提に設計・実装が行われるからでしょうか？ (Ｙｏｕ＆Ｉ)

〃 テスト前提というよりは、階層構造での設計がされていることが多いのからでは？（あな）

ここら辺は、担当者(チーム)がテストが楽になる設計をすればテストが楽になるといっているだけの気がする。前からの主張に具体的な事例もふえてないので読む価値なさそう(あな）

P.116 「鍵はテストと品質に対するチーム全体のコミットメントです。」 テスト容易性を考慮した設計アプローチは、チーム全員が意識する必要があると思います。（岩井）

P115下コラム レガシーシステムのテスト

このコラムにあるような設計・実装・プロジェクトで作っているなら、そもそもレガシーシステムと言わない気がする。今後の開発の参考にするけど既存のレガシーシステムの改造には使えない(あな）

7.2.4 タイムリーなフィードバック (P.116)

P.117 「長時間かかるインテグレーションやデータベースアクセスのテストは、2次ビルドやテストのプロセスにまわしましょう」 2次ビルドって何だろう？ (Ｙｏｕ＆Ｉ)

• http://www.ibm.com/developerworks/jp/java/library/j-ap11297/

  • ビルドを実行するのに 10 分以上かかる場合、ビルド・パイプラインを確立して、誰かがコードをリポジトリーにコミットした後に初期の軽量なビルドが実行されるようにします。このビ ルドの「コミット」は、(理想として) 短時間のユニット・テストのコンパイルと実行などといった軽量のプロセスで構成されます。この初期ビルドが成功した上で 2 次ビルドを実行し、最初のプロセスよりも時間のかかるテスト、ソフトウェア検査、さらにはアプリケーション・サーバーへのデプロイを実行するというわけで す。

P117 リサの話

「ビルドが始まるたびにリファクタリングし、不要なテストを省き・・・、ビルドが早くなる」 ・・・ レスポンス向上のために昔必要だったテストを省いていいのか（あな）

最終段落は、具体的にどういう問題があってどう解決したのかよくわからない（あな）

7.3 どこで技術面のテストを止めるか？ (P.118)

表題の質問の答えになっていない気が...。第1象限のテストは第2象限のテストと目的が違うので、重複しても気にするなと言っているのでしょうか？（ヤマモト）

一方で、ビジネス面のテストにおいて単体テストレベルで自動化できるテストケースがあったら、できるだけ低いレベル（単体テスト？）に

落とし込んだ方が投資収益率が向上する、と言ってますね。第１象限と第２象限の境界線をどこに設定するか、ということが言いたいのでしょうか。（岩井）

7.4 チームがこれからのテストをしないと、どうなるでしょうか？ (P.119)

大事なことを言っている感じがるが日本語が下手すぎて、書いてあることがわからない。(あな）

7.4.1 テスターは何ができるか？ (P.119)

「テスターが単体テストを書くことは避けるべきです（なぜならプログラマーがコードを書く前に書くべきものだから）」うーん、これには賛同しかねます。TDDのユニットテストは確かにその通りでプログラマーが書くしかあり得ないと思います。しかし、単に単体テストと言うとき、それはユニットに対する網羅的で批評的な後付けのテストを意味する（文化もある）ので、その場合はテスターの出番があるかもしれないと思います。「TDDのユニットテスト」と「単体テスト」を同一視してよいかどうかは、論点になりやすいところだと思います。（ヤマモト）

上記の続きで 「TDDは実際のところ設計の活動で、～」 ここでの設計が外部設計なのかそれとも内部設計なのか。内部設計であるならコードを書いている人が考えるものですが、外部設計の場合はI/Fにも関わるので、コーダーだけの話ではない気がしますね。 (Ｙｏｕ＆Ｉ)

P.120 「マリー・リン・マンズとリンダ・ライジングの本『Fearless Change』」 リンダ・ライジングさんは今年の4月のAgile Japan 2011で来日、そしてFearless Changeをテーマに講演をされていました。その時の動画は必見です。 (Ｙｏｕ＆Ｉ)

• http://www.amazon.co.jp/dp/0201741571

  • http://d.hatena.ne.jp/wayaguchi/20110409/1302321264 (Fearless Change 第一章の非公式翻訳)

  • http://www.slideshare.net/hiranabe/linda-rising-on-fearless-change-at-agilejapan-2011 (Agile Japan 2011 講演資料)

  • http://www.youtube.com/watch?v=hOu4S-uv6lw (Agile Japan 2011 講演動画[1/2])

  • http://www.youtube.com/watch?v=vnAhvlzEDHo (Agile Japan 2011 講演動画[2/2])

7.4.2 テストマネージャーは何ができるのか？ (P.121)

テストマネージャーのできること⇒（１）品質がいかにビジネス価値を生むかをビジネスマネージャーに説明する。（２）自動化ツールやフレームワークの使い方を習得する時間を確保する。（岩井）

7.4.3 それはチームの問題です (P.121)

7.5 ツールキット (P.122)

7.5.1 ソースコード管理 (P.122)

「自動化テストと対応するコードバージョンを結びつけることは重要です。」（ヤマモト）

7.5.2 IDE(統合開発環境) (P.123)

「最も大事なことは、IDEはリファクタリングを支援することです。」（ヤマモト）

「同じIDEを使うことはが一般的に不可欠ではありません。」そうですか！（ヤマモト）

7.5.3 ビルドツール (P.124)

7.5.4 ビルド自動化ツール (P.124)

7.5.5 単体テストツール (P.125)

「GUIコードはテストファーストで開発できます。」 ・・・GUIこそ手動でテストするしかなく、完成してからのテストすると思っていましたが、どうやってテストファーストするのでしょうか？（あな）

7.6 まとめ (P.126)

４つめ「アジャイル・・」、５つめ「レガシー・・」はどこに書いてあった？ （あな）

７つめ「チームを・・」、こんなことは書いてないと思う （あな）