アジャイルテスト ...
DESCRIPTION
TRANSCRIPT
Developers Summit 2010
増田増田増田増田増田増田増田増田 聡聡聡聡聡聡聡聡ITITアーキテクトアーキテクト
日本アイ・ビー・エム株式会社日本アイ・ビー・エム株式会社
テストマネジメントテストマネジメント
18-C-3
アジャイルテストアジャイルテストアジャイルテストアジャイルテストアジャイルテストアジャイルテストアジャイルテストアジャイルテスト
高品質高品質高品質高品質をををを追求追求追求追求するするするするアジャイルチームアジャイルチームアジャイルチームアジャイルチームにおけるにおけるにおけるにおけるテストテストテストテストのののの視点視点視点視点高品質高品質高品質高品質をををを追求追求追求追求するするするするアジャイルチームアジャイルチームアジャイルチームアジャイルチームにおけるにおけるにおけるにおけるテストテストテストテストのののの視点視点視点視点
2 Developers Summit 2010 18-C-3
Agenda
1. はじめに1. 自己紹介2. セッション概要3. 皆様にお伝えしたいこと
2. アジャイルテストとは1. アジャイルテストの4象限
2. テストの視点から3. 高品質を目指すチームのプラクティス
1. 重要な成功要因4. アジャイルテストに取り組むチームへのアドバイス
1. チャレンジ5. おわりに
3 Developers Summit 2010 18-C-3
1.はじめに1-1.自己紹介
� 所属– 日本アイ・ビー・エム株式会社 グローバル・ビジネス・サービス テストマネジメント
� 経歴– 日本アイ・ビー・エム株式会社入社。アプリケーション開発・保守部門において、新手法や
新技術、ツールの適用・展開などの技術支援業務に従事。– テスト方法論、テスト技法、テストツールに専門的に取り組み、日本のプロジェクトにおいて
展開を行う。– IBM のグローバルテスティングサービスの日本市場への展開業務に従事。現在、グロー
バル・ビジネス・サービス事業において、テストコンサルティングなどのテスティングサービスをお客様に提供をしている。
– 情報処理学会正会員、IEEE Computer Society 正会員、NPO法人ソフトウェアテスト技術振興協会(ASTER)理事。
� 著作・翻訳– 「ソフトウェアテストPRESS Vol.2」(2005年技術評論社)
– 「プロジェクトマネジメントハンドブック」(2009年オーム社)
– 「「「「実践実践実践実践アジャイルテストアジャイルテストアジャイルテストアジャイルテスト」」」」(2009年翔泳社年翔泳社年翔泳社年翔泳社)
本日本日本日本日ののののセッションセッションセッションセッションのきっかけのきっかけのきっかけのきっかけ
4 Developers Summit 2010 18-C-3
1.はじめに1-2.本セッションの概要
� 「「「「Agile Testing」」」」のののの内容内容内容内容はははは実践的実践的実践的実践的であるであるであるである– 日々考えていることの答えやヒントが書かれてあった。
• 品質メトリクスを現場にいかに周知徹底していくかという検討会議の後に翻訳した部分が指標に関する部分であった。(=>5.2.3 指標でやってはならないこと)
• テストのし易さについて議論した後に翻訳した部分がテストを考慮した設計であった。(=>7.2.3 テストを考慮した設計)
� セッションセッションセッションセッション概要概要概要概要– アジャイルテストとはアジャイルチームにおけるテストのこ
と。– アジャイルテストの4象限について。– テストの視点からの紹介。
• アジャイルテストの実践的なポイント。• 高品質を追求するチーム。
原書:Agile TestingAddison-Wesley Professional; 1版 (2009/1/9)
ISBN-10: 0321534468
翔泳社 (2009/11/28)
ISBN-10: 4798119970
5 Developers Summit 2010 18-C-3
1.はじめに1-3.皆様に伝えたいこと「高品質を追求するアジャイルチームにおけるテストの視点」
1. アジャイルテストは、高品質なソフトウェア開発に重要な役割を担っている
2. アジャイルテストは、ビジネス面または技術面の軸とチームを支援する目的か製品を批評する目的かの軸による4象限の分類で説明される
3. アジャイルテストのプラクティスがある
– チーム全体アプローチ
– 自動化
など
4. これからアジャイルテストに取り組むチームへのアドバイス
– 文化的、チーム運営、プロセス移行へのチャレンジ
テスターテスターテスターテスターのののの視点視点視点視点
プログラマプログラマプログラマプログラマのののの視点視点視点視点
プログラマビジネスアナリスト
テスター
従来型機能別チーム
プログラマビジネスアナリスト
テスター
アジャイルチーム
※「実践アジャイルテスト」(翔泳社)64ページ図4-1より引用
機能別チームからアジャイルチームへ
6 Developers Summit 2010 18-C-3
2.アジャイルテストとは2-1.従来型のテストの視点
� 従来型のテストの視点– 従来型の開発・テストのモデル
• 局面化開発モデル• V字モデル
Solutioning Macro Micro PG/UT UAT
品質管理計画品質管理計画品質管理計画品質管理計画 テストテストテストテスト計画計画計画計画 テストテストテストテスト仕様書仕様書仕様書仕様書 テストテストテストテスト実施実施実施実施 受入受入受入受入
開発開発開発開発チームチームチームチーム
テストテストテストテストチームチームチームチーム
要件テスト
ビジネス目標・要件
マクロ設計
プログラミング
ユーザー受入テスト
おおおお客様客様客様客様ののののニーズニーズニーズニーズおおおお客様客様客様客様ののののニーズニーズニーズニーズ 実現機能実現機能実現機能実現機能
受入判定
お客様ニーズの受入検証
設計テスト
システムテスト
要件テスト
テスト実施レビュー
システム要件 システム統合テスト
検証
検証
検証
プロダクションレビュー
マイクロ設計 統合テスト検証
SIT
静的静的静的静的テストテストテストテスト
単体テスト
動的動的動的動的テストテストテストテスト
IT ST
7 Developers Summit 2010 18-C-3
2.アジャイルテストとは2-1.従来型のテストの視点
� 従来型のテストの視点– 標準
• IEEEなど
– テストタイプ、テストレベル– インシデント管理– テストケース作成
• 網羅性etc.
� メソドロジーとは– 以下の3点が含まれる
1. プロセス記述(WBS)
2. ガイド3. 作成物サンプル
テスト文書IEEE 829
Test Document
テストプロセスIEEE 1008 UT
IEEE 1012 V&VBS 7925-2 Component test
テストツール
コンセプト&用語BS7925-1
テスト技法BS7925-2
ツール適用エリア
標準類
プロセス記述 ガイド作成物
サンプル
標準事例
ベストプラクティステクノロジー
作成・更新
メソドロジー
メソドロジーを作る側の視点
組織標準、プロジェクト標準
WBSガイド 作成物
サンプル
テーラリング
組織で活用するためにメソドロジー化
事例フィードバック
8 Developers Summit 2010 18-C-3
2.アジャイルテストとは2-2.アジャイルテストの4象限
※「実践アジャイルテスト」(翔泳社)96ページ図6-1より引用
パフォーマンス/負荷テスト
セキュリティテスト「~性」テスト
単体テストコンポーネントテスト
探索的テストシナリオ
ユーザービリティテストユーザー受入テスト
アルファ/ベータ
機能テスト例
ストーリーテストプロトタイプ
シミュレーション
パフォーマンス/負荷テスト
セキュリティテスト「~性」テスト
単体テストコンポーネントテスト
探索的テストシナリオ
ユーザービリティテストユーザー受入テスト
アルファ/ベータ
機能テスト例
ストーリーテストプロトタイプ
シミュレーション
自動と手動
自動 ツール
手動ビジネス面
技術面
チームを支援する
製品を批評する
第2象限 第3象限第1象限 第4象限
9 Developers Summit 2010 18-C-3
2.アジャイルテストとは2-2.アジャイルテストの4象限
� アジャイルテストは、ビジネス面または技術面の軸とチームを支援する目的か製品を批評する目的かの軸による4象限の分類で説明されている。
– 技術面: 作る側の面
– ビジネス面: 出来上がったものを検証する面
– チームを支援する: チームの効率化の面
– 製品を批評する: 欠陥を探す面
� 各象限の概要は以下のとおり。
– 第1象限はチームを支援する技術面のテスト
• テスト駆動開発などアジャイル開発の中心である。
– 第2象限はチームを支援するビジネス面のテスト
• 顧客の視点からのハイレベルの機能テストなど。
– 第3象限は製品を批評するビジネス面のテスト
• ユーザー受入テスト、探索的テストなど。
– 第4象限は技術面のテストを使った製品の批評
• パフォーマンステストやセキュリティテストなど。
※「実践アジャイルテスト」(翔泳社)96ページ図6-1より引用
パフォーマンス/負荷テスト
セキュリティテスト「~性」テスト
単体テストコンポーネントテスト
探索的テストシナリオ
ユーザービリティテストユーザー受入テスト
アルファ/ベータ
機能テスト例
ストーリーテストプロトタイプ
シミュレーション
パフォーマンス/負荷テスト
セキュリティテスト「~性」テスト
単体テストコンポーネントテスト
探索的テストシナリオ
ユーザービリティテストユーザー受入テスト
アルファ/ベータ
機能テスト例
ストーリーテストプロトタイプ
シミュレーション
自動と手動
自動 ツール
手動ビジネス面
技術面
チームを支援する
製品を批評する
第2象限 第3象限第1象限 第4象限
※この4象限のオリジナルはBrian Marickが作成したhttp://www.exampler.com/old-blog/2003/08/21/
10 Developers Summit 2010 18-C-3
3.高品質を目指すチームのプラクティス (1/2)
1. チームチームチームチーム全体全体全体全体ののののアプローチアプローチアプローチアプローチをををを取取取取るるるる
�プログラマと一緒に座り、自ら会議に参加する。
�問題をチーム全体の問題としてとらえる。
2. アジャイルテストアジャイルテストアジャイルテストアジャイルテストのののの考考考考えをえをえをえを採用採用採用採用するするするする
�継続的により良い方法を探す。
�良い本やブログ、記事を読み、新しいアイデアやスキルを身につける。
3. 自動自動自動自動リグレッションテストリグレッションテストリグレッションテストリグレッションテストをををを適用適用適用適用するするするする
�自動リグレッションテストはチームの仕事である。テスターだけの仕事ではない。
�シンプルに始める。自動スモークテストや自動単体テストだけでも効率化される。
4. フィードバックフィードバックフィードバックフィードバックをををを与与与与ええええ、、、、受受受受けるけるけるける
�フィードバックはアジャイルの中心的な価値である。
�反復計画会議と振り返りに十分な時間をかけて改善する方法を探る。
1. チームチームチームチーム全体全体全体全体ののののアプローチアプローチアプローチアプローチをををを取取取取るるるる
�プログラマと一緒に座り、自ら会議に参加する。
�問題をチーム全体の問題としてとらえる。
2. アジャイルテストアジャイルテストアジャイルテストアジャイルテストのののの考考考考えをえをえをえを採用採用採用採用するするするする
�継続的により良い方法を探す。
�良い本やブログ、記事を読み、新しいアイデアやスキルを身につける。
3. 自動自動自動自動リグレッションテストリグレッションテストリグレッションテストリグレッションテストをををを適用適用適用適用するするするする
�自動リグレッションテストはチームの仕事である。テスターだけの仕事ではない。
�シンプルに始める。自動スモークテストや自動単体テストだけでも効率化される。
4. フィードバックフィードバックフィードバックフィードバックをををを与与与与ええええ、、、、受受受受けるけるけるける
�フィードバックはアジャイルの中心的な価値である。
�反復計画会議と振り返りに十分な時間をかけて改善する方法を探る。
11 Developers Summit 2010 18-C-3
3.高品質を目指すチームのプラクティス (2/2)
5. コアプラクティスコアプラクティスコアプラクティスコアプラクティスのののの基礎基礎基礎基礎をををを築築築築くくくく
1.継続的インテグレーションをする。
2.テスト環境を管理する。
3.技術的な負債(*1)を管理する。
4.段階的に作る。
5.コーディングとテストはひとつのプロセスとする。
6.各プラクティスの相乗効果を図る。
6. 顧客顧客顧客顧客とととと共同作業共同作業共同作業共同作業するするするする
�テスターはまとめ役になる。
7. 広広広広いいいい視野視野視野視野をををを持持持持つつつつ
�現在のストーリーがビジネスの重要なスキームに合うか評価できるようにする
5. コアプラクティスコアプラクティスコアプラクティスコアプラクティスのののの基礎基礎基礎基礎をををを築築築築くくくく
1.継続的インテグレーションをする。
2.テスト環境を管理する。
3.技術的な負債(*1)を管理する。
4.段階的に作る。
5.コーディングとテストはひとつのプロセスとする。
6.各プラクティスの相乗効果を図る。
6. 顧客顧客顧客顧客とととと共同作業共同作業共同作業共同作業するするするする
�テスターはまとめ役になる。
7. 広広広広いいいい視野視野視野視野をををを持持持持つつつつ
�現在のストーリーがビジネスの重要なスキームに合うか評価できるようにする
*1:技術的な負債(Technical Dept) ≒ 未解決の技術的な課題の累積
12 Developers Summit 2010 18-C-3
4.アジャイルテストへの移行
� 従来型機能別従来型機能別従来型機能別従来型機能別チームチームチームチームからからからからアジャイルチームアジャイルチームアジャイルチームアジャイルチームへのへのへのへの移行移行移行移行ののののチャレンジチャレンジチャレンジチャレンジ
�組織的な3つのチャレンジ
1.文化的なチャレンジ
2.チームの運営のチャレンジ
3.プロセスの移行のチャレンジ
テスターの視点
プログラマの視点
プログラマビジネスアナリスト
テスター
従来型機能別チーム
プログラマビジネスアナリスト
テスター
アジャイルチーム
※「実践アジャイルテスト」(翔泳社)64ページ図4-1より引用
機能別チームからアジャイルチームへ
13 Developers Summit 2010 18-C-3
4.アジャイルテストへの移行4-1.文化的なチャレンジ� 文化的なチャレンジ
– 組織の文化 →味方を増やす– 適応のための阻害 →継続する– 変革の導入 →小さな成功を収める– 管理職の期待 →管理職の世界感の共有– 変化は簡単ではない →体験させる
※「実践アジャイルテスト」(翔泳社)37ページ図より引用
14 Developers Summit 2010 18-C-3
4.アジャイルテストへの移行4-2.チーム運営
� チーム運営– チームの構成 →役割分担は必要– 物の準備 →作業環境、ツールも重要– 人材 →どのような人物がふさわしいか– チームの立ち上げ →情報共有、目標共有
※「実践アジャイルテスト」(翔泳社)59ページ図より引用
15 Developers Summit 2010 18-C-3
4.アジャイルテストへの移行4-2.プロセスの移行
� プロセスの移行– 軽量プロセスを探す →できることから始める– 指標を設定する →プラス思考になれる指標を設定する– 欠陥の追跡をする →ナレッジベースとして使う– テスト計画書を作成する →先のことを考えるとリスクが浮かび上がる– 既存のプロセスとモデル →従うべきプロセスもある
※「実践アジャイルテスト」(翔泳社)73ページ図より引用
16 Developers Summit 2010 18-C-3
� ワークアイテムワークアイテムワークアイテムワークアイテム管理管理管理管理をををを軸軸軸軸にににに、、、、計画管理計画管理計画管理計画管理、、、、構成管理構成管理構成管理構成管理、、、、ビルドビルドビルドビルド管理管理管理管理をををを統合統合統合統合したしたしたしたAll-in-One製品製品製品製品
– 成果物間に渡る、ワークアイテムを軸とした強力な追跡性、一貫性
– プロジェクト全体をリアルタイムに可視化– 分散並行開発を支えるソース管理
� 分散開発分散開発分散開発分散開発におけるにおけるにおけるにおけるチームチームチームチーム・・・・コラボレーションコラボレーションコラボレーションコラボレーションををををサポートサポートサポートサポート– Web2.0技術(wiki, chat, RSS)を統合し、円滑なコラボレーショ
ンをサポート� オープンオープンオープンオープン&&&&スケーラブルスケーラブルスケーラブルスケーラブルななななJazzプラットフォームプラットフォームプラットフォームプラットフォーム上上上上のののの製品製品製品製品
– 既存資産、既存ツールとの連携が可能– 幅広い開発環境、DB/アプリケーションサーバー環境をサポー
ト– 小規模から大規模へ、段階的にRTCを適用可能– オープンでコミュニティベースの開発モデル
Rational Team Concert の概要
IBM Rational Team Concert
透明性 統合された表示 wiki オープン リ
アルタイム・レポーティング チャット引き継ぎの自動化Web 2.0 ダッシュボード
のカスタマイズ データ収集の自動化 拡張性拡張性拡張性拡張性Eclipseプラグイン サービス・アーキテクチャ 生生生生成成成成のののの自由自由自由自由
コラボレーションコラボレーションコラボレーションコラボレーションをををを通通通通じたじたじたじたソフトウエアソフトウエアソフトウエアソフトウエア開発開発開発開発のののの実現実現実現実現
4.アジャイルテストへの移行アジャイルプロセスサポートツール Rational Team Concertのご紹介
17 Developers Summit 2010 18-C-3
ソースソースソースソース管理管理管理管理 リリースリリースリリースリリース管理管理管理管理
Rational Team Concertにより作業の可視化とワークフローを実現
ビルドビルドビルドビルド
開発者開発者開発者開発者
設計設計設計設計、、、、実装実装実装実装、、、、テストテストテストテスト
ワークワークワークワークのののの登録登録登録登録、、、、アサインアサインアサインアサイントラッキングトラッキングトラッキングトラッキング
利害関係者利害関係者利害関係者利害関係者 リーダーリーダーリーダーリーダー ビルドビルドビルドビルド担当者担当者担当者担当者
Rational Team Concert包括的包括的包括的包括的ななななコラボレーティブコラボレーティブコラボレーティブコラボレーティブ・・・・インフラストラクチャインフラストラクチャインフラストラクチャインフラストラクチャ
ワークアイテムワークアイテムワークアイテムワークアイテム管理管理管理管理計画管理計画管理計画管理計画管理
反復反復
反復
④④④④コンパイルコンパイルコンパイルコンパイルしししし、、、、ビルドビルドビルドビルドをををを作成作成作成作成
- メンバーメンバーメンバーメンバー管理管理管理管理- 自動自動自動自動データデータデータデータ収集収集収集収集&&&&レポートレポートレポートレポート作成作成作成作成
①①①①ワークアイテムワークアイテムワークアイテムワークアイテムをををを登録登録登録登録。。。。
②②②②アサインアサインアサインアサイン見見見見積積積積もりもりもりもり
③③③③開発開発開発開発&&&&テストテストテストテスト。。。。実績値実績値実績値実績値をををを入力入力入力入力。。。。
全ての成果物を一元的に管理。ワークアイテム駆動で、アサイン、見積
もり、トラックする
4.アジャイルテストへの移行アジャイルプロセスサポートツール Rational Team Concert (RTC)のご紹介
18 Developers Summit 2010 18-C-3
Rational Team Concertによる進捗管理、作業の追跡
ワークアイテムワークアイテムワークアイテムワークアイテムにににに関関関関するするするする履歴情報履歴情報履歴情報履歴情報
((((承認承認承認承認ログログログログもももも含含含含むむむむ))))作業作業作業作業のののの一覧一覧一覧一覧進捗管理進捗管理進捗管理進捗管理
ダッシュボードダッシュボードダッシュボードダッシュボードによによによによるるるる状況状況状況状況のののの把握把握把握把握
4.アジャイルテストへの移行アジャイルプロセスサポートツール Rational Team Concert (RTC)のご紹介
19 Developers Summit 2010 18-C-3
5.おわりに本日お伝えしたこと
「高品質を追求するアジャイルチームにおけるテストの視点」
1. アジャイルテストは、高品質なソフトウェア開発に重要な役割を担っている
2. アジャイルテストは、ビジネス面または技術面の軸とチームを支援する目的か製品を批評する目的かの軸による4象限の分類で説明される
3. アジャイルテストの実践的なポイントがある
– チーム全体アプローチ
– 自動化
など
4. これからアジャイルテストに取り組むチームのチャレンジ
– 文化的、チーム運営、プロセス移行へのチャレンジ
「高品質を追求するアジャイルチームにおけるテストの視点」
1. アジャイルテストは、高品質なソフトウェア開発に重要な役割を担っている
2. アジャイルテストは、ビジネス面または技術面の軸とチームを支援する目的か製品を批評する目的かの軸による4象限の分類で説明される
3. アジャイルテストの実践的なポイントがある
– チーム全体アプローチ
– 自動化
など
4. これからアジャイルテストに取り組むチームのチャレンジ
– 文化的、チーム運営、プロセス移行へのチャレンジ
20 Developers Summit 2010 18-C-3
21 Developers Summit 2010 18-C-3
ワークショップ、セッション、および資料は、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.の米国およびその他の国における商標です。他の会社名、製品名およびサービス名等はそれぞれ各社の商標。