Downloaded 207 times
アジャイルテスト -高品質を追求するアジャイルチームにおけるテストの視点-
- 1. アジャイルテスト 高品質を追求するアジャイルチームにおけるテストの 高品質を追求するアジャイルチームにおけるテストの視点 するアジャイルチームにおけるテスト 18-C-3 増田 聡 ITアーキテクト 日本アイ・ビー・エム株式会社 テストマネジメント Developers Summit 2010
- 2. Agenda 1. はじめに 1. 自己紹介 2. セッション概要 3. 皆様にお伝えしたいこと 2. アジャイルテストとは 1. アジャイルテストの4象限 2. テストの視点から 3. 高品質を目指すチームのプラクティス 1. 重要な成功要因 4. アジャイルテストに取り組むチームへのアドバイス 1. チャレンジ 5. おわりに 2 Developers Summit 2010 18-C-3
- 3. １．はじめに １－１．自己紹介 所属 – 日本アイ・ビー・エム株式会社 グローバル・ビジネス・サービス テストマネジメント 経歴 – 日本アイ・ビー・エム株式会社入社。アプリケーション開発・保守部門において、新手法や 新技術、ツールの適用・展開などの技術支援業務に従事。 – テスト方法論、テスト技法、テストツールに専門的に取り組み、日本のプロジェクトにおいて 展開を行う。 – IBM のグローバルテスティングサービスの日本市場への展開業務に従事。現在、グロー バル・ビジネス・サービス事業において、テストコンサルティングなどのテスティングサービ スをお客様に提供をしている。 – 情報処理学会正会員、IEEE Computer Society 正会員、NPO法人ソフトウェアテスト技術 振興協会（ASTER）理事。 著作・翻訳 – 「ソフトウェアテストPRESS Vol.2」(2005年技術評論社) – 「プロジェクトマネジメントハンドブック」(2009年オーム社) 実践アジャイルテスト アジャイルテスト」 年翔泳社) – 「実践アジャイルテスト」(2009年翔泳社 年翔泳社 本日のセッションのきっかけ 本日のセッションのきっかけ 3 Developers Summit 2010 18-C-3
- 4. １．はじめに １－2．本セッションの概要 」 内容は実践的である 「Agile Testing」の内容は実践的である – 日々考えていることの答えやヒントが書かれてあった。 • 品質メトリクスを現場にいかに周知徹底していくかとい う検討会議の後に翻訳した部分が指標に関する部分 であった。 (=>5.2.3 指標でやってはならないこと) • テストのし易さについて議論した後に翻訳した部分が テストを考慮した設計であった。 (=>7.2.3 テストを考慮した設計) 原書：Agile Testing Addison-Wesley Professional; 1版 (2009/1/9) ISBN-10: 0321534468 セッション概要 セッション概要 – アジャイルテストとはアジャイルチームにおけるテストのこ と。 – アジャイルテストの４象限について。 – テストの視点からの紹介。 • アジャイルテストの実践的なポイント。 • 高品質を追求するチーム。 4 Developers Summit 2010 18-C-3 翔泳社 (2009/11/28) ISBN-10: 4798119970
- 5. １．はじめに １－３．皆様に伝えたいこと 「高品質を追求するアジャイルチームにおけるテストの視点」 1. アジャイルテストは、高品質なソフトウェア開発に重要な役割を担っている 2. アジャイルテストは、ビジネス面または技術面の軸とチームを支援する目的か製品を批評す る目的かの軸による４象限の分類で説明される 3. アジャイルテストのプラクティスがある – チーム全体アプローチ – 自動化 など 4. これからアジャイルテストに取り組むチームへのアドバイス – 文化的、チーム運営、プロセス移行へのチャレンジ プログラマの プログラマの視点 アジャイルチーム 従来型機能別チーム ビジネス ビジネス プログラマ プログラマ アナリスト アナリスト 機能別チームから テスター テスター アジャイルチームへ テスターの テスターの視点 5 Developers Summit 2010 18-C-3 ※「実践アジャイルテスト」(翔泳社)64ページ図4-1より引用
- 6. ２．アジャイルテストとは ２－１．従来型のテストの視点 従来型のテストの視点 – 従来型の開発・テストのモデル • 局面化開発モデル • V字モデル お客様のニーズ 客様の お客様ニーズの受入検証 実現機能 受入判定 検証 ビジネス目標・要件 ユーザー受入テスト 要件テスト プロダクションレビュー 検証 システム要件 システム統合テスト 要件テスト 静的テスト 静的テスト 検証 マクロ設計 システムテスト 設計テスト テスト実施レビュー 動的テスト 動的テスト 検証 マイクロ設計 統合テスト プログラミング 単体テスト 開発 Solutioning Macro Micro PG/UT IT ST SIT UAT チーム テスト 品質管理計画 テスト計画 テスト計画 テスト仕様書 テスト仕様書 テスト実施 テスト実施 受入 チーム 6 Developers Summit 2010 18-C-3
- 7. ２．アジャイルテストとは ２－１．従来型のテストの視点 従来型のテストの視点 メソドロジーとは – 標準 – 以下の3点が含まれる • IEEEなど 1. プロセス記述(WBS) – テストタイプ、テストレベル 2. ガイド – インシデント管理 3. 作成物サンプル – テストケース作成 • 網羅性 etc. 標準類 メソドロジー 組織標準、プロジェクト標準 コンセプト&用語 BS7925-1 作成物 WBS プロセス記述 ガイド ガイド 作成物 サンプル サンプル テストプロセス テスト文書 テーラリング テスト技法 IEEE 1008 UT IEEE 829 BS7925-2 IEEE 1012 V&V Test Document BS 7925-2 Component test メソドロジーを 作成・更新 作る側の視点 ツール適用エリア 事例 事例 標準 テクノロジー テストツール ベストプラクティス フィードバック 組織で活用するために メソドロジー化 7 Developers Summit 2010 18-C-3
- 8. ２．アジャイルテストとは ２－2．アジャイルテストの4象限 ビジネス面 自動と手動 手動 機能テスト 探索的テスト 例 シナリオ チ ストーリーテスト ユーザービリティテスト 製 ー プロトタイプ ユーザー受入テスト 品 ム アルファ/ベータ を を シミュレーション 支 批 第2象限 第3象限 評 援 第1象限 第4象限 す す る る パフォーマンス/負荷テスト 単体テスト セキュリティテスト コンポーネントテスト 「～性」テスト 自動 ツール 技術面 8 Developers Summit 2010 18-C-3 ※「実践アジャイルテスト」(翔泳社)96ページ図6-1より引用
- 9. ２．アジャイルテストとは ２－２．アジャイルテストの4象限 アジャイルテストは、ビジネス面または技術面の軸とチー ムを支援する目的か製品を批評する目的かの軸による４ 象限の分類で説明されている。 – 技術面：作る側の面 – ビジネス面： 出来上がったものを検証する面 ビジネス面 自動と手動 手動 – チームを支援する： チームの効率化の面 機能テスト 探索的テスト – 製品を批評する： 欠陥を探す面 例 シナリオ チ ストーリーテスト ユーザービリティテスト 製 ー プロトタイプ ユーザー受入テスト 品 各象限の概要は以下のとおり。 ム を シミュレーション アルファ/ベータ を – 第１象限はチームを支援する技術面のテスト 支 第2象限 第3象限 批 援 評 • テスト駆動開発などアジャイル開発の中心である。 第1象限 第4象限 す す – 第２象限はチームを支援するビジネス面のテスト る る パフォーマンス/負荷テスト • 顧客の視点からのハイレベルの機能テストなど。 単体テスト セキュリティテスト コンポーネントテスト – 第３象限は製品を批評するビジネス面のテスト 「～性」テスト • ユーザー受入テスト、探索的テストなど。 自動 ツール – 第４象限は技術面のテストを使った製品の批評 技術面 • パフォーマンステストやセキュリティテストなど。 ※この4象限のオリジナルはBrian Marickが作成した http://www.exampler.com/old-blog/2003/08/21/ 9 Developers Summit 2010 18-C-3 ※「実践アジャイルテスト」(翔泳社)96ページ図6-1より引用
- 10. ３．高品質を目指すチームのプラクティス (1/2) チーム全体 のアプローチを 取る チーム全体の アプローチを 1. チーム全体のアプローチを取る 全体 プログラマと一緒に座り、自ら会議に参加する。 プログラマと一緒に座り、自ら会議に参加する。 問題をチーム全体の問題としてとらえる。 問題をチーム全体の問題としてとらえる。 アジャイルテストの 考えを採用 する アジャイルテストの えを採用する 2. アジャイルテストの考えを採用する 採用 継続的により良い方法を探す。 継続的により良い方法を探す。 良い本やブログ、記事を読み、新しいアイデアやスキルを身につける。 良い本やブログ、記事を読み、新しいアイデアやスキルを身につける。 自動リグレッションテスト を適用する 自動リグレッションテストを 適用する 3. 自動リグレッションテストを適用する リグレッションテスト 自動リグレッションテストはチームの仕事である。テスターだけの仕事ではない。 自動リグレッションテストはチームの仕事である。テスターだけの仕事ではない。 シンプルに始める。自動スモークテストや自動単体テストだけでも効率化される。 シンプルに始める。自動スモークテストや自動単体テストだけでも効率化される。 フィードバックを 与え、受ける 4. フィードバックを与え、受ける フィードバックを フィードバックはアジャイルの中心的な価値である。 フィードバックはアジャイルの中心的な価値である。 反復計画会議と振り返りに十分な時間をかけて改善する方法を探る。 反復計画会議と振り返りに十分な時間をかけて改善する方法を探る。 10 Developers Summit 2010 18-C-3
- 11. ３．高品質を目指すチームのプラクティス (2/2) コアプラクティスの基礎を 築く 5. コアプラクティスの基礎を築く コアプラクティスの基礎を 1.継続的インテグレーションをする。 1.継続的インテグレーションをする。 2.テスト環境を管理する。 2.テスト環境を管理する。 3.技術的な負債(*1)を管理する。 3.技術的な負債(*1)を管理する。 4.段階的に作る。 4.段階的に作る。 5.コーディングとテストはひとつのプロセスとする。 5.コーディングとテストはひとつのプロセスとする。 6.各プラクティスの相乗効果を図る。 6.各プラクティスの相乗効果を図る。 顧客と共同作業する 6. 顧客と共同作業する 顧客と共同作業する テスターはまとめ役になる。 テスターはまとめ役になる。 広い視野を 持つ 7. 広い視野を持つ 視野を 現在のストーリーがビジネスの重要なスキームに合うか評価できるようにする 現在のストーリーがビジネスの重要なスキームに合うか評価できるようにする *1:技術的な負債(Technical Dept) ≒ 未解決の技術的な課題の累積 11 Developers Summit 2010 18-C-3
- 12. ４．アジャイルテストへの移行 従来型機能別チームからアジャイルチームへの移行の 従来型機能別チームからアジャイルチームへの移行のチャレンジ チームからアジャイルチームへの移行 組織的な3つのチャレンジ 1.文化的なチャレンジ 2.チームの運営のチャレンジ 3.プロセスの移行のチャレンジ プログラマの視点 アジャイルチーム 従来型機能別チーム ビジネス ビジネス プログラマ プログラマ アナリスト アナリスト 機能別チームから テスター テスター アジャイルチームへ テスターの視点 ※「実践アジャイルテスト」(翔泳社)64ページ図4-1より引用 12 Developers Summit 2010 18-C-3
- 13. ４．アジャイルテストへの移行 ４－１．文化的なチャレンジ 文化的なチャレンジ – 組織の文化 →味方を増やす – 適応のための阻害 →継続する – 変革の導入 →小さな成功を収める – 管理職の期待 →管理職の世界感の共有 – 変化は簡単ではない →体験させる 13 Developers Summit 2010 18-C-3 ※「実践アジャイルテスト」(翔泳社)37ページ図より引用
- 14. ４．アジャイルテストへの移行 ４－2．チーム運営 チーム運営 – チームの構成 →役割分担は必要 – 物の準備 →作業環境、ツールも重要 – 人材 →どのような人物がふさわしいか – チームの立ち上げ →情報共有、目標共有 14 Developers Summit 2010 18-C-3 ※「実践アジャイルテスト」(翔泳社)59ページ図より引用
- 15. ４．アジャイルテストへの移行 ４－2．プロセスの移行 プロセスの移行 – 軽量プロセスを探す →できることから始める – 指標を設定する →プラス思考になれる指標を設定する – 欠陥の追跡をする →ナレッジベースとして使う – テスト計画書を作成する →先のことを考えるとリスクが浮かび上がる – 既存のプロセスとモデル →従うべきプロセスもある 15 Developers Summit 2010 18-C-3 ※「実践アジャイルテスト」(翔泳社)73ページ図より引用
- 16. ４．アジャイルテストへの移行 アジャイルプロセスサポートツール RationalTeam Concertのご紹介 Rational Team Concert の概要 コラボレーションを じたソフトウエア開発の コラボレーションを通じたソフトウエア開発の実現 ソフトウエア開発 ワークアイテム管理を ワークアイテム管理を軸に、計画管理、構成管理、ビルド管理を 管理 計画管理、構成管理、ビルド管理を 管理 IBM Rational Team Concert 統合した 統合したしたAll-in-One製品 製品 – 成果物間に渡る、ワークアイテムを軸とした強力な追跡性、一 貫性 – プロジェクト全体をリアルタイムに可視化 – 分散並行開発を支えるソース管理 分散開発におけるチーム・コラボレーションを におけるチーム 分散開発におけるチーム・コラボレーションをサポート – Web2.0技術(wiki, chat, RSS)を統合し、円滑なコラボレーショ ンをサポート オープン＆スケーラブルな プラットフォーム上 オープン＆スケーラブルなJazzプラットフォーム上の製品 プラットフォーム – 既存資産、既存ツールとの連携が可能 – 幅広い開発環境、DB/アプリケーションサーバー環境をサポー ト 透明性 統合された表示 wiki オープン リ – 小規模から大規模へ、段階的にＲＴＣを適用可能 – オープンでコミュニティベースの開発モデル アルタイム・レポーティング チャット 引き継ぎの自動化 Web 2.0 ダッシュボード のカスタマイズ 拡張性 データ収集の自動化 Eclipseプラグイン サービス・アーキテクチャ 生 成の自由 16 Developers Summit 2010 18-C-3
- 17. ４．アジャイルテストへの移行 アジャイルプロセスサポートツール RationalTeam Concert (RTC)のご紹介 Rational Team Concertにより作業の可視化とワークフローを実現 ワークの登録、 ワークの登録、アサイン 設計、 設計、 トラッキング ビルド 実装、 実装、テスト 利害関係者 リーダー 開発者 ビルド担当者 ビルド担当者 ②アサイン見 アサイン見 積もり 全ての成果物を一元的 ④コンパイルし、 コンパイルし ①ワークアイテム ビルドを作成 ビルドを に管理。ワークアイテム 登録。 を登録。 ③開発＆テスト。 開発＆テスト。 実績値を入力。 実績値を入力。 駆動で、アサイン、見積 もり、トラックする 反復 反復 反復 計画管理 ワークアイテム管理 ワークアイテム管理 ソース管理 ソース管理 リリース管理 リリース管理 Rational Team Concert メンバー管理 - メンバー管理 自動データ収集＆レポート作成 データ収集 - 自動データ収集＆レポート作成 包括的なコラボレーティブ･ 包括的なコラボレーティブ･インフラストラクチャ 17 Developers Summit 2010 18-C-3
- 18. ４．アジャイルテストへの移行 アジャイルプロセスサポートツール Rational TeamConcert (RTC)のご紹介 Rational Team Concertによる進捗管理、作業の追跡 ワークアイテムに ワークアイテムに関 する履歴情報 する履歴情報 承認ログ ログも （承認ログも含む） 作業の 作業の一覧 進捗管理 ダッシュボードによ ダッシュボードによ 状況の る状況の把握 18 Developers Summit 2010 18-C-3
- 19. ５．おわりに 本日お伝えしたこと 「高品質を追求するアジャイルチームにおけるテストの視点」 1. アジャイルテストは、高品質なソフトウェア開発に重要な役割を担っている 1. アジャイルテストは、高品質なソフトウェア開発に重要な役割を担っている 2. アジャイルテストは、ビジネス面または技術面の軸とチームを支援する目的か製品を批評す 2. アジャイルテストは、ビジネス面または技術面の軸とチームを支援する目的か製品を批評す る目的かの軸による４象限の分類で説明される る目的かの軸による４象限の分類で説明される 3. アジャイルテストの実践的なポイントがある 3. アジャイルテストの実践的なポイントがある – チーム全体アプローチ – チーム全体アプローチ – 自動化 – 自動化 など など 4. これからアジャイルテストに取り組むチームのチャレンジ 4. これからアジャイルテストに取り組むチームのチャレンジ – 文化的、チーム運営、プロセス移行へのチャレンジ – 文化的、チーム運営、プロセス移行へのチャレンジ 19 Developers Summit 2010 18-C-3
- 20. 20 Developers Summit 2010 18-C-3
- 21. ワークショップ、セッション、および資料は、IBMまたはセッション発表者によって準備され、それぞれ独自の見解を反映したものです。それらは情報提供の目的のみで提供されてお り、いかなる参加者に対しても法律的またはその他の指導や助言を意図したものではなく、またそのような結果を生むものでもありません。本プレゼンテーションに含まれている情報 については、完全性と正確性を帰するよう努力しましたが、「現状のまま」提供され、明示または暗示にかかわらずいかなる保証も伴わないものとします。本プレゼンテーションまた はその他の資料の使用によって、あるいはその他の関連によって、いかなる損害が生じた場合も、IBMは責任を負わないものとします。 本プレゼンテーションに含まれている内容は、 IBMまたはそのサプライヤーやライセンス交付者からいかなる保証または表明を引きだすことを意図したものでも、IBMソフトウェアの使用を規定する適用ライセンス契約の条項を変 更することを意図したものでもなく、またそのような結果を生むものでもありません。 本プレゼンテーションでIBM製品、プログラム、またはサービスに言及していても、IBMが営業活動を行っているすべての国でそれらが使用可能であることを暗示するものではありま せん。本プレゼンテーションで言及している製品リリース日付や製品機能は、市場機会またはその他の要因に基づいてIBM独自の決定権をもっていつでも変更できるものとし、いか なる方法においても将来の製品または機能が使用可能になると確約することを意図したものではありません。本資料に含まれている内容は、参加者が開始する活動によって特定 の販売、売上高の向上、またはその他の結果が生じると述べる、または暗示することを意図したものでも、またそのような結果を生むものでもありません。 パフォーマンスは、管理された環境において標準的なIBMベンチマークを使用した測定と予測に基づいています。ユーザーが経験する実際のスループットやパフォーマンスは、 ユーザーのジョブ・ストリームにおけるマルチプログラミングの量、入出力構成、ストレージ構成、および処理されるワークロードなどの考慮事項を含む、数多くの要因に応じて変化し ます。したがって、個々のユーザーがここで述べられているものと同様の結果を得られると確約するものではありません。 記述されているすべてのお客様事例は、それらのお客様がどのようにIBM製品を使用したか、またそれらのお客様が達成した結果の実例として示されたものです。実際の環境コス トおよびパフォーマンス特性は、お客様ごとに異なる場合があります。 IBM、IBM ロゴ、ibm.com、AppScan、Build Forge、DOORS、Policy Tester、PurifyPlus、Rational、Rational Team Concert、Rhapsody、System i、System zは、 世界の多くの国で登録されたInternational Business Machines Corporationの商標です。 他の製品名およびサービス名等は、それぞれIBMまたは各社の商標である場合があります。 現時点での IBM の商標リストについては、www.ibm.com/legal/copytrade.shtmlをご覧ください。 Adobe, Adobeロゴ, PostScript, PostScriptロゴは、Adobe Systems Incorporatedの米国およびその他の国における登録商標または商標です。 IT Infrastructure Libraryは英国Office of Government Commerceの一部であるthe Central Computer and Telecommunications Agencyの登録商標です。 Intel, Intelロゴ, Intel Inside, Intel Insideロゴ, Intel Centrino, Intel Centrinoロゴ, Celeron, Intel Xeon, Intel SpeedStep, Itanium, Pentium は Intel Corporationまたは子会社の米国お よびその他の国における商標または登録商標です。 Linuxは、Linus Torvaldsの米国およびその他の国における登録商標です。 Microsoft, Windows, Windows NT および Windowsロゴは Microsoft Corporationの米国およびその他の国における商標です。 ITILは英国Office of Government Commerceの登録商標および共同体登録商標であって、米国特許商標庁にて登録されています。 UNIXはThe Open Groupの米国およびその他の国における登録商標です。 Cell Broadband Engineは、米国およびその他の国におけるSony Computer Entertainment, Inc.の商標であり、同社の許諾を受けて使用しています。 JavaおよびすべてのJava関連の商標およびロゴは Sun Microsystems, Inc.の米国およびその他の国における商標です。 他の会社名、製品名およびサービス名等はそれぞれ各社の商標。 21 Developers Summit 2010 18-C-3