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