テスターとアジャイルチームのための実践ガイド 実践アジャイルテスト(榊原 彰 榊原 彰 榊原 彰 Lisa Crispin Janet Gregory 山腰 直樹 山腰 直樹 増田 聡 増田 聡 石橋 正章 石橋 正章)|翔泳社の本
  1. ホーム >
  2. 書籍 >
  3. テスターとアジャイルチームのための実践ガイド 実践アジャイルテスト

テスターとアジャイルチームのための実践ガイド 実践アジャイルテスト

監修
翻訳
原著


翻訳
原著
翻訳
原著
翻訳
原著

形式:
書籍
発売日:
ISBN:
9784798119977
定価:
5,280(本体4,800円+税10%)
仕様:
B5変・560ページ
カテゴリ:
開発管理
キーワード:
#開発環境,#開発手法,#プログラミング,#システム運用

ソフトウェア開発者が一番知りたかったプロジェクト成功へ導くテスト手法の数々

アジャイル開発の登場でソフトウェアテストの重要性が再認識されました。しかし、その方法を正しく理解している現場は多くありません。本書はアジャイル開発でのテスト(アジャイルテスト)では誰が何をすべきかを、担当者の役割などから実践的に解説します。これまで見逃されてきた“ユーザー視点によるテスト”に着目し、開発プロジェクトを成功に導く手法を紹介するなど、開発者にとって非常に価値の高い1冊になっています。

●第1部序章

第1章アジャイルテストとは 1.1アジャイルの価値 1.2「アジャイルテスト」とは? 1.3アジャイルチームにおける役割と作業 1.4アジャイルテイストは何が違うのか 1.5チーム全体アプローチ 1.6まとめ 第2章アジャイルテスターのための10の原則 2.1アジャイルテスターとは? 2.2アジャイルテキストの考え方 2.3アジャイルの原則と価値の適用 2.4継続的にフィードバックする 2.5付加価値を与える 2.6まとめ

●第2部組織的なチャレンジ

第3章文化的なチャレンジ 3.1組織の文化 3.2テスト/QAチームがアジャイルに適応するたもの阻害要因 3.3変革の導入 3.4管理職の期待 3.5変化は簡単ではない 3.6まとめ 3.7 第4章チームの運営 4.1チームの構成 4.2物の準備 4.3人材 4.4チームの立ち上げ 4.5まとめ 4.6 第5章典型的なプロセスの移行 5.1軽量プロセスを探す 5.2指標 5.3欠陥の追跡 5.4手巣地計画書 5.5既存のプロセスとモデル 5.6まとめ

●第3部アジャイルテストの4象限

第6章テストの目的 6.1アジャイルテストの4象限 6.2ストーリーがいつ終わるのかを知る 6.3技術的な負債を管理する 6.4コンテキストのテスト 6.5まとめ 第7章チームを支援する技術面のテスト 7.1アジャイルテストの基礎 7.2なぜこのテストを書いて実行するのか 7.3どこで技術面のテストを止めるか? 7.4チームがこれらのテストをしないと、どうなるでしょうか? 7.5ツールキット 7.6まとめ 第8章チームを支援するビジネス面のテスト 8.1ビジネス面のテストにより開発を推進する 8.2要求に関する悩み 8.3薄い断片、小さな塊 8.4どのように完了を知るのか? 8.5テストはリスクを軽減する 8.6テスタビリティと自動化 8.7まとめ 第9章チームを支援するビジネス面のテストのためのツールキット 9.1ビジネス面のテストのテストツール戦略 9.2例よ要求を引き出すためのツール 9.3例に基づくテスト自動化用のツール 9.4テストを記述するための戦略 9.5テスタビリティ 9.6テスト管理 9.7まとめ 第10章製品を批評するビジネス面のテスト 10.1第3象限への導入 10.2デモ 10.3シナリオテスト 10.4探索的テスト 10.5ユーザビリティテスト 10.6GUIの裏側 10.7文書のテストと文書化 10.8探索的テストを補助するツール 10.9まとめ 第11章技術面のテストを使った製品の批評 11.1第4象限の紹介 11.2誰がやるのか? 11.3いつやるのか? 11.4「~性」テスト 11.5パフォーマンステスト、負荷テスト、ストレステスト、拡張性テスト 11.6まとめ 第12章テストの4象限のまとめ 12.1テストの4象限のレビュー 12.2システムテストの例 12.3テスト駆動開発(TDD) 12.4自動化 12.5ビジネス面の手宇土で製品を批評する 12.6文書化 12.7アジャイルテストの4象限を使う 12.8まとめ

●第4部自動化

第13章なぜテストを自動化したいのか、何が阻害するのか? 13.1なぜ自動化するのか? 13.2自動化を妨げる障害 13.3障害を克服できるのか? 13.4まとめ 第14章アジャイルテストの自動化戦略 14.1テスト自動化のためにアジャイルのアプローチ 14.2何を自動化できるか? 14.3何を自動化すべきでないか? 14.4何が自動化しにくいのか? 14.5自動化の戦略を立てる―どこから始めるべきか? 14.6テスト自動化にアジャイルの原則を適用する 14.7テストのためにデータを提供する 14.8自動化ツールを評価する 14.9自動化を実現する 14.10自動化されたテストを管理する 14.11始めましょう 14.12まとめ

●第5部テスター活動における反復

第15章リリースやテーマ計画におけるテスターの作業 15.1リリース計画の目的 15.2持つ森 15.3優先順位付け 15.4スコープは何か? 15.5テスト計画 15.6テスト計画の代替案 15.7可視化のための準備 15.8まとめ 第16章順調なスタートを切る 16.1積極的になろう 16.2事前の明確性 16.3例(サンプル) 16.4テスト戦略 16.5欠陥の優先順位付け 16.6リソース 16.7まとめ 第17章反復のキックオフ 17.1反復計画 17.2テスト可能なストーリー 17.3顧客との共同作業 17.4概要レベルのテストと例 第18章コーディングとテスト 18.1開発を推進する 18.2製品を批評するテスト 18.3プログラマとの共同作業 18.4顧客に話しかける 18.5テストのタスクを完了する 18.6バグに対処する 18.7選択のすべて 18.8コミュニケーションを促進する 18.9リソース 18.10反復指標 18.11まとめ 第19章反復のまとめ 19.1反復のデモ 19.2振り返り 19.3成功を祝う 19.4まとめ 第20章成功裡にデリバリーする 20.1製品は何によって作られるか? 20.2テストに十分な時間を計画する 20.3エンドゲーム 20.4顧客テスト 20.5開発後のテストサイクル 20.6提出物 20.7製品のリリース 20.8顧客の期待 20.9まとめ

●第6部まとめ

第21章重要な成功要因 21.1成功要因1:チーム全体のアプローチを取る 21.2成功要因2:アジャイルテストの考え方を採用する 21.3成功要因3:自動リグレッションテスト 21.4成功要因4:フィードバックを与え、受ける 21.5成功要因5:コンプラクティスの基礎を築く 21.6成功要因6:顧客と共同作業する 21.7成功要因7:広い視野をもつ 21.8まとめ

本書は付属データの提供はございません。

お問い合わせ

内容についてのお問い合わせは、正誤表、追加情報をご確認後に、お送りいただくようお願いいたします。

正誤表、追加情報に掲載されていない書籍内容へのお問い合わせや
その他書籍に関するお問い合わせは、書籍のお問い合わせフォームからお送りください。

利用許諾に関するお問い合わせ

本書の書影(表紙画像)をご利用になりたい場合は書影許諾申請フォームから申請をお願いいたします。
書影(表紙画像)以外のご利用については、こちらからお問い合わせください。

追加情報はありません。

ご購入いただいた書籍の種類を選択してください。

書籍の刷数を選択してください。

刷数は奥付(書籍の最終ページ)に記載されています。

現在表示されている正誤表の対象書籍

書籍の種類:

書籍の刷数:

本書に誤りまたは不十分な記述がありました。下記のとおり訂正し、お詫び申し上げます。

対象の書籍は正誤表がありません。

最終更新日:2013年09月17日
発生刷 ページ数 書籍改訂刷 電子書籍訂正 内容 登録日
1刷 079
下から8行目
欠陥追跡システム(DTS)
欠陥追跡システム(Defect Tracking System:DTS)
2013.09.02
1刷 087
下から2行目
何か修正されることを知っています。
何が修正されることを知っています。
2013.09.02
1刷 104
2行目
単体レベルの障害
単体レベルの欠陥
2013.09.17
1刷 109
「7.1.1 第1象限のテストの目的」16~17行目
テスト駆動開発は、理解していない人にはテストではなく設計のことを言っていると誤解されてしまいます
「テスト駆動開発」という言葉は、それがテストよりもむしろ設計に関するものであるということを理解していない人に誤解を与えます。
2010.09.15
1刷 110
3行目
エラーを引き起こした
障害を引き起こした
2013.09.17
1刷 110
下から5行目
エラーをチームに
障害をチームに
2013.09.17
1刷 116
下から6行目
単体テストエラー
単体テストの失敗
2013.09.17
1刷 167
下から2行目
失敗や例外
障害や例外
2013.09.17
1刷 201
5行目
コンテキスト駆動スクール
コンテキスト駆動流派
2013.09.02
1刷 21
19行目
異常を起こしそうな
障害を起こしそうな
2013.09.17
1刷 237
18行目
故障
障害
2013.09.17
1刷 260
26行目
退化の問題
退行の欠陥
2013.09.17
1刷 285
2行目
将来失敗するリスク
将来の障害リスク
2013.09.17
1刷 292
7行目
バグを見つける
欠陥を見つける
2013.09.17
1刷 327
第5部の部見出し
第5部 テスターの活動における反復
第5部 テスター視点での反復
2013.09.02
1刷 327
3行目
「まだ何もテストする準備ができていない時にどのような反復テストをするのですか?」
「まだ何もテストする準備ができていない最初の反復時にテスターは何をするのですか?」
2013.09.02
1刷 327
18行目
指標や障害対応
指標や欠陥対応
2013.09.17
1刷 384
10行目
もう1つの従来の計画会議の要素は、軽食でした。
もう1つの伝統的な計画会議の要素は、軽食をとりながら行うことです。
2013.09.02
1刷 385
下から15行目
「スコープにいつの間にか入り込んでくるもの」
「スコープ・クリープ(スコープにいつの間にか入り込んでくるもの)」
2013.09.02
1刷 392
下から5行目
あるいは不明でさらに調査が必要なタスクは、余分に1つか2つタスクカードを書き、
あるいは、不明もしくはさらに調査が必要なタスクは、1つか2つの余分なストーリーをタスクカードに書き、
2013.09.02
1刷 395
下から9行目
ファンクショナルアナリストのような顧客の代表者
ファンクショナルアナリストのような顧客の代理人
2013.09.02
1刷 398
10行目
これまで話したほとんどのアジャイルチームは、彼らの一番の問題は、それぞれのストーリーを十分に理解して、顧客が望むように作ることだと言っています。
各ストーリーを十分に理解して顧客の要求に必要十分答えるものを提供することが最大の問題である、とこれまで話したほとんどのアジャイルチームが言っています。
2013.09.02
1刷 399
18行目
ダイレクトなコミュニケーションが最も大事です。
直接のコミュニケーションが常に最善の方法です。
2013.09.02
1刷 400
下から3行目
テストを含む文書
テストを含む有用な文書
2013.09.02
1刷 401
11行目
要求定義書なしにはできません。
このような修正は要求定義書ではできません。
2013.09.02
1刷 401
12行目
必ずしも簡単ではありません。
一筋縄にはいきません。
2013.09.02
1刷 403
図の左下
それは障害か、機能か?
それは欠陥か、機能か?
2013.09.17
1刷 405
15行目
極端な部分へ
直ちに極端な部分へ
2013.09.02
1刷 410
16行目
このテストを延期しないで下さい。
このテストを先送りしないで下さい。
2013.09.02
1刷 414
10~12行目
 リサのチームのプログラマは、単体テストや結合テストのほかに、定期的にGUIの裏で動くテストを自動化します。彼らはGUIの裏で動く機能テストケースも書きます。時には、彼らは最初の簡単で実行可能なテストを書きます。そして、テストと
 リサのチームのプログラマ達は、単体テストや結合テストのほかに、定期的にGUIの裏で動くテストを自動化します。彼らはGUIの裏で動く機能テストケースも書き、時には最初の正常パスで実行可能なテストケースもを書きます。場合によっては、テストと
2013.09.02
1刷 415
12行目
18.6.1 それは障害か、機能か?
18.6.1 それは欠陥か、機能か?
2013.09.02
1刷 415
12行目
18.6.1 それは障害か、機能か?
18.6.1 それは欠陥か、機能か?
2013.09.17
1刷 416
下から4行目
不完全な反復の危険をさらす
不完全な反復の危険にさらす
2013.09.02
1刷 416
下から1行目
修正の可能性が高くなったでしょう。
手戻りの可能性が大きくなったでしょう。
2013.09.02
1刷 417
7行目
ほかに、
それでも、
2013.09.02
1刷 417
下から6行目
問題の警鐘となります。
すぐ修正すべき警告となります。
2013.09.02
1刷 417
下から9行目、10行目
エラー
障害
2013.09.04
1刷 417
10行目、11行目、14行目、16行目
エラー
障害
2013.09.17
1刷 418
下から13行目
乗せるのがいいかもしれません。
乗せるのがリマインダーとしていいかもしれません。
2013.09.02
1刷 418
下から8行目
プログラマは別のストーリーに移り、すべてをいま修正することができません。
プログラマは別のストーリーに移るため、修正のためにすべてを投げ出すことはできません。
2013.09.02
1刷 418
下から6行目
ストーリーとして扱われる必要があり、将来の反復のために見積もられ、
ストーリーとして扱われる必要があり、そのストーリーは将来の反復のために見積もられ、
2013.09.02
1刷 418
4行目
一方、エラーは

一方、障害は
2013.09.17
1刷 419
4行目
稀であるため、
絶対ないため、
2013.09.02
1刷 419
12行目および13行目
選択は、
トリアージ(選択)は、
2013.09.02
1刷 419
下から4行目
欠陥のインベントリー
欠陥の在庫
2013.09.04
1刷 420
1行目
局面方法論ベース
局面化方法論ベース
2013.09.02
1刷 420
3行目
欠陥が新しい機能を開発中に見つかる場合、あるいは他のバグの修正で見つかる副作用である場合は、自動的に修正されるべきです。
新しい機能を開発中に発見された欠陥である場合、あるいは他のバグの修正で発生する副作用である場合は、反射的に修正されるべきです。
2013.09.02
1刷 420
11行目
少ないかもしれませんが、
かなり大きいかもしれませんが、
2013.09.02
1刷 420
15行目、19行目
バグ
欠陥
2013.09.02
1刷 420
23行目
もしあなたの選択がこの場合は、
もしあなたのトリアージ(選択)がこの場合は、
2013.09.02
1刷 420
下から1行目から、P.421の2行目まで
 多くのオプションがありますが、他人が問題を再生させるため、あるいは、プログラマが修正する準備ができた時に議論できるために、十分な情報を含んでいることをお勧めします。
 いろいろな手段がありますが、お勧めは他人が問題を再現するようガイドできたり、修正の準備が整った際に議論に集中できるように、十分な情報を含んでいるものを選ぶことです。
2013.09.02
1刷 420
15行目
バグの対応はチームによって異なります。あるチームは、見つかったバグは
欠陥の対応はチームによって異なります。あるチームは、見つかった欠陥は
2013.09.17
1刷 420
19行目
あなたのチームはバグを見つけましたが、
あなたのチームは欠陥を見つけましたが、
2013.09.17
1刷 421
19行目
テストなしではバグは修正されないという、ルール
テストなしではバグは修正されないというルール
2013.09.02
1刷 426
下から8行目
リサは、彼女がwikiに欲しいすべてのテストと例を書くことができることを知っていますが、もし誰も読むのに困らなければ、彼らは助けてくれません。
リサは、リサが求むすべてのテストと例をwikiに書くことができますが、もし誰も読まなければテストや例は役に立ちません。
2013.09.02
1刷 427
27行目
テスターはバグが多すぎたので、バグが記録され
テスターは欠陥が多すぎたので、欠陥が記録され
2013.09.17
1刷 430
下から3行目
価値がないことが分かりました。
かけがえのないものであることが分かりました。
2013.09.02
1刷 430
6行目
そのエラーを
その障害を
2013.09.17
1刷 433
2行目
ハードウェアリリース日
確実なリリース日
2013.09.02
1刷 433
下から11行目
「難しい」要求とコーディング局面
「確実に」要求局面とコーディング局面
2013.09.02
1刷 433
下から2行目
コーディングやテスト局面では傷害を追跡
コーディングやテスト局面では障害を追跡
2013.09.02
1刷 435
下から13行目
統計分析ツール
静的解析ツール
2013.09.02
1刷 439
下から4行目
テスターは反復のレビューを行います。
テスターが反復のレビューを運営します。
2013.09.03
1刷 444
下から8行目
Scrumマスターは妨げとなっているバックログを維持し、
Scrumマスターは障害リストを維持し、
2013.09.03
1刷 445
欄外
脚注を444ページの欄外下側に移動
2013.09.03
1刷 450
9行目
何年もかけて彼はその業界で非常に良い評判を得ていましたが、潜在顧客が彼が忙しいからという理由で断ってしまいました。
何年もかけて彼はその業界で非常に良い評判を得ていました。忙しいという理由で潜在顧客を断っていたほどです。
2013.09.03
1刷 450
下から5行目、6行目、7行目
フィットアンドフィッシュ
フィットアンドフィニッシュ
2013.09.04
1刷 450
下から5~7行目
フィットアンドフィッシュ
フィットアンドフィニッシュ
2013.09.17
1刷 451
下から10行目
『導管』
ガイド
2013.09.03
1刷 452
5行目
「厳しい」反復に頼るチームもあります。
「安定化」の反復過程に頼ってしまうチームもあります。
2013.09.03
1刷 457
下から16行目
そしてシステム特性を他のシステムに「回す」ように利用しましょう。
そしてシステム特性をどちらかに「切り替え」られるシステム特性にしておきましょう。
2013.09.03
1刷 459
14行目
それでも、滅茶苦茶な時は滅茶苦茶な方法でやってしまいます。
それでも、背に腹はかえられません。
2013.09.03
1刷 468
表20-1内
基本的なチームワーク製品
製品開発における基本的なチームの活動
2013.09.03
1刷 468
表20-1内
出来具合基準
出来具合の基準
2013.09.03
1刷 469
18行目
リリース候補の失敗を
リリース候補の障害を
2013.09.17
1刷 79
下から2行目
エラーを見せ
障害を見せ
2013.09.17

感想・レビュー

もりけい さん

2015-03-08

テストに絞った内容で、特にテストタイプを支援と批判、ビジネスと技術の4象限に分けた図と原理原則が役に立ちました。ウォーターフォールで開発している方でも本書の内容を適用できるところが多々あります。

pragma さん

2010-09-06

 アジャイル開発におけるテスターの役割を明確に定義した価値ある一冊です。 プログラマ目線のテスト(TDD等)について書かれた書籍は色々とありますが、 テスター目線というのが新鮮で参考になりました。 ビジネス面のテストというのがテスターのキーワードだと感じました。  本書では、テストの目的をハッキリさせるために「アジャイルテストの4象限」 という考え方が紹介されています。 ・単体テスト ・機能テスト ・探索的テスト ・パフォーマンス/負荷テスト この考え方が非常に分かりやすく参考になりました。  前提知

nashcft さん

2016-04-25

テスターの視点からアジャイル開発のプロセスを俯瞰する。メインはアジャイル開発の各プロセスにおけるテスターの役割やテストの手法についてだが、それぞれの場面で開発者やマネージャ、顧客とどのように連携するのかについても言及されているので、テスター以外のメンバーが読むことでどのようにテストを開発プロセスの中に組み込んでいけば良いかを知ることもできる。翻訳書としては文の体をないしていない文が結構あって酷く読みにくい。原著を当たらないと意味が取れないようなところもあるので素直に原著を読んだ方が良い。