Embedded Files
第8章 チームを支援するビジネス面のテスト (P.127)
8.1 ビジネス面のテストにより開発を推進する (P.128)
「ビジネス面のテストは、ビジネス要求を解決するもの」。「要求を例に基づいて表現するもの」。
「開発をガイドし、素早いフィードバックを提供することでチームを支援するもの」。
「コーディングが始まる前に各々のストーリーに対して記述され」「外部の品質を検証するもの」。
「いつ完了するかを知ることに役立ちます」。（ヤマモト）
第１象限との共通点は「開発チームへの素早いフィードバック」。異なる点は、第１象限が内部品質を保証するのに対し、第２象限は外部品質を検証する。（岩井）
現実の仕事で、受入テスト中のソフトが、受注CSVデータを読み飛ばすことがあって困っているが、これは第２象限の問題だろうか？第１象限か？（あな）
8.2 要求に対する悩み (P.130)
8.2.1 共通言語 (P.132)
P.132 「開発チームとビジネスエキスパートの双方に理解される共通言語を提供するために、テストを用いることができます。」なるほど。これは（中間生産物を省いているという意味で）アジャイルっぽいですね。（ヤマモト）
↑フロー図などの初期の要求モデルを元にテストを設計することで、モデル（フロー図などの）モデルに含む暗黙知を補完し、スコープが明確になっていくことを差しているのかな？と理解しました。（KENさん）
P.133 「顧客が完璧でなくても、顧客テストを書く際に顧客を巻き込むことで、ストーリーの範囲外の機能について気づく機会を与える事ができるのです。」 巻き込みは重要ですね。請負業務では実現する事は難しいですが。 (Ｙｏｕ＆Ｉ)
顧客に例を示してもらうことで、スコープの定義が明確になります。（例外ケースをどこまでスコープに含むか等）
⇒ユーザ試験の段階で「実はこんなケースがあるんだけど・・・」といったことを未然に防ぐ効果が期待できます。（岩井）
いつ、顧客テストを書くのか？がポイントだと思います。
開発のできるだけ、早い段階で高位の顧客テストを書いていければ、よりスコープへのFB効果が高いでしょうね。（KENさん）
8.2.2 要求を引き出す (P.133)
P.134 「最悪の事態のシナリオからはアイデアを得やすい」 最悪の事態が起こりうるものなのか、それとも実際には殆ど起こらないけどI/F仕様上は例外が飛ぶ可能性がケースなども含めて考えるのでしょうか。 (Ｙｏｕ＆Ｉ)
↑リスクベースドテストをイメージしました。起こりうる事態を、ビジネスインパクト/プロダクトインパクトに分け、発生率を検討し、最終的にテストの優先順位をつけていく方法です。
FTA/FMEAの簡易版です。（KENさん）
P.135 様々な立場からストーリーを抽出することで、思わぬ観点漏れ発見できそうです。（岩井）
P.136 「オズの魔法使いテスト」 何が言いたいのかサッパリ分からない。 (Ｙｏｕ＆Ｉ)
8.2.3 事前の明確性 (P.138)
プロダクトオーナーという役割を作り、要求の優先順位付けを一本化すると、やりやすくはなるけれど、要求を取りこぼすかもしれない、という問題提起だけがなされているのでしょうか？よくわからない...（ヤマモト）
8.2.4 達成の条件 (P.139)
アジャイル開発に限らないですが、完了条件を明確にして、ストーリーなりタスクなりが終了したかどうかが明確であることは重要、ということでしょうか。そして、ストーリーの達成条件には「より大きなシステムへの影響」を考慮するのを忘れないように、と。（ヤマモト）
受入基準を明らかにすることでリスク識別やタスク抽出に役立ち、正確な見積もりができる。（岩井）
8.2.5 波及効果 (P.140)
システムの機能の一覧を作成して、波及効果のチェックリストに使えと？うーん、（そういう中間生産物を作るのは）アジャイルらしくない気がしますが、有効な現実解なのかもしれません。（ヤマモト）
⇒逆に、これが無いと怖いですね。（岩井）
8.3 薄い断片、小さな塊 (P.141)
顧客テストを、ハッピーパスの端から端までをたどる「薄い断片」から書いていきましょう、と？（ヤマモト）
8.4 どのように完了を知るのか？ (P.144)
本当の完了はもっとさまざまなテストによる確認が必要だけれども、まずは第2象限のテストがパスしたかどうかで見ましょう、ということ？（ヤマモト）
8.5 テストはリスクを軽減する (P.145)
顧客テストでリスクを管理するとは、リスクをテストによって探索することができる、ということですか？（ヤマモト）
テストを書く＝リスクを抽出する、顧客に段階的に受入に参加してもらう＝＝リスクを軽減する と言ってます。（岩井）
P.146 現実味のあるテストデータを使うことは重要です。そのためにも顧客を巻き込むことが大事なのですね。（岩井）
8.6 テスタビリティと自動化 (P.147)
「技術面のテストのみを自動化するチームは、顧客の希望通りに動かないただのバグのないコードが作れるだけです。」表題とはズレちゃいますがいいこと言っていると思いました。（ヤマモト）
8.7 まとめ (P.148)
全般的に本章は読んでも内容が全く理解できなかった。文章を読んでも頭に入っていかない感じ。 (Ｙｏｕ＆Ｉ)
Page updated
Google Sites
Report abuse