1. テストにつ いて考える 2011/1/27 #devlove Ryutaro “Ryuzee” YOSHIBA http://www.flickr.com/photos/jakecaptive/3205277810/
2. ⾃⼰紹介 Ryuzee @ryuzee http://www.ryuzee.com/ http://www.flickr.com/photos/adforce1/2539903964/
3. アジャイルコーチ 認定スクラムマスター(CSM) 認定スクラムプロダクトオーナー(CSPO) オープンソース開発者、翻訳者 スクラム道の共同設⽴者 Shibuya.tracのスタッフ TIS,野村総合研究所を経てベンチャーのCTO http://www.flickr.com/photos/royskeane/413103429/
4. 今⽇の話のコンテキスト • アジャイルな⽴場から話をします • もちろんウォーターフォールでも適⽤ 可能です. • ソフトウェア開発はコンテキスト依存 性が⾼いので、唯⼀絶対解はありませ ん.個々のプロジェクト内で良く話し 合うことをお勧めします. http://www.flickr.com/photos/okiboi/411678818/
5. アジェンダ 1. テストの⽬的と価値 2. テストの⼿法 3. テストのコスト 4. テスト結果の評価 http://www.flickr.com/photos/ondablv/3959216018/
6. 1. テストの⽬的と価値 • 品質ってなんだ？ • 何のためにテストするのか？ • テスト範囲の決め⽅
7. 品質ってなんだ？ 顧客にとっての品質は、バグの有無ではな く、そのソフトウェアを利⽤してビジネス 上の成果があげられるかどうかである. http://www.flickr.com/photos/oberazzi/318947873/
8. 極論すると… バグは無いが、ビジ ネスの役に⽴たない ソフトウェア http://www.flickr.com/photos/tschaut/875393159/ バグはあるが、ビジ ネスの役に⽴つ ソフトウェア
9. バグが少ないことだけをゴールにし ていませんか？ http://www.flickr.com/photos/lauralie0/2988591080/
10. テスト範囲や内容の決め⽅ • 範囲は ⽬的 に依存する • 範囲は ROI に依存する • 範囲は リスク に依存する ⇒テスト範囲や内容とその完了の条件は WFでもアジャイルでも重要 http://www.flickr.com/photos/benbunch/4816136249/
11. 銀⾏、医療、携帯電話、Webサイトのど れもが同じ条件によるテストが必要なわ けではない！ http://www.flickr.com/photos/30854583@N07/4424574772/ http://www.flickr.com/photos/christianacare/4642178916/ http://www.flickr.com/photos/phossil/4849753531/ http://www.flickr.com/photos/deia/2235006720/
12. ビジネスによる判断 • システムが競争⼒の源泉になる • サービスやシステムの早期のマーケットへの投⼊が、⼤ きなリターンにつながる • 逆にいえば、いくら品質が良くても、マーケットへの投 ⼊が遅れれば、⼤きなビジネスチャンスを失う可能性も ある 顧客の要求例 「2011年2⽉28⽇までにサービスインしたい.品質につ いては、正常系が動作すること、秒間3件以上のアクセ スに耐えられること」 http://www.flickr.com/photos/maysbusinessschool/4418165194/
13. Doneの定義 プロジェクトごとにDoneの定義(完 了条件)は異なるので、案件開始時に 決める必要がある http://www.scrumalliance.org/articles/107-how-do-we-know-when-we-are-done
14. 2. テストの⼿法 • WFにおける課題 • アジャイルにおけるテストに対する考 え⽅ • テストの４象限 • テストの⼿法 • ⾃動化・モニタリング • 外注、パートナー混成チームにおける 品質の作り込み http://www.flickr.com/photos/crystalcampbell/3454977037/
15. ウォーターフォールモデル 受⼊テスト 要件定義 基本設計 総合テスト 詳細設計 結合テスト 実装・単体テスト ウォーターフォールのV字モデル
16. WFモデルの課題① 構築したソフトウェアが顧客ビジネスのニーズに マッチしているかどうかを確認できるのは、受け ⼊れ試験の時期になってしまう http://www.flickr.com/photos/coyotejack/2273593999/
17. WFモデルの課題② モノの品質の確定は⼯期の後半に始まる 品質 品質 ビックバンリスク ⼯期 ⼯期
18. WFでありがちな話 要件定義は順調です ○○設計は順調です 開発は遅れてますが、挽回可能です 結合試験で重⼤な問題が出ています 受⼊試験でニーズ不⼀致が判明 リリースできません 多くのリスクが後半に顕在化 http://www.flickr.com/photos/kwazar/2289418010/
19. アジャイルでの品質の作りこみ Scrumの場合 24時間 スプリント 2~4週間 スプリントゴール 返品 スプリント バックログ キャンセル Return クーポン Gift wrap ギフト包装 Cancel クーポン プロダクトバックログ 出荷可能な製品の 積み上げ 単体テスト、結合テスト、 受け⼊れテストがスプリン ト単位(もしくはリリース単 位)で⾏われる.
20. アジャイルでの品質の作りこみ スプリント終了時には「テスト」が完了.スプリントレ ビューで顧客のビジネス要件への適合性も確認できる http://www.flickr.com/photos/kakutani/2761992149/
21. アジャイルでの品質の作りこみ Scrumではフレームワークの定義のみで、テスト⾃ 動化については触れられていない.しかしアジャイル 開発においてはテスト⾃動化は必須 ⼩規模リリースのたびに⼿ 動でテストするとスプリン ト後半になるにつれてテス トコストが膨らむ ⾃動化しないとソフトウェア規模に応じて、テスト⼯数の占め る割合が増加していく（＝価値への投資が減少）
22. テストの4象限 ビジネス⾯（ビジネス的品質） 【⾃動と⼿動】 【⼿動】※1 機能テスト ストーリーテスト プロトタイプ シミュレーション 探索的テスト シナリオテスト ユーザビリティテスト ユーザー受⼊テスト アルファ版、ベータ版 ー チ 第２象限 ム を ⽀ 【⾃動化】 援 単体テスト コンポーネントテスト 第３象限 【ツール】 パフォーマンステスト 負荷テスト セキュリティテスト 第１象限 技術⾯（技術的品質） ※1 ATDD等では⾃動化 第４象限 製 品 を 批 評
23. テストの4象限 第1象限 チームを⽀援する技術⾯のテスト テスト駆動開発などアジャイル開発の中⼼。 第2象限 チームを⽀援するビジネス⾯のテスト 顧客の視点からのハイレベルの機能テストなど。 第3象限 製品を批評するビジネス⾯のテスト ユーザー受⼊テスト、探索的テストなど。 第4象限 技術⾯のテストを使った製品の批評 パフォーマンステスト、セキュリティテストなど。 「アジャイルテスト ―⾼品質を追求するアジャイルチームにおけるテストの視点―」増⽥聡⽒ http://codezine.jp/devsumi/2010/report/07/ より引⽤
24. ⾃動化されたテストの要件 ⾃動化されたテストは以下の条件を満たしている必要がある。 RISE 繰り返し可能 (Repeatable) 何回でも繰り返し実⾏できること。また実⾏ごとに結果が変わらないこと 独⽴性 (Independent) 環境や外部のコンポーネントに依存しないこと テストケースの実⾏順序に依存しないこと ⾃⼰検証 (Self validation) テストが成功したか、失敗したかはプログラムが判断する。 （⼈⼿で判断しない） 簡単実⾏ (Easy) テストの準備に⼤量の時間や⼈⼿がかかるようにしない
25. ツール・⼿法のマッピング(例) ビジネス⾯（ビジネス的品質） 【⾃動と⼿動】 ー チ 機能テスト Selenium ストーリーテスト Cucumber プロトタイプ Rspec シミュレーション FitNess … CI推奨 第２象限 ム を ⽀ 【⾃動化】 援 単体テスト コンポーネントテスト TDD xUnit PMD, CPD … CI必須 第１象限 【⼿動】 探索的テスト シナリオテスト ユーザビリティテスト ユーザー受⼊テスト アルファ版、ベータ版 ⼀部CI可能 第３象限 【ツール】 パフォーマンステスト Jmeter 負荷テスト WebScarab セキュリティテスト RatProxy ValGrind … CI推奨 技術⾯（技術的品質） 第４象限 製 品 を 批 評
26. 単体テスト⾃動化/TDDとは？ XPのプラクティスの中で、最も単体で導⼊しやすいプラクティスの１つである。 基本的な⽅法 失敗するテストを書く できる限り早く、テストがパスするような最⼩限のコード本体を書く リファクタリングをする 適⽤範囲 通常では、独⽴性の⾼いクラスやファンクションへの適⽤が良い。 GUIや分散オブジェクト、⾃動⽣成されたコード、DBのスキーマに関するテスト は導⼊が難しい。 既存システムにおいて、テストが準備されていない場合に、部分的に導⼊するの は難易度が⾼い。従って新規プロジェクトの初期から導⼊することが望ましい。 問題点 開発者が仕様を誤解していた場合、誤解に基づくテストコードが作成されるため、 誤解の検知は保証できない。あくまで開発者が作成するコードが、開発者が認識 するテストコードに適合していることのみが保証される。
27. 結合テスト⾃動化とは？ 複数のモジュールやサブシステム、実際の画⾯を使ったエンドツーエンドテスト 基本的な⽅法 内部コードではなく振る舞いを確認する.単体レベルの内容は検証しない. Selenium、Cucumberなどを利⽤ 問題点 基本的にはテストの作成コストは⾼い. テストに際しては複数のシステムやデータベース等依存性のあるものの準備も含 めて⾃動化する必要があり、テストケースの実⾏に時間がかかることがある.（ス ローテスト問題）
28. レガシープロジェクトへの導⼊ レガシープロジェクトとは？ ⾃動化されたテストが備わっていないプロジェクトのこと。 利⽤している⾔語やフレームワークには関係ない。 レガシープロジェクトの問題点 機能追加や改修の際に、現⾏機能に問題がないことを保証するためには、⼈⼒ による再テストを実施するしかない。従って機能追加・改修が度重なるたびに、 テストのスコープが膨れ上がり、開発コストの増⼤につながる。 通常、ユニットテストによるテストを意識したモジュール間の依存性が低い状 態になっていないため、テストしにくく、結合度の⾼さ故、変更を加えにくく、 予期しない箇所に影響が出やすい。 どうやって導⼊するか？ 結合テストレベルのテストを先に⽤意し、想定されるアプリケーション全体の 動作をチェックできるようにする。
29. 第１象限での⾃動評価 プロジェクトの特性や要員構成等に応じて決める テスト件数と結果(単体、結合) PMD警告件数 Checkstyle警告件数 カバレージ
30. チーム活動の評価 コード⾏数 アクティビティ コミット時間
31. チーム構成別リスク検出 外注する場合の注意点 品質定義、テスト範囲について委託先に任せているケースが⾮常に多いが、最 終的に⼤きなリスクを発注者が背負うことになる。従って 品質定義、テスト範囲、テスト⽅法、網羅性(カバレージ指標)について発注時 に伝えるとともに、⼯期中随時発注者側がチェックできる仕掛けを⽤意する。 (例：レポジトリ環境の提供、委託者作成のソースコードの⾃動チェック、⾃ 動ビルド) パートナー混成チームの注意点 チームの要員不⾜をパートナー(派遣契約等)混成チームで補うことがあるが、 要員のスキルの把握が事前にできないケースが多いため、特定のコーダーが作 成したモジュールに問題が頻発するといった結果になることが多い。 従って、外注する場合と同じように参画の段階で、品質定義、テスト範囲、テ スト⽅法等を⼗分に伝える必要がある。また継続的レビューや⾃動チェックも 必要 なるべく⾃動化してリスクを⾃動で検出できる仕掛けを作る ことが望ましい
32. 3. テストのコスト • ⼿動テストのコストと⾃動テストの コストの評価 • 初期開発とエンハンス開発 http://www.flickr.com/photos/webflunkie/5122391694/
33. テストのコスト評価 作成したテストを何回くらい実⾏することになるのか ？ テストの⾃動化を実現するために要するコストおよび維持コス トはどの程度か？ ITアーキテクト「機能テストの⾃動化について考える」 より引⽤ http://www.itarchitect.jp/print/?menu3=24601
34. 初期開発とエンハンス開発 初期開発 エンハンス開発 要員 ⼊れ替わりはすくない ⼊れ替わりが多い スキル エース級やアーキテク エース級やアーキテク トの存在 ト不在 リリース 回数予測可能 回数 運⽤期間に⽐例しリニ アに増加 テスト 件数 エンハンス内容に⽐例 しリニアに増加 件数予測可能 エンハンス中はリニアにテスト件数が増加する.テストが⾃動 化されていない場合、全機能のリグレッションテストを⾏うが、 そのボリュームが増え続けてしまう. ⼿動テストのコストを顧客は負担したがるか？
35. 4. テスト結果の評価 • テスト結果の評価は誰がする？ • 社内の品質管理部⾨の役割は？ http://www.flickr.com/photos/billsophoto/4175299981/
36. テスト結果の評価は誰がする？ 答え チームと顧客 SIerにおける社内品質基準での画⼀評価は、顧客に とっては意味がない. (例)顧客のRequirement 「2011年2⽉28⽇までにサービスインしたい.品質について は、正常系が動作すること、秒間3件以上のアクセスに耐えら れること」 ⇒このようなケースで社内品質基準で評価すると、出荷不可 能な製品になってしまう. http://www.flickr.com/photos/billward/2837582102/
37. 社内の品質管理部⾨の役割は？ プロジェクトの後半ではなく、プロジェクトの提案活動、 テスト範囲の決定、テスト⽅法の決定についてチームを⽀ 援する. ＝Doneの定義 社内 品質基準 プロジェクト 品質基準 顧客の要求に あわせて テーラリング 品質管理部⾨ ＋ チーム
38. まとめ ü 品質とはバグの有無ではなくビジネス価値が実現 できるか否かである。 ü テストには⽬的が必要。⽬的によって実施⽅法や 範囲(完了条件)は異なる。 ü ソフトウェアがニーズにマッチしているかどうか は早期から確認が必要。 ü テスト⾃動化は継続的な価値の創出に効果がある。 ü テスト結果の評価は品質管理部⾨が⾏うものでは なくチームと顧客が⾏う。
39. http://www.flickr.com/photos/meganelizasmith/4096564203/
