20110127_devloveテストの話.pdf

Transcript

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の定義 http://www.scrumalliance.org/articles/107-‐‑‒how-‐‑‒do-‐‑‒we-‐‑‒know-‐‑‒when-‐‑‒we-‐‑‒are-‐‑‒done プロジェクトごとに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の場合 Cancel Gift  wrap Return スプリント 2~∼4週間 返品 スプリントゴール スプリント バックログ 出荷可能な製品の 積み上げ プロダクトバックログ クーポン ギフト包装 クーポン キャンセル 24時間 単体テスト、結合テスト、 受け⼊入れテストがスプリン ト単位(もしくはリリース単 位)で⾏行行われる.
20. アジャイルでの品質の作りこみ スプリント終了了時には「テスト」が完了了.スプリントレ ビューで顧客のビジネス要件への適合性も確認できる http://www.flickr.com/photos/kakutani/2761992149/
21. アジャイルでの品質の作りこみ Scrumではフレームワークの定義のみで、テスト⾃自 動化については触れられていない.しかしアジャイル 開発においてはテスト⾃自動化は必須 ⼩小規模リリースのたびに⼿手 動でテストするとスプリン ト後半になるにつれてテス トコストが膨らむ ⾃自動化しないとソフトウェア規模に応じて、テスト⼯工数の占め る割合が増加していく（＝価値への投資が減少）
22. 【⾃自動と⼿手動】 機能テスト ストーリーテスト プロトタイプ シミュレーション 【⼿手動】※1 探索索的テスト シナリオテスト ユーザビリティテスト ユーザー受⼊入テスト アルファ版、ベータ版 【⾃自動化】 単体テスト コンポーネントテスト 【ツール】 パフォーマンステスト 負荷テスト セキュリティテスト 第１象限 第２象限 第３象限 第４象限 技術⾯面（技術的品質） ビジネス⾯面（ビジネス的品質） チ ー ム を ⽀支 援 製 品 を 批 評 テストの4象限 ※1  ATDD等では⾃自動化
23. 第1象限 　チームを⽀支援する技術⾯面のテスト テスト駆動開発などアジャイル開発の中⼼心。 第2象限 　チームを⽀支援するビジネス⾯面のテスト 顧客の視点からのハイレベルの機能テストなど。 第3象限 　製品を批評するビジネス⾯面のテスト ユーザー受⼊入テスト、探索索的テストなど。 第4象限 　技術⾯面のテストを使った製品の批評 パフォーマンステスト、セキュリティテストなど。 テストの4象限 「アジャイルテスト  ―⾼高品質を追求するアジャイルチームにおけるテストの視点―」増⽥田聡⽒氏 http://codezine.jp/devsumi/2010/report/07/ 　より引⽤用
24. ⾃自動化されたテストの要件 ⾃自動化されたテストは以下の条件を満たしている必要がある。 RISE 繰り返し可能  (Repeatable) 何回でも繰り返し実⾏行行できること。また実⾏行行ごとに結果が変わらないこと 独⽴立立性  (Independent) 環境や外部のコンポーネントに依存しないこと テストケースの実⾏行行順序に依存しないこと ⾃自⼰己検証  (Self  validation) テストが成功したか、失敗したかはプログラムが判断する。 （⼈人⼿手で判断しない） 簡単実⾏行行  (Easy) テストの準備に⼤大量量の時間や⼈人⼿手がかかるようにしない
25. 【⾃自動と⼿手動】 機能テスト ストーリーテスト プロトタイプ シミュレーション 【⼿手動】 探索索的テスト シナリオテスト ユーザビリティテスト ユーザー受⼊入テスト アルファ版、ベータ版 【⾃自動化】 単体テスト コンポーネントテスト 【ツール】 パフォーマンステスト 負荷テスト セキュリティテスト 第１象限 第２象限 第３象限 第４象限 技術⾯面（技術的品質） ビジネス⾯面（ビジネス的品質） チ ー ム を ⽀支 援 製 品 を 批 評 ツール・⼿手法のマッピング(例例) TDD xUnit PMD,  CPD  … Jmeter WebScarab RatProxy ValGrind  … Selenium Cucumber Rspec FitNess  … CI推奨 CI推奨 CI必須 ⼀一部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/