テストについて考える

6,019 views
5,843 views

Published on

アジャイルにおけるテスト戦略について某社でお話した内容

Published in: Technology
0 Comments
24 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
6,019
On SlideShare
0
From Embeds
0
Number of Embeds
1,220
Actions
Shares
0
Downloads
80
Comments
0
Likes
24
Embeds 0
No embeds

No notes for slide

テストについて考える

  1. 1. テストにつ いて考える 2010/11/30 Ryutaro “Ryuzee” YOSHIBA http://www.flickr.com/photos/nicolas-hoizey/2693162677/
  2. 2. 自己紹介 Ryuzee @ryuzee http://www.ryuzee.com/ http://www.flickr.com/photos/adforce1/2539903964/
  3. 3. アジャイルコーチ 認定スクラムマスター オープンソース開発者、翻訳者 Shibuya.tracのスタッフ TIS,野村総合研究所を経てベンチャーのCTO http://www.flickr.com/photos/royskeane/413103429/
  4. 4. 今日の話のコンテキスト • ゕジャ゗ルな立場から話をします • がウォーターフォールでも適用可能 です.(適用してください) • ソフトウェゕ開発はコンテキスト依 存性が高いので、唯一絶対解はあり ません.個々のプロジェクト内で良く 話し合うことをお勧めします.
  5. 5. 1. テストの目的と価値 • 品質ってなんだ? • 何のためにテストするのか? • テスト範囲の決め方
  6. 6. 品質ってなんだ? 顧客にとっての品質は、バグの有無ではな く、そのソフトウェゕを利用してビジネス 上の成果があげられるかどうかである. http://www.flickr.com/photos/oberazzi/318947873/
  7. 7. 極論すると バグは無いが、ビジ ネスの役に立たない ソフトウェゕ バグはあるが、ビジ ネスの役に立つ ソフトウェゕ http://www.flickr.com/photos/tschaut/875393159/
  8. 8. 何のためにテストするのか? テスト範囲をどう決める? バグがあることを確認する? バグがないことを確認する? 顧客の要求にあっているかを確認する? 範囲は目的に依存する 範囲はROIに依存する 範囲はリスクに依存する ⇒テスト範囲と完了の条件はWFでもアジャイルでも重要
  9. 9. 2. テストの手法 • WFにおける課題 • ゕジャ゗ルにおけるテストに対する 考え方 • テストの4象限 • テストの手法 • 自動化・モニタリング • 外注、パートナー混成チームにおけ る品質の作り込み
  10. 10. http://thinkit.co.jp/article/22/3/ 小堀 真義氏 「第3回:ウォーターフォールにおけるドキュメント作成ポ゗ント」より引用 ウォーターフォールモデル
  11. 11. WFモデルの課題① 構築したソフトウェアが顧客ビジネスのニーズに マッチしているかどうかを確認できるのは、受け 入れ試験の時期になってしまう http://www.flickr.com/photos/coyotejack/2273593999/
  12. 12. WFモデルの課題② モノの品質の確定は工期の後半に始まる 工期 品質 ビックバンリスク 工期 品質
  13. 13. WFでありがちな話 要件定義は順調です ○○設計は順調です 開発は遅れてますが、挽回可能です 結合試験で重大な問題が出ています リリースできません これで顧客の信頼を得られるのか? http://www.flickr.com/photos/kwazar/2289418010/
  14. 14. アジャイルでの品質の作りこみ Scrumの場合 Cancel Gift wrap Return スプリント 2~4週間 返品 スプリントゴール スプリント バックログ 出荷可能な製品の 積み上げ プロダクトバックログ クーポンギフト包装 クーポン キャンセル 24時間 単体テスト、結合テスト、 受け入れテストがスプリン ト単位(もしくはリリース単 位)で行われる.
  15. 15. アジャイルでの品質の作りこみ スプリント終了時には「テスト」が完了.スプリントレ ビューで顧客のビジネス要件への適合性も確認できる http://www.flickr.com/photos/kakutani/2761992149/
  16. 16. アジャイルでの品質の作りこみ Scrumではフレームワークの定義のみで、テスト自 動化については触れられていない.しかしゕジャ゗ル 開発においてはテスト自動化は必須 小規模リリースのたびに 手動でテストするとスプ リント後半になるにつれ てテストコストが膨らむ 自動化しないとソフトウェゕ規模に応じて、ベロシティ(生産 性)が低下していく
  17. 17. テストの4象限 「ゕジャ゗ルテスト ―高品質を追求するゕジャ゗ルチームにおけるテストの視点―」増田聡氏 http://codezine.jp/devsumi/2010/report/07/ より引用
  18. 18. 第1象限 チームを支援する技術面のテスト テスト駆動開発などゕジャ゗ル開発の中心。 第2象限 チームを支援するビジネス面のテスト 顧客の視点からのハ゗レベルの機能テストなど。 第3象限 製品を批評するビジネス面のテスト ユーザー受入テスト、探索的テストなど。 第4象限 技術面のテストを使った製品の批評 パフォーマンステスト、セキュリテゖテストなど。 テストの4象限 「ゕジャ゗ルテスト ―高品質を追求するゕジャ゗ルチームにおけるテストの視点―」増田聡氏 http://codezine.jp/devsumi/2010/report/07/ より引用
  19. 19. 具体的なテストの手法 • ユニットテスト(単体テスト自動化) • カバレージ • ゗ンスペクション • コーデゖング規約 • 結合テスト • 受け入れテスト • セキュリテゖ試験 • 性能試験
  20. 20. 単体テスト自動化/TDDとは? XPのプラクテゖスの中で、最も単体で導入しやすいプラクテゖスの1つである。 基本的な方法 失敗するテストを書く できる限り早く、テストがパスするような最小限のコード本体を書く リフゔクタリングをする 適用範囲 通常では、独立性の高いクラスやフゔンクションへの適用が良い。 GUIや分散オブジェクト、自動生成されたコード、DBのスキーマに関するテスト は導入が難しい。 既存システムにおいて、テストが準備されていない場合に、部分的に導入するの は難易度が高い。従って新規プロジェクトの初期から導入することが望ましい。 問題点 開発者が仕様を誤解していた場合、誤解に基づくテストコードが作成されるため、 誤解の検知は保証できない。あくまで開発者が作成するコードが、開発者が認識 するテストコードに適合していることのみが保証される。
  21. 21. 結合テスト自動化とは? 複数のモジュールやサブシステム、実際の画面を使ったエンドツーエンドテスト 基本的な方法 内部コードではなく振る舞いを確認する.単体レベルの内容は検証しない. Selenium、Cucumberなどを利用 問題点 基本的にはテストの作成コストは高い. テストに際しては複数のシステムやデータベース等依存性のあるものの準備も含 めて自動化する必要があり、テストケースの実行に時間がかかることがある.(ス ローテスト問題)
  22. 22. 自動化されたテストの要件 自動化されたテストは以下の条件を満たしている必要がある。 簡単実行 テストの準備に大量の時間や人手がかかるようにしない 自己検証 テストが成功したか、失敗したかはプログラムが判断する。 (人手で判断しない) 繰り返し可能 何回でも繰り返し実行できること。また実行ごとに結果が変わらないこと 独立性 環境や外部のコンポーネントに依存しないこと テストケースの実行順序に依存しないこと
  23. 23. レガシープロジェクトへの導入 レガシープロジェクトとは? 自動化されたテストが備わっていないプロジェクトのこと。 利用している言語やフレームワークには関係ない。 レガシープロジェクトの問題点 機能追加や改修の際に、現行機能に問題がないことを保証するためには、人力 による再テストを実施するしかない。従って機能追加・改修が度重なるたびに、 テストのスコープが膨れ上がり、開発コストの増大につながる。 通常、ユニットテストによるテストを意識したモジュール間の依存性が低い状 態になっていないため、テストしにくく、結合度の高さ故、変更を加えにくく、 予期しない箇所に影響が出やすい。 どうやって導入するか? 結合テストレベルのテストを先に用意し、想定されるゕプリケーション全体の 動作をチェックできるようにする。
  24. 24. 自動化/モニタリングの範囲 プロジェクトの特性や要員構成等に応じて決める テスト件数と結果(単体、結合) PMD警告件数 Checkstyle警告件数 カバレージ
  25. 25. 自動化/モニタリングの範囲 コード行数 コミット時間 アクティビティ
  26. 26. 外注/パートナー混成チーム 外注する場合の注意点 品質定義、テスト範囲について委託先に任せているケースが非常に多いが、最 終的に大きなリスクを発注者が背負うことになる。従って 品質定義、テスト範囲、テスト方法、網羅性(カバレージ指標)について発注時 に伝えるとともに、工期中随時発注者側がチェックできる仕掛けを用意する。 (例:レポジトリ環境の提供、委託者作成のソースコードの自動チェック、自 動ビルド) パートナー混成チームの注意点 チームの要員不足をパートナー(派遣契約等)混成チームで補うことがあるが、 要員のスキルの把握が事前にできないケースが多いため、特定のコーダーが作 成したモジュールに問題が頻発するといった結果になることが多い。 従って、外注する場合と同じように参画の段階で、品質定義、テスト範囲、テ スト方法等を十分に伝える必要がある。また継続的レビューや自動チェックも 必要 なるべく自動化してリスクを自動で検出できる仕掛けを作る ことが望ましい
  27. 27. 3. テストのコスト • 手動テストのコストと自動テストの コストの評価 • 初期開発とエンハンス開発
  28. 28. ITゕーキテクト「機能テストの自動化について考える」 より引用 http://www.itarchitect.jp/print/?menu3=24601 テストのコスト評価 作成したテストを何回くらい実行することになるのか ? テストの自動化を実現するために要するコストおよび維持コス トはどの程度か?
  29. 29. 初期開発とエンハンス開発 初期開発 エンハンス開発 要員 入れ替わりはすくない 入れ替わりが多い スキル エース級やゕーキテク トの存在 エース級やゕーキテク ト不在 リリース 回数 回数予測可能 運用期間に比例しリニ ゕに増加 テスト 件数 件数予測可能 エンハンス内容に比例 しリニゕに増加 エンハンス中はリニゕにテスト件数が増加する.テストが自動 化されていない場合、全機能のリグレッションテストを行う が、そのボリュームが増え続けてしまう. 手動テストのコストを顧客は負担したがるか?
  30. 30. 4. テスト結果の評価 • テスト結果の評価は誰がする? • 社内の品質管理部門の役割は?
  31. 31. テスト結果の評価は誰がする? 答え チームと顧客 SIerにおける社内品質基準での画一評価は、顧客にとって は意味がない. (例)顧客のRequirement 「2010年12月31日までにサービス゗ンしたい.品質につい ては、正常系が動作すること、秒間3件以上のゕクセスに 耐えられること」 ⇒このようなケースで社内品質基準で評価すると、出荷不 可能な製品になってしまう.
  32. 32. 社内の品質管理部門の役割は? プロジェクトの後半ではなく、プロジェクトの提案活動、 テスト範囲の決定、テスト方法の決定についてチームを支 援する. 社内 品質基準 プロジェクト 品質基準 顧客の要求に あわせて テラーリング 品質管理部門 + チーム
  33. 33. http://www.flickr.com/photos/meganelizasmith/4096564203/

×