SlideShare una empresa de Scribd logo
1 de 21
Descargar para leer sin conexión
アジャイルテスト

高品質を追求するアジャイルチームにおけるテストの
高品質を追求するアジャイルチームにおけるテストの視点
      するアジャイルチームにおけるテスト




18-C-3                   増田 聡
                         ITアーキテクト
                         日本アイ・ビー・エム株式会社
                         テストマネジメント
         Developers Summit 2010
Agenda

    1. はじめに
        1. 自己紹介
        2. セッション概要
        3. 皆様にお伝えしたいこと
    2. アジャイルテストとは
        1. アジャイルテストの4象限
        2. テストの視点から
    3. 高品質を目指すチームのプラクティス
        1. 重要な成功要因
    4. アジャイルテストに取り組むチームへのアドバイス
        1. チャレンジ
    5. おわりに


2        Developers Summit 2010 18-C-3
1.はじめに
1-1.自己紹介
       所属
        – 日本アイ・ビー・エム株式会社 グローバル・ビジネス・サービス テストマネジメント

       経歴
        – 日本アイ・ビー・エム株式会社入社。アプリケーション開発・保守部門において、新手法や
          新技術、ツールの適用・展開などの技術支援業務に従事。
        – テスト方法論、テスト技法、テストツールに専門的に取り組み、日本のプロジェクトにおいて
          展開を行う。
        – IBM のグローバルテスティングサービスの日本市場への展開業務に従事。現在、グロー
          バル・ビジネス・サービス事業において、テストコンサルティングなどのテスティングサービ
          スをお客様に提供をしている。
        – 情報処理学会正会員、IEEE Computer Society 正会員、NPO法人ソフトウェアテスト技術
          振興協会(ASTER)理事。

       著作・翻訳
        – 「ソフトウェアテストPRESS Vol.2」(2005年技術評論社)
        – 「プロジェクトマネジメントハンドブック」(2009年オーム社)
           実践アジャイルテスト
              アジャイルテスト」     年翔泳社)
        – 「実践アジャイルテスト」(2009年翔泳社
                            年翔泳社

    本日のセッションのきっかけ
    本日のセッションのきっかけ
3        Developers Summit 2010 18-C-3
1.はじめに
1-2.本セッションの概要
                  」 内容は実践的である
    「Agile Testing」の内容は実践的である
     – 日々考えていることの答えやヒントが書かれてあった。
        • 品質メトリクスを現場にいかに周知徹底していくかとい
          う検討会議の後に翻訳した部分が指標に関する部分
          であった。
           (=>5.2.3 指標でやってはならないこと)
        • テストのし易さについて議論した後に翻訳した部分が
          テストを考慮した設計であった。
           (=>7.2.3 テストを考慮した設計)
                                           原書:Agile Testing
                                           Addison-Wesley Professional; 1版 (2009/1/9)
                                           ISBN-10: 0321534468

    セッション概要
    セッション概要
     – アジャイルテストとはアジャイルチームにおけるテストのこ
       と。
     – アジャイルテストの4象限について。
     – テストの視点からの紹介。
        • アジャイルテストの実践的なポイント。
        • 高品質を追求するチーム。



4          Developers Summit 2010 18-C-3
                                            翔泳社 (2009/11/28)
                                           ISBN-10: 4798119970
1.はじめに
1-3.皆様に伝えたいこと
「高品質を追求するアジャイルチームにおけるテストの視点」
    1. アジャイルテストは、高品質なソフトウェア開発に重要な役割を担っている
    2. アジャイルテストは、ビジネス面または技術面の軸とチームを支援する目的か製品を批評す
       る目的かの軸による4象限の分類で説明される
    3. アジャイルテストのプラクティスがある
        – チーム全体アプローチ
        – 自動化
        など
    4. これからアジャイルテストに取り組むチームへのアドバイス
        – 文化的、チーム運営、プロセス移行へのチャレンジ

                                          プログラマの
                                          プログラマの視点     アジャイルチーム
     従来型機能別チーム

                         ビジネス                                    ビジネス
    プログラマ                                            プログラマ       アナリスト
                         アナリスト
                                         機能別チームから          テスター
            テスター                         アジャイルチームへ



                                                       テスターの
                                                       テスターの視点
5        Developers Summit 2010 18-C-3
                                                       ※「実践アジャイルテスト」(翔泳社)64ページ図4-1より引用
2.アジャイルテストとは
2-1.従来型のテストの視点
 従来型のテストの視点
    – 従来型の開発・テストのモデル
       • 局面化開発モデル
       • V字モデル
              お客様のニーズ
               客様の                                      お客様ニーズの受入検証                      実現機能
                                                                                          受入判定
                                                                  検証
              ビジネス目標・要件                                                                 ユーザー受入テスト
                       要件テスト                                                        プロダクションレビュー
                                                                  検証
                          システム要件                                                システム統合テスト
                                   要件テスト
                  静的テスト
                  静的テスト                                           検証
                                          マクロ設計                            システムテスト

                                                設計テスト                  テスト実施レビュー        動的テスト
                                                                                        動的テスト
                                                                  検証
                                                 マイクロ設計                統合テスト

                                                             プログラミング
                                                             単体テスト

        開発              Solutioning             Macro     Micro    PG/UT   IT      ST     SIT     UAT
        チーム
        テスト         品質管理計画                    テスト計画
                                              テスト計画       テスト仕様書
                                                          テスト仕様書                テスト実施
                                                                                テスト実施            受入
        チーム
6             Developers Summit 2010 18-C-3
2.アジャイルテストとは
2-1.従来型のテストの視点
  従来型のテストの視点                                                     メソドロジーとは
     – 標準                                                        – 以下の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
2.アジャイルテストとは
2-2.アジャイルテストの4象限


                                              ビジネス面
      自動と手動                                                        手動

                                 機能テスト                 探索的テスト
                                   例                    シナリオ
          チ                     ストーリーテスト            ユーザービリティテスト                製
          ー                      プロトタイプ              ユーザー受入テスト                 品
          ム                                           アルファ/ベータ                 を
          を                     シミュレーション
          支                                                                    批
                                        第2象限    第3象限                           評
          援                             第1象限    第4象限
      す                                                                    す
      る                                                                    る
                                                    パフォーマンス/負荷テスト
                              単体テスト
                                                      セキュリティテスト
                            コンポーネントテスト
                                                       「~性」テスト


               自動                                                 ツール
                                              技術面



8             Developers Summit 2010 18-C-3
                                                          ※「実践アジャイルテスト」(翔泳社)96ページ図6-1より引用
2.アジャイルテストとは
2-2.アジャイルテストの4象限
アジャイルテストは、ビジネス面または技術面の軸とチー
ムを支援する目的か製品を批評する目的かの軸による4
象限の分類で説明されている。
 – 技術面: 作る側の面
 – ビジネス面: 出来上がったものを検証する面                                         ビジネス面
                                         自動と手動                                                  手動
 – チームを支援する: チームの効率化の面
                                                    機能テスト                    探索的テスト
 – 製品を批評する: 欠陥を探す面                                    例                       シナリオ
                                         チ         ストーリーテスト               ユーザービリティテスト                 製
                                         ー          プロトタイプ                 ユーザー受入テスト                  品
各象限の概要は以下のとおり。                           ム
                                         を         シミュレーション                 アルファ/ベータ                  を
 – 第1象限はチームを支援する技術面のテスト                  支                第2象限         第3象限
                                                                                                      批
                                         援                                                            評
    • テスト駆動開発などアジャイル開発の中心である。                             第1象限         第4象限                           す
                                         す
 – 第2象限はチームを支援するビジネス面のテスト                る                                                            る
                                                                        パフォーマンス/負荷テスト
    • 顧客の視点からのハイレベルの機能テストなど。                        単体テスト
                                                                          セキュリティテスト
                                                  コンポーネントテスト
 – 第3象限は製品を批評するビジネス面のテスト                                                   「~性」テスト
    • ユーザー受入テスト、探索的テストなど。
                                             自動                                                 ツール
 – 第4象限は技術面のテストを使った製品の批評
                                                                 技術面
    • パフォーマンステストやセキュリティテストなど。




                                                      ※この4象限のオリジナルはBrian Marickが作成した
                                                      http://www.exampler.com/old-blog/2003/08/21/

9        Developers Summit 2010 18-C-3
                                                       ※「実践アジャイルテスト」(翔泳社)96ページ図6-1より引用
3.高品質を目指すチームのプラクティス (1/2)

   チーム全体 のアプローチを 取る
   チーム全体の アプローチを
1. チーム全体のアプローチを取る
      全体
     プログラマと一緒に座り、自ら会議に参加する。
     プログラマと一緒に座り、自ら会議に参加する。
     問題をチーム全体の問題としてとらえる。
     問題をチーム全体の問題としてとらえる。
   アジャイルテストの 考えを採用 する
   アジャイルテストの えを採用する
2. アジャイルテストの考えを採用する
                採用
     継続的により良い方法を探す。
     継続的により良い方法を探す。
     良い本やブログ、記事を読み、新しいアイデアやスキルを身につける。
     良い本やブログ、記事を読み、新しいアイデアやスキルを身につける。
   自動リグレッションテスト を適用する
   自動リグレッションテストを 適用する
3. 自動リグレッションテストを適用する
     リグレッションテスト
     自動リグレッションテストはチームの仕事である。テスターだけの仕事ではない。
     自動リグレッションテストはチームの仕事である。テスターだけの仕事ではない。
     シンプルに始める。自動スモークテストや自動単体テストだけでも効率化される。
     シンプルに始める。自動スモークテストや自動単体テストだけでも効率化される。
   フィードバックを 与え、受ける
4. フィードバックを与え、受ける
   フィードバックを
     フィードバックはアジャイルの中心的な価値である。
     フィードバックはアジャイルの中心的な価値である。
     反復計画会議と振り返りに十分な時間をかけて改善する方法を探る。
     反復計画会議と振り返りに十分な時間をかけて改善する方法を探る。




10       Developers Summit 2010 18-C-3
3.高品質を目指すチームのプラクティス (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
4.アジャイルテストへの移行

     従来型機能別チームからアジャイルチームへの移行の
     従来型機能別チームからアジャイルチームへの移行のチャレンジ
           チームからアジャイルチームへの移行
      組織的な3つのチャレンジ
       1.文化的なチャレンジ
       2.チームの運営のチャレンジ
       3.プロセスの移行のチャレンジ



                                          プログラマの視点        アジャイルチーム
       従来型機能別チーム

                          ビジネス                                      ビジネス
      プログラマ                                             プログラマ       アナリスト
                          アナリスト
                                            機能別チームから          テスター
              テスター                          アジャイルチームへ



                                                          テスターの視点

                                                          ※「実践アジャイルテスト」(翔泳社)64ページ図4-1より引用

12        Developers Summit 2010 18-C-3
4.アジャイルテストへの移行
4-1.文化的なチャレンジ
     文化的なチャレンジ
      – 組織の文化                       →味方を増やす
      – 適応のための阻害                    →継続する
      – 変革の導入                       →小さな成功を収める
      – 管理職の期待                      →管理職の世界感の共有
      – 変化は簡単ではない                   →体験させる




13          Developers Summit 2010 18-C-3
                                                  ※「実践アジャイルテスト」(翔泳社)37ページ図より引用
4.アジャイルテストへの移行
4-2.チーム運営
     チーム運営
      – チームの構成                      →役割分担は必要
      – 物の準備                        →作業環境、ツールも重要
      – 人材                          →どのような人物がふさわしいか
      – チームの立ち上げ                    →情報共有、目標共有




14          Developers Summit 2010 18-C-3
                                                      ※「実践アジャイルテスト」(翔泳社)59ページ図より引用
4.アジャイルテストへの移行
4-2.プロセスの移行
     プロセスの移行
      – 軽量プロセスを探す                           →できることから始める
      – 指標を設定する                             →プラス思考になれる指標を設定する
      – 欠陥の追跡をする                            →ナレッジベースとして使う
      – テスト計画書を作成する                         →先のことを考えるとリスクが浮かび上がる
      – 既存のプロセスとモデル                         →従うべきプロセスもある




15          Developers Summit 2010 18-C-3
                                                        ※「実践アジャイルテスト」(翔泳社)73ページ図より引用
4.アジャイルテストへの移行
 アジャイルプロセスサポートツール Rational Team Concertのご紹介
Rational Team Concert の概要
           コラボレーションを じたソフトウエア開発の
           コラボレーションを通じたソフトウエア開発の実現
                       ソフトウエア開発
  ワークアイテム管理を
  ワークアイテム管理を軸に、計画管理、構成管理、ビルド管理を
              管理         計画管理、構成管理、ビルド管理を
                                        管理
                                               IBM Rational Team Concert
  統合した
  統合したしたAll-in-One製品
                  製品
  – 成果物間に渡る、ワークアイテムを軸とした強力な追跡性、一
    貫性
  – プロジェクト全体をリアルタイムに可視化
  – 分散並行開発を支えるソース管理
  分散開発におけるチーム・コラボレーションを
         におけるチーム
  分散開発におけるチーム・コラボレーションをサポート
  – Web2.0技術(wiki, chat, RSS)を統合し、円滑なコラボレーショ
    ンをサポート
  オープン&スケーラブルな             プラットフォーム上
  オープン&スケーラブルなJazzプラットフォーム上の製品
                           プラットフォーム
  – 既存資産、既存ツールとの連携が可能
  – 幅広い開発環境、DB/アプリケーションサーバー環境をサポー
    ト
                                               透明性       統合された表示    wiki オープン   リ
  – 小規模から大規模へ、段階的にRTCを適用可能
  – オープンでコミュニティベースの開発モデル                       アルタイム・レポーティング       チャット
                                               引き継ぎの自動化       Web 2.0 ダッシュボード
                                               のカスタマイズ                 拡張性
                                                               データ収集の自動化
                                               Eclipseプラグイン   サービス・アーキテクチャ 生
                                               成の自由



 16         Developers Summit 2010 18-C-3
4.アジャイルテストへの移行
 アジャイルプロセスサポートツール Rational Team Concert (RTC)のご紹介
Rational Team Concertにより作業の可視化とワークフローを実現


                 ワークの登録、
                 ワークの登録、アサイン                                  設計、
                                                              設計、
                    トラッキング                                                        ビルド
                                                             実装、
                                                             実装、テスト
 利害関係者                      リーダー                                開発者              ビルド担当者
                                                                                 ビルド担当者




                                                  ②アサイン見
                                                   アサイン見
                                                    積もり
全ての成果物を一元的                                                                        ④コンパイルし、
                                                                                   コンパイルし
                                ①ワークアイテム                                           ビルドを作成
                                                                                   ビルドを
に管理。ワークアイテム                        登録。
                                  を登録。
                                                                 ③開発&テスト。
                                                                  開発&テスト。
                                                                 実績値を入力。
                                                                 実績値を入力。
駆動で、アサイン、見積
 もり、トラックする


     反復
      反復
        反復
             計画管理                             ワークアイテム管理
                                              ワークアイテム管理              ソース管理
                                                                     ソース管理          リリース管理
                                                                                    リリース管理
                                             Rational Team Concert         メンバー管理
                                                                         - メンバー管理
                                                                           自動データ収集&レポート作成
                                                                             データ収集
                                                                         - 自動データ収集&レポート作成
                                     包括的なコラボレーティブ・
                                     包括的なコラボレーティブ・インフラストラクチャ

17           Developers Summit 2010 18-C-3
4.アジャイルテストへの移行
アジャイルプロセスサポートツール Rational Team Concert (RTC)のご紹介
Rational Team Concertによる進捗管理、作業の追跡




                                                         ワークアイテムに
                                                         ワークアイテムに関
                                                          する履歴情報
                                                          する履歴情報
                                                          承認ログ
                                                            ログも
                                                         (承認ログも含む)
     作業の
     作業の一覧
      進捗管理




                                             ダッシュボードによ
                                             ダッシュボードによ
                                               状況の
                                              る状況の把握




18           Developers Summit 2010 18-C-3
5.おわりに
本日お伝えしたこと


     「高品質を追求するアジャイルチームにおけるテストの視点」
     1. アジャイルテストは、高品質なソフトウェア開発に重要な役割を担っている
     1. アジャイルテストは、高品質なソフトウェア開発に重要な役割を担っている
     2. アジャイルテストは、ビジネス面または技術面の軸とチームを支援する目的か製品を批評す
     2. アジャイルテストは、ビジネス面または技術面の軸とチームを支援する目的か製品を批評す
        る目的かの軸による4象限の分類で説明される
        る目的かの軸による4象限の分類で説明される
     3. アジャイルテストの実践的なポイントがある
     3. アジャイルテストの実践的なポイントがある
       – チーム全体アプローチ
       – チーム全体アプローチ
       – 自動化
       – 自動化
       など
       など
     4. これからアジャイルテストに取り組むチームのチャレンジ
     4. これからアジャイルテストに取り組むチームのチャレンジ
       – 文化的、チーム運営、プロセス移行へのチャレンジ
       – 文化的、チーム運営、プロセス移行へのチャレンジ




19          Developers Summit 2010 18-C-3
20   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.の米国およびその他の国における商標です。
     他の会社名、製品名およびサービス名等はそれぞれ各社の商標。



21                           Developers Summit 2010 18-C-3

Más contenido relacionado

La actualidad más candente

Agile開発でのテストのやり方~私の場合~
Agile開発でのテストのやり方~私の場合~Agile開発でのテストのやり方~私の場合~
Agile開発でのテストのやり方~私の場合~Mineo Matsuya
 
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)Yasuharu Nishi
 
テスト分析.pptx
テスト分析.pptxテスト分析.pptx
テスト分析.pptxkauji0522
 
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLiveDXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLiveTokoroten Nakayama
 
ITコミュニティと情報発信に共通する成長と貢献の要素
ITコミュニティと情報発信に共通する成長と貢献の要素ITコミュニティと情報発信に共通する成長と貢献の要素
ITコミュニティと情報発信に共通する成長と貢献の要素NISHIHARA Shota
 
アジャイル×テスト開発を考える
アジャイル×テスト開発を考えるアジャイル×テスト開発を考える
アジャイル×テスト開発を考えるyasuohosotani
 
アジャイル開発とメトリクス
アジャイル開発とメトリクスアジャイル開発とメトリクス
アジャイル開発とメトリクスRakuten Group, Inc.
 
DeNAの品質を支えるQAの取り組み 〜標準化から実践まで〜
DeNAの品質を支えるQAの取り組み 〜標準化から実践まで〜DeNAの品質を支えるQAの取り組み 〜標準化から実践まで〜
DeNAの品質を支えるQAの取り組み 〜標準化から実践まで〜Tetsuya Kouno
 
ソフトウェアテストの歴史と近年の動向
ソフトウェアテストの歴史と近年の動向ソフトウェアテストの歴史と近年の動向
ソフトウェアテストの歴史と近年の動向Keizo Tatsumi
 
はじめてのアジャイル
はじめてのアジャイルはじめてのアジャイル
はじめてのアジャイルYoshihito Kuranuki
 
人生がときめくAPIテスト自動化 with Karate
人生がときめくAPIテスト自動化 with Karate人生がときめくAPIテスト自動化 with Karate
人生がときめくAPIテスト自動化 with KarateTakanori Suzuki
 
Akkaとは。アクターモデル とは。
Akkaとは。アクターモデル とは。Akkaとは。アクターモデル とは。
Akkaとは。アクターモデル とは。Kenjiro Kubota
 
SQL上級者こそ知って欲しい、なぜO/Rマッパーが重要か?
SQL上級者こそ知って欲しい、なぜO/Rマッパーが重要か?SQL上級者こそ知って欲しい、なぜO/Rマッパーが重要か?
SQL上級者こそ知って欲しい、なぜO/Rマッパーが重要か?kwatch
 
「採用基準」読んでみた
「採用基準」読んでみた「採用基準」読んでみた
「採用基準」読んでみたまこっちゃん
 
どうする計画駆動型スクラム(スクラムフェス大阪2023 発表資料)
どうする計画駆動型スクラム(スクラムフェス大阪2023 発表資料)どうする計画駆動型スクラム(スクラムフェス大阪2023 発表資料)
どうする計画駆動型スクラム(スクラムフェス大阪2023 発表資料)NTT DATA Technology & Innovation
 
テストを分類してみよう!
テストを分類してみよう!テストを分類してみよう!
テストを分類してみよう!Kenji Okumura
 
例外設計における大罪
例外設計における大罪例外設計における大罪
例外設計における大罪Takuto Wada
 
Karpenterで君だけの最強のオートスケーリングを実装しよう
Karpenterで君だけの最強のオートスケーリングを実装しようKarpenterで君だけの最強のオートスケーリングを実装しよう
Karpenterで君だけの最強のオートスケーリングを実装しようKohei Nagase
 
パターン QA to AQ: 伝統的品質保証(Quality Assurance)からアジャイル品質(Agile Quality)へ
パターン QA to AQ: 伝統的品質保証(Quality Assurance)からアジャイル品質(Agile Quality)へパターン QA to AQ: 伝統的品質保証(Quality Assurance)からアジャイル品質(Agile Quality)へ
パターン QA to AQ: 伝統的品質保証(Quality Assurance)からアジャイル品質(Agile Quality)へHironori Washizaki
 

La actualidad más candente (20)

Agile開発でのテストのやり方~私の場合~
Agile開発でのテストのやり方~私の場合~Agile開発でのテストのやり方~私の場合~
Agile開発でのテストのやり方~私の場合~
 
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
 
テスト分析.pptx
テスト分析.pptxテスト分析.pptx
テスト分析.pptx
 
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLiveDXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
 
ITコミュニティと情報発信に共通する成長と貢献の要素
ITコミュニティと情報発信に共通する成長と貢献の要素ITコミュニティと情報発信に共通する成長と貢献の要素
ITコミュニティと情報発信に共通する成長と貢献の要素
 
アジャイル×テスト開発を考える
アジャイル×テスト開発を考えるアジャイル×テスト開発を考える
アジャイル×テスト開発を考える
 
アジャイル開発とメトリクス
アジャイル開発とメトリクスアジャイル開発とメトリクス
アジャイル開発とメトリクス
 
Google Cloud で実践する SRE
Google Cloud で実践する SRE  Google Cloud で実践する SRE
Google Cloud で実践する SRE
 
DeNAの品質を支えるQAの取り組み 〜標準化から実践まで〜
DeNAの品質を支えるQAの取り組み 〜標準化から実践まで〜DeNAの品質を支えるQAの取り組み 〜標準化から実践まで〜
DeNAの品質を支えるQAの取り組み 〜標準化から実践まで〜
 
ソフトウェアテストの歴史と近年の動向
ソフトウェアテストの歴史と近年の動向ソフトウェアテストの歴史と近年の動向
ソフトウェアテストの歴史と近年の動向
 
はじめてのアジャイル
はじめてのアジャイルはじめてのアジャイル
はじめてのアジャイル
 
人生がときめくAPIテスト自動化 with Karate
人生がときめくAPIテスト自動化 with Karate人生がときめくAPIテスト自動化 with Karate
人生がときめくAPIテスト自動化 with Karate
 
Akkaとは。アクターモデル とは。
Akkaとは。アクターモデル とは。Akkaとは。アクターモデル とは。
Akkaとは。アクターモデル とは。
 
SQL上級者こそ知って欲しい、なぜO/Rマッパーが重要か?
SQL上級者こそ知って欲しい、なぜO/Rマッパーが重要か?SQL上級者こそ知って欲しい、なぜO/Rマッパーが重要か?
SQL上級者こそ知って欲しい、なぜO/Rマッパーが重要か?
 
「採用基準」読んでみた
「採用基準」読んでみた「採用基準」読んでみた
「採用基準」読んでみた
 
どうする計画駆動型スクラム(スクラムフェス大阪2023 発表資料)
どうする計画駆動型スクラム(スクラムフェス大阪2023 発表資料)どうする計画駆動型スクラム(スクラムフェス大阪2023 発表資料)
どうする計画駆動型スクラム(スクラムフェス大阪2023 発表資料)
 
テストを分類してみよう!
テストを分類してみよう!テストを分類してみよう!
テストを分類してみよう!
 
例外設計における大罪
例外設計における大罪例外設計における大罪
例外設計における大罪
 
Karpenterで君だけの最強のオートスケーリングを実装しよう
Karpenterで君だけの最強のオートスケーリングを実装しようKarpenterで君だけの最強のオートスケーリングを実装しよう
Karpenterで君だけの最強のオートスケーリングを実装しよう
 
パターン QA to AQ: 伝統的品質保証(Quality Assurance)からアジャイル品質(Agile Quality)へ
パターン QA to AQ: 伝統的品質保証(Quality Assurance)からアジャイル品質(Agile Quality)へパターン QA to AQ: 伝統的品質保証(Quality Assurance)からアジャイル品質(Agile Quality)へ
パターン QA to AQ: 伝統的品質保証(Quality Assurance)からアジャイル品質(Agile Quality)へ
 

Destacado

AgileJapan2010 基調講演:野中郁次郎先生による「実践知のリーダシップ~スクラムと知の場作り」
AgileJapan2010 基調講演:野中郁次郎先生による「実践知のリーダシップ~スクラムと知の場作り」AgileJapan2010 基調講演:野中郁次郎先生による「実践知のリーダシップ~スクラムと知の場作り」
AgileJapan2010 基調講演:野中郁次郎先生による「実践知のリーダシップ~スクラムと知の場作り」Kenji Hiranabe
 
スプリント計画ミーティング
スプリント計画ミーティングスプリント計画ミーティング
スプリント計画ミーティングMiho Nagase
 
プランニングポーカーではじめる工数見積りと計画づくり
プランニングポーカーではじめる工数見積りと計画づくりプランニングポーカーではじめる工数見積りと計画づくり
プランニングポーカーではじめる工数見積りと計画づくりReimi Kuramochi Chiba
 
開発モデルの作り方(守破離の破)
開発モデルの作り方(守破離の破)開発モデルの作り方(守破離の破)
開発モデルの作り方(守破離の破)Arata Fujimura
 
ストーリーポイントで見積もるということ
ストーリーポイントで見積もるということストーリーポイントで見積もるということ
ストーリーポイントで見積もるということYagi Natsuki
 
認定スクラムマスター研修に行ってきました
認定スクラムマスター研修に行ってきました認定スクラムマスター研修に行ってきました
認定スクラムマスター研修に行ってきましたHajime Yanagawa
 

Destacado (6)

AgileJapan2010 基調講演:野中郁次郎先生による「実践知のリーダシップ~スクラムと知の場作り」
AgileJapan2010 基調講演:野中郁次郎先生による「実践知のリーダシップ~スクラムと知の場作り」AgileJapan2010 基調講演:野中郁次郎先生による「実践知のリーダシップ~スクラムと知の場作り」
AgileJapan2010 基調講演:野中郁次郎先生による「実践知のリーダシップ~スクラムと知の場作り」
 
スプリント計画ミーティング
スプリント計画ミーティングスプリント計画ミーティング
スプリント計画ミーティング
 
プランニングポーカーではじめる工数見積りと計画づくり
プランニングポーカーではじめる工数見積りと計画づくりプランニングポーカーではじめる工数見積りと計画づくり
プランニングポーカーではじめる工数見積りと計画づくり
 
開発モデルの作り方(守破離の破)
開発モデルの作り方(守破離の破)開発モデルの作り方(守破離の破)
開発モデルの作り方(守破離の破)
 
ストーリーポイントで見積もるということ
ストーリーポイントで見積もるということストーリーポイントで見積もるということ
ストーリーポイントで見積もるということ
 
認定スクラムマスター研修に行ってきました
認定スクラムマスター研修に行ってきました認定スクラムマスター研修に行ってきました
認定スクラムマスター研修に行ってきました
 

Similar a アジャイルテスト -高品質を追求するアジャイルチームにおけるテストの視点-

テストとの上手な付き合い方
テストとの上手な付き合い方テストとの上手な付き合い方
テストとの上手な付き合い方Akira Suenami
 
SGT2013 技術トークス「アジャイルテスティング」
SGT2013 技術トークス「アジャイルテスティング」SGT2013 技術トークス「アジャイルテスティング」
SGT2013 技術トークス「アジャイルテスティング」yasuohosotani
 
19-B-4 開発品質向上のための、ASQ/ALMソリューション
19-B-4 開発品質向上のための、ASQ/ALMソリューション19-B-4 開発品質向上のための、ASQ/ALMソリューション
19-B-4 開発品質向上のための、ASQ/ALMソリューションDevelopers Summit
 
開発品質向上のための、ASQ/ALMソリューション ~品質向上策・活用していないのは何故ですか?~
開発品質向上のための、ASQ/ALMソリューション ~品質向上策・活用していないのは何故ですか?~開発品質向上のための、ASQ/ALMソリューション ~品質向上策・活用していないのは何故ですか?~
開発品質向上のための、ASQ/ALMソリューション ~品質向上策・活用していないのは何故ですか?~mafujiwara
 
【18-B-4】ソースコード品質、大丈夫ですか? ~静的検証のススメ~
【18-B-4】ソースコード品質、大丈夫ですか? ~静的検証のススメ~【18-B-4】ソースコード品質、大丈夫ですか? ~静的検証のススメ~
【18-B-4】ソースコード品質、大丈夫ですか? ~静的検証のススメ~Developers Summit
 
Team Foundation Server ~ 今を生きるエンジニアのための開発基盤とは 【BPStudy #63】
Team Foundation Server ~ 今を生きるエンジニアのための開発基盤とは 【BPStudy #63】 Team Foundation Server ~ 今を生きるエンジニアのための開発基盤とは 【BPStudy #63】
Team Foundation Server ~ 今を生きるエンジニアのための開発基盤とは 【BPStudy #63】 智治 長沢
 
Jenkins ユーザ・カンファレンス 2012 東京 S406-4/マルチステージ型継続的インテグレーションのすすめ
Jenkins ユーザ・カンファレンス 2012 東京 S406-4/マルチステージ型継続的インテグレーションのすすめJenkins ユーザ・カンファレンス 2012 東京 S406-4/マルチステージ型継続的インテグレーションのすすめ
Jenkins ユーザ・カンファレンス 2012 東京 S406-4/マルチステージ型継続的インテグレーションのすすめatsushi_tmx
 
Qc astah 連携について012
Qc astah 連携について012Qc astah 連携について012
Qc astah 連携について012Kei Nakahara
 
ぼくのかんがえた iOSテスト戦略
ぼくのかんがえた iOSテスト戦略ぼくのかんがえた iOSテスト戦略
ぼくのかんがえた iOSテスト戦略Naoki Umehara
 
JUnit実践入門 xUnitTestPatternsで学ぶユニットテスト
JUnit実践入門 xUnitTestPatternsで学ぶユニットテストJUnit実践入門 xUnitTestPatternsで学ぶユニットテスト
JUnit実践入門 xUnitTestPatternsで学ぶユニットテストShuji Watanabe
 
【JaSST'11 Tokyo】 テスト イノベーション
【JaSST'11 Tokyo】 テスト イノベーション【JaSST'11 Tokyo】 テスト イノベーション
【JaSST'11 Tokyo】 テスト イノベーション智治 長沢
 
アジャイルなテストの見積もりと計画作り
アジャイルなテストの見積もりと計画作りアジャイルなテストの見積もりと計画作り
アジャイルなテストの見積もりと計画作りkyon mm
 
Agile japan2010 rakuten様プレゼン資料
Agile japan2010 rakuten様プレゼン資料Agile japan2010 rakuten様プレゼン資料
Agile japan2010 rakuten様プレゼン資料Akiko Kosaka
 
#NagoyaTesting アジャイルなテストの見積りと計画づくり
#NagoyaTesting アジャイルなテストの見積りと計画づくり #NagoyaTesting アジャイルなテストの見積りと計画づくり
#NagoyaTesting アジャイルなテストの見積りと計画づくり kyon mm
 
ワンクリックデプロイ101 #ocdeploy
ワンクリックデプロイ101 #ocdeployワンクリックデプロイ101 #ocdeploy
ワンクリックデプロイ101 #ocdeployRyutaro YOSHIBA
 
Qs information20110615
Qs information20110615Qs information20110615
Qs information20110615Kei Nakahara
 
Enterprise TEST Forum 2012
Enterprise TEST Forum 2012Enterprise TEST Forum 2012
Enterprise TEST Forum 2012智治 長沢
 

Similar a アジャイルテスト -高品質を追求するアジャイルチームにおけるテストの視点- (20)

ITS fidel
ITS fidelITS fidel
ITS fidel
 
テストとの上手な付き合い方
テストとの上手な付き合い方テストとの上手な付き合い方
テストとの上手な付き合い方
 
SGT2013 技術トークス「アジャイルテスティング」
SGT2013 技術トークス「アジャイルテスティング」SGT2013 技術トークス「アジャイルテスティング」
SGT2013 技術トークス「アジャイルテスティング」
 
19-B-4 開発品質向上のための、ASQ/ALMソリューション
19-B-4 開発品質向上のための、ASQ/ALMソリューション19-B-4 開発品質向上のための、ASQ/ALMソリューション
19-B-4 開発品質向上のための、ASQ/ALMソリューション
 
開発品質向上のための、ASQ/ALMソリューション ~品質向上策・活用していないのは何故ですか?~
開発品質向上のための、ASQ/ALMソリューション ~品質向上策・活用していないのは何故ですか?~開発品質向上のための、ASQ/ALMソリューション ~品質向上策・活用していないのは何故ですか?~
開発品質向上のための、ASQ/ALMソリューション ~品質向上策・活用していないのは何故ですか?~
 
【18-B-4】ソースコード品質、大丈夫ですか? ~静的検証のススメ~
【18-B-4】ソースコード品質、大丈夫ですか? ~静的検証のススメ~【18-B-4】ソースコード品質、大丈夫ですか? ~静的検証のススメ~
【18-B-4】ソースコード品質、大丈夫ですか? ~静的検証のススメ~
 
Team Foundation Server ~ 今を生きるエンジニアのための開発基盤とは 【BPStudy #63】
Team Foundation Server ~ 今を生きるエンジニアのための開発基盤とは 【BPStudy #63】 Team Foundation Server ~ 今を生きるエンジニアのための開発基盤とは 【BPStudy #63】
Team Foundation Server ~ 今を生きるエンジニアのための開発基盤とは 【BPStudy #63】
 
Jenkins ユーザ・カンファレンス 2012 東京 S406-4/マルチステージ型継続的インテグレーションのすすめ
Jenkins ユーザ・カンファレンス 2012 東京 S406-4/マルチステージ型継続的インテグレーションのすすめJenkins ユーザ・カンファレンス 2012 東京 S406-4/マルチステージ型継続的インテグレーションのすすめ
Jenkins ユーザ・カンファレンス 2012 東京 S406-4/マルチステージ型継続的インテグレーションのすすめ
 
Qc astah 連携について012
Qc astah 連携について012Qc astah 連携について012
Qc astah 連携について012
 
ぼくのかんがえた iOSテスト戦略
ぼくのかんがえた iOSテスト戦略ぼくのかんがえた iOSテスト戦略
ぼくのかんがえた iOSテスト戦略
 
JUnit実践入門 xUnitTestPatternsで学ぶユニットテスト
JUnit実践入門 xUnitTestPatternsで学ぶユニットテストJUnit実践入門 xUnitTestPatternsで学ぶユニットテスト
JUnit実践入門 xUnitTestPatternsで学ぶユニットテスト
 
【JaSST'11 Tokyo】 テスト イノベーション
【JaSST'11 Tokyo】 テスト イノベーション【JaSST'11 Tokyo】 テスト イノベーション
【JaSST'11 Tokyo】 テスト イノベーション
 
Q te cc2
Q te cc2Q te cc2
Q te cc2
 
アジャイルなテストの見積もりと計画作り
アジャイルなテストの見積もりと計画作りアジャイルなテストの見積もりと計画作り
アジャイルなテストの見積もりと計画作り
 
Agile japan2010 rakuten様プレゼン資料
Agile japan2010 rakuten様プレゼン資料Agile japan2010 rakuten様プレゼン資料
Agile japan2010 rakuten様プレゼン資料
 
#NagoyaTesting アジャイルなテストの見積りと計画づくり
#NagoyaTesting アジャイルなテストの見積りと計画づくり #NagoyaTesting アジャイルなテストの見積りと計画づくり
#NagoyaTesting アジャイルなテストの見積りと計画づくり
 
ワンクリックデプロイ101 #ocdeploy
ワンクリックデプロイ101 #ocdeployワンクリックデプロイ101 #ocdeploy
ワンクリックデプロイ101 #ocdeploy
 
Qs info 002
Qs info 002Qs info 002
Qs info 002
 
Qs information20110615
Qs information20110615Qs information20110615
Qs information20110615
 
Enterprise TEST Forum 2012
Enterprise TEST Forum 2012Enterprise TEST Forum 2012
Enterprise TEST Forum 2012
 

アジャイルテスト -高品質を追求するアジャイルチームにおけるテストの視点-

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