Embedded Files
第9章 チームを支援するビジネス面のテストのためのツールキット（P151）
「何をコーディングすればよいかをプログラマが知る」必要があり、そのために「対面の会話は、常に最善の方法」ですが、常にそれが可能とは限らないので、「ビジネス面のテスト」を利用します、という理解でOK？（ヤマモト）
アジャイル開発が一般的になると、テストを記述するのに役立つツールも多くなる。但しツールを利用する場合、目的に応じたものを利用し、ツールありきで作業を進めるべきではない。という事でしょうか。 (Ｙｏｕ＆Ｉ)
リサの話から、異なるレベル(＝テストの粒度？)のテストケース記述を事前に調査しておき、場面場面でそれらの成果を利用する事が有用である。 (Ｙｏｕ＆Ｉ)
9.1 ビジネス面のテストのテストツール戦略（P152）
アジャイル開発では「ユーザーストーリー」を要求記述のために使いますが、それは簡易的なものでその先の会話の出発点として用いる、と。
そして詳細を掘り下げていくためのツールとして、チェックリストやマインドマップ等のツールを用いる、と？（ヤマモト）
ユーザーストーリーの”あるべき姿”がイメージできなくてここの記述が理解できませんでした。。。（KENさん）
P23 に、「追加機能に対してだれでも疑問を呈することはできますが、テスターはストリーへの影響に良くきづきます。」とあるので
機能と、ストーリー（や顧客の価値）が剥離しないように提言していくのが役割の一つになるのかなぁ（KEN）
9.2 例と要求を引き出すためのツール（P153）
ここで言っているのは、ストーリーは詳細過ぎても良くない、ということでしょうか？（岩井）
※「会話の開始点」、「正しいサイズ」、「資源の無駄遣い」、、、
9.2.1 チェックリスト（P154）
9.2.2 マインドマップ（P156）
ここでは発想の発散のツールとしてマインドマップが使われている模様。それとは異なり、スキーマーを決めておいて埋めていくような使い方もありえますね。（ヤマモト）
⇒よくあるパターンを雛形として使いまわすことができれば工数の削減にもなると思います。ただそのスキーマが硬直化してしまわないよう留意する必要はあるかと。（岩井）
9.2.3 スプレッドシート（P157）
これをこじらせると、Excel方眼紙になってしまうんでしょうね。 (Ｙｏｕ＆Ｉ)
9.2.4 モックアップ（P158）
ペーパープロトタイピングは引き出しのツールであると同時にテスト（前述のオズの魔法使い）でもあると？（ヤマモト）
9.2.5 フロー図（P159）
フロー図は詳細になりすぎ膨大になったりしないように注意して使う必要がある気がします。（ヤマモト）
9.2.6 ソフトウェアベースツール（P161）
9.3 例に基づくテスト自動化用のツール（P1６３）
「理解しやすいドメイン言語と適切なフィクスチャが提供され」、つまりテストを記述しやすくて、構造化が容易であることが、テストツールには重要ということかな。（ヤマモト）
P.166 シナリオに名前が付けられるのは良い。（岩井）
9.3.1 GUIおよびAPIの下位レベルをテストするためのツール（P163）
P.168 「FitNesse」「FitNese」「FitNess」と表記ぶれ。 (Ｙｏｕ＆Ｉ)
9.3.2 GUIテストのためのツール（P169）
P.169 「学習曲線は険しいので、パフォーマンステストと負荷テストに・・・」の部分が意味わかりません。（岩井）
P.171 「・価格が適正です。」テストツールって高価格なイメージがあります。 (Ｙｏｕ＆Ｉ)
P.171 「XPath」って何でしょう？さも当たり前の用語として扱われていますね。 (Ｙｏｕ＆Ｉ)
P.173 「ジャネットの話」 変数名等をIDEが生成するデフォルトのものを使ったままコミットして放置、後で同じ名前ばかりになって変更するという流れでしょうか。 (Ｙｏｕ＆Ｉ)
9.4 テストを記述するための戦略（P177）
9.4.1 段階的にビルドテストを行う（P178）
最も明確なユースケースをまず優先してテストし、徐々にテストケースを追加していきましょう、という理解であっていますか？（ヤマモト）
開発者が「振る舞いを正しく理解しているかどうかの確認」が目的ということですね。まさに「チームを支援するビジネス面のテスト」（岩井）
9.4.2 テストを成功させ続ける（P179）
P.179 リサの話「だが、テスターはそうである！」 テストは一時的なものではない。テスターは一時的な物という事？ (Ｙｏｕ＆Ｉ)
テスターはロールであってアジャイルプロジェクトにおいては開発者が被る帽子のひとつだ（だからといってテストを一過性のものと考えてはいけない）ということを強調したかったんですかね。よく分かりませんね。（ヤマモト）
コードの変更⇒テストへの反映⇒再テスト を繰り返し継続する、ということを言っているのは理解できました。（岩井）
9.4.3 適切なテストのデザインパターンを用いる（P179）
「構成/動作/確認」「時間依存、活動、イベント」といったパターンがテストには現れるので、それを知っていると手早くよいテストが書けますよ。書籍を読んだり自分達の資産を見直すことでパターンを学びましょう、ということかな。（ヤマモト）
P.181 ローン計算の例ですが、「on 01-30-2006」のところを操作することで、日付依存のテストケースをシミュレートするのでしょうか？（岩井）
9.4.4 キーワードとデータ駆動テスト（P182）
データ駆動テストは、値だけが異なる沢山のテストケースを構造化するための手法という理解です。キーワード駆動テストってのはよく分からない。どなたかわかりますか？（ヤマモト）
9.5 テスタビリティ（テスト容易性）（P183）
基本は、テストを意識すればテストしやすく作ることになるはず、ということと思います。（ヤマモト）
9.5.1 コードの設計とテストの設計（P184）
「コードの設計とテストの設計は完全に独立してます」がピンときません。相互に深く関係しあっています、なら分かるのですが。。。（ヤマモト）
9.5.2 自動化vs.第2象限の手動テスト（P185）
良く理解できませんでした。第２象限のテストでは手動テストに深入りするな、ということでしょうか？（岩井）
9.6 テスト管理（P186）
「テストはソースコード管理に含まれるべき」まったくその通りだと思います。ソースコード管理に含まれたテストは、生き残ります。（ヤマモト）
9.7 まとめ（P186）
Page updated
Google Sites
Report abuse