Slide 1

Slide 1 text

テストにつ いて考える                         2011/1/27  #devlove     Ryutaro  “Ryuzee”  YOSHIBA http://www.flickr.com/photos/jakecaptive/3205277810/

Slide 2

Slide 2 text

⾃自⼰己紹介                            Ryuzee                               @ryuzee http://www.ryuzee.com/ http://www.flickr.com/photos/adforce1/2539903964/

Slide 3

Slide 3 text

アジャイルコーチ 認定スクラムマスター(CSM) 認定スクラムプロダクトオーナー(CSPO) オープンソース開発者、翻訳者 スクラム道の共同設⽴立立者 Shibuya.tracのスタッフ TIS,野村総合研究所を経てベンチャーのCTO http://www.flickr.com/photos/royskeane/413103429/

Slide 4

Slide 4 text

今⽇日の話のコンテキスト •  アジャイルな⽴立立場から話をします •  もちろんウォーターフォールでも適⽤用 可能です. •  ソフトウェア開発はコンテキスト依存 性が⾼高いので、唯⼀一絶対解はありませ ん.個々のプロジェクト内で良良く話し 合うことをお勧めします. http://www.flickr.com/photos/okiboi/411678818/

Slide 5

Slide 5 text

アジェンダ 1.  テストの⽬目的と価値 2.  テストの⼿手法 3.  テストのコスト 4.  テスト結果の評価 http://www.flickr.com/photos/ondablv/3959216018/

Slide 6

Slide 6 text

1.  テストの⽬目的と価値 •  品質ってなんだ? •  何のためにテストするのか? •  テスト範囲の決め⽅方

Slide 7

Slide 7 text

品質ってなんだ? 顧客にとっての品質は、バグの有無ではな く、そのソフトウェアを利利⽤用してビジネス 上の成果があげられるかどうかである. http://www.flickr.com/photos/oberazzi/318947873/

Slide 8

Slide 8 text

極論論すると… バグは無いが、ビジ ネスの役に⽴立立たない ソフトウェア バグはあるが、ビジ ネスの役に⽴立立つ ソフトウェア http://www.flickr.com/photos/tschaut/875393159/

Slide 9

Slide 9 text

http://www.flickr.com/photos/lauralie0/2988591080/ バグが少ないことだけをゴールにし ていませんか?

Slide 10

Slide 10 text

テスト範囲や内容の決め⽅方 •  範囲は  ⽬目的  に依存する •  範囲は  ROI  に依存する •  範囲は  リスク  に依存する ⇒テスト範囲や内容とその完了了の条件は WFでもアジャイルでも重要 http://www.flickr.com/photos/benbunch/4816136249/

Slide 11

Slide 11 text

銀⾏行行、医療療、携帯電話、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/

Slide 12

Slide 12 text

•  システムが競争⼒力力の源泉になる •  サービスやシステムの早期のマーケットへの投⼊入が、⼤大 きなリターンにつながる •  逆にいえば、いくら品質が良良くても、マーケットへの投 ⼊入が遅れれば、⼤大きなビジネスチャンスを失う可能性も ある ビジネスによる判断 顧客の要求例例 「2011年年2⽉月28⽇日までにサービスインしたい.品質につ いては、正常系が動作すること、秒間3件以上のアクセ スに耐えられること」 http://www.flickr.com/photos/maysbusinessschool/4418165194/

Slide 13

Slide 13 text

Doneの定義 http://www.scrumalliance.org/articles/107-‐‑‒how-‐‑‒do-‐‑‒we-‐‑‒know-‐‑‒when-‐‑‒we-‐‑‒are-‐‑‒done プロジェクトごとにDoneの定義(完 了了条件)は異異なるので、案件開始時に 決める必要がある

Slide 14

Slide 14 text

2.  テストの⼿手法 •  WFにおける課題 •  アジャイルにおけるテストに対する考 え⽅方 •  テストの4象限 •  テストの⼿手法 •  ⾃自動化・モニタリング •  外注、パートナー混成チームにおける 品質の作り込み http://www.flickr.com/photos/crystalcampbell/3454977037/

Slide 15

Slide 15 text

ウォーターフォールモデル 要件定義 受⼊入テスト 基本設計 総合テスト 詳細設計 結合テスト 実装・単体テスト ウォーターフォールのV字モデル

Slide 16

Slide 16 text

WFモデルの課題① 構築したソフトウェアが顧客ビジネスのニーズに マッチしているかどうかを確認できるのは、受け ⼊入れ試験の時期になってしまう http://www.flickr.com/photos/coyotejack/2273593999/

Slide 17

Slide 17 text

WFモデルの課題② モノの品質の確定は⼯工期の後半に始まる ⼯工期 品質 ビックバンリスク ⼯工期 品質

Slide 18

Slide 18 text

WFでありがちな話 要件定義は順調です ○○設計は順調です 開発は遅れてますが、挽回可能です 結合試験で重⼤大な問題が出ています 受⼊入試験でニーズ不不⼀一致が判明 多くのリスクが後半に顕在化 http://www.flickr.com/photos/kwazar/2289418010/ リリースできません

Slide 19

Slide 19 text

アジャイルでの品質の作りこみ Scrumの場合 Cancel Gift  wrap Return スプリント 2~∼4週間 返品 スプリントゴール スプリント バックログ 出荷可能な製品の 積み上げ プロダクトバックログ クーポン ギフト包装 クーポン キャンセル 24時間 単体テスト、結合テスト、 受け⼊入れテストがスプリン ト単位(もしくはリリース単 位)で⾏行行われる.

Slide 20

Slide 20 text

アジャイルでの品質の作りこみ スプリント終了了時には「テスト」が完了了.スプリントレ ビューで顧客のビジネス要件への適合性も確認できる http://www.flickr.com/photos/kakutani/2761992149/

Slide 21

Slide 21 text

アジャイルでの品質の作りこみ Scrumではフレームワークの定義のみで、テスト⾃自 動化については触れられていない.しかしアジャイル 開発においてはテスト⾃自動化は必須 ⼩小規模リリースのたびに⼿手 動でテストするとスプリン ト後半になるにつれてテス トコストが膨らむ ⾃自動化しないとソフトウェア規模に応じて、テスト⼯工数の占め る割合が増加していく(=価値への投資が減少)

Slide 22

Slide 22 text

【⾃自動と⼿手動】 機能テスト ストーリーテスト プロトタイプ シミュレーション 【⼿手動】※1 探索索的テスト シナリオテスト ユーザビリティテスト ユーザー受⼊入テスト アルファ版、ベータ版 【⾃自動化】 単体テスト コンポーネントテスト 【ツール】 パフォーマンステスト 負荷テスト セキュリティテスト 第1象限 第2象限 第3象限 第4象限 技術⾯面(技術的品質) ビジネス⾯面(ビジネス的品質) チ ー ム を ⽀支 援 製 品 を 批 評 テストの4象限 ※1  ATDD等では⾃自動化

Slide 23

Slide 23 text

第1象限  チームを⽀支援する技術⾯面のテスト テスト駆動開発などアジャイル開発の中⼼心。 第2象限  チームを⽀支援するビジネス⾯面のテスト 顧客の視点からのハイレベルの機能テストなど。 第3象限  製品を批評するビジネス⾯面のテスト ユーザー受⼊入テスト、探索索的テストなど。 第4象限  技術⾯面のテストを使った製品の批評 パフォーマンステスト、セキュリティテストなど。 テストの4象限 「アジャイルテスト  ―⾼高品質を追求するアジャイルチームにおけるテストの視点―」増⽥田聡⽒氏 http://codezine.jp/devsumi/2010/report/07/  より引⽤用

Slide 24

Slide 24 text

⾃自動化されたテストの要件 ⾃自動化されたテストは以下の条件を満たしている必要がある。 RISE 繰り返し可能  (Repeatable) 何回でも繰り返し実⾏行行できること。また実⾏行行ごとに結果が変わらないこと 独⽴立立性  (Independent) 環境や外部のコンポーネントに依存しないこと テストケースの実⾏行行順序に依存しないこと ⾃自⼰己検証  (Self  validation) テストが成功したか、失敗したかはプログラムが判断する。 (⼈人⼿手で判断しない) 簡単実⾏行行  (Easy) テストの準備に⼤大量量の時間や⼈人⼿手がかかるようにしない

Slide 25

Slide 25 text

【⾃自動と⼿手動】 機能テスト ストーリーテスト プロトタイプ シミュレーション 【⼿手動】 探索索的テスト シナリオテスト ユーザビリティテスト ユーザー受⼊入テスト アルファ版、ベータ版 【⾃自動化】 単体テスト コンポーネントテスト 【ツール】 パフォーマンステスト 負荷テスト セキュリティテスト 第1象限 第2象限 第3象限 第4象限 技術⾯面(技術的品質) ビジネス⾯面(ビジネス的品質) チ ー ム を ⽀支 援 製 品 を 批 評 ツール・⼿手法のマッピング(例例) TDD xUnit PMD,  CPD  … Jmeter WebScarab RatProxy ValGrind  … Selenium Cucumber Rspec FitNess  … CI推奨 CI推奨 CI必須 ⼀一部CI可能

Slide 26

Slide 26 text

単体テスト⾃自動化/TDDとは? XPのプラクティスの中で、最も単体で導⼊入しやすいプラクティスの1つである。 基本的な⽅方法 失敗するテストを書く できる限り早く、テストがパスするような最⼩小限のコード本体を書く リファクタリングをする 適⽤用範囲 通常では、独⽴立立性の⾼高いクラスやファンクションへの適⽤用が良良い。 GUIや分散オブジェクト、⾃自動⽣生成されたコード、DBのスキーマに関するテスト は導⼊入が難しい。 既存システムにおいて、テストが準備されていない場合に、部分的に導⼊入するの は難易易度度が⾼高い。従って新規プロジェクトの初期から導⼊入することが望ましい。 問題点 開発者が仕様を誤解していた場合、誤解に基づくテストコードが作成されるため、 誤解の検知は保証できない。あくまで開発者が作成するコードが、開発者が認識識 するテストコードに適合していることのみが保証される。

Slide 27

Slide 27 text

結合テスト⾃自動化とは? 複数のモジュールやサブシステム、実際の画⾯面を使ったエンドツーエンドテスト 基本的な⽅方法 内部コードではなく振る舞いを確認する.単体レベルの内容は検証しない. Selenium、Cucumberなどを利利⽤用 問題点 基本的にはテストの作成コストは⾼高い. テストに際しては複数のシステムやデータベース等依存性のあるものの準備も含 めて⾃自動化する必要があり、テストケースの実⾏行行に時間がかかることがある.(ス ローテスト問題)

Slide 28

Slide 28 text

レガシープロジェクトへの導⼊入 レガシープロジェクトとは? ⾃自動化されたテストが備わっていないプロジェクトのこと。 利利⽤用している⾔言語やフレームワークには関係ない。 レガシープロジェクトの問題点 機能追加や改修の際に、現⾏行行機能に問題がないことを保証するためには、⼈人⼒力力 による再テストを実施するしかない。従って機能追加・改修が度度重なるたびに、 テストのスコープが膨れ上がり、開発コストの増⼤大につながる。 通常、ユニットテストによるテストを意識識したモジュール間の依存性が低い状 態になっていないため、テストしにくく、結合度度の⾼高さ故、変更更を加えにくく、 予期しない箇所に影響が出やすい。 どうやって導⼊入するか? 結合テストレベルのテストを先に⽤用意し、想定されるアプリケーション全体の 動作をチェックできるようにする。

Slide 29

Slide 29 text

第1象限での⾃自動評価 プロジェクトの特性や要員構成等に応じて決める テスト件数と結果(単体、結合) PMD警告件数 Checkstyle警告件数 カバレージ

Slide 30

Slide 30 text

チーム活動の評価 コード⾏行行数 コミット時間 アクティビティ

Slide 31

Slide 31 text

チーム構成別リスク検出 外注する場合の注意点 品質定義、テスト範囲について委託先に任せているケースが⾮非常に多いが、最 終的に⼤大きなリスクを発注者が背負うことになる。従って 品質定義、テスト範囲、テスト⽅方法、網羅羅性(カバレージ指標)について発注時 に伝えるとともに、⼯工期中随時発注者側がチェックできる仕掛けを⽤用意する。 (例例:レポジトリ環境の提供、委託者作成のソースコードの⾃自動チェック、⾃自 動ビルド) パートナー混成チームの注意点 チームの要員不不⾜足をパートナー(派遣契約等)混成チームで補うことがあるが、 要員のスキルの把握が事前にできないケースが多いため、特定のコーダーが作 成したモジュールに問題が頻発するといった結果になることが多い。 従って、外注する場合と同じように参画の段階で、品質定義、テスト範囲、テ スト⽅方法等を⼗十分に伝える必要がある。また継続的レビューや⾃自動チェックも 必要 なるべく⾃自動化してリスクを⾃自動で検出できる仕掛けを作る ことが望ましい

Slide 32

Slide 32 text

3.  テストのコスト •  ⼿手動テストのコストと⾃自動テストの コストの評価 •  初期開発とエンハンス開発 http://www.flickr.com/photos/webflunkie/5122391694/

Slide 33

Slide 33 text

ITアーキテクト「機能テストの⾃自動化について考える」  より引⽤用 http://www.itarchitect.jp/print/?menu3=24601 テストのコスト評価 作成したテストを何回くらい実⾏行行することになるのか  ? テストの⾃自動化を実現するために要するコストおよび維持コス トはどの程度度か?  

Slide 34

Slide 34 text

初期開発とエンハンス開発 初期開発 エンハンス開発 要員 ⼊入れ替わりはすくない ⼊入れ替わりが多い スキル エース級やアーキテク トの存在 エース級やアーキテク ト不不在 リリース 回数 回数予測可能 運⽤用期間に⽐比例例しリニ アに増加 テスト 件数 件数予測可能 エンハンス内容に⽐比例例 しリニアに増加 エンハンス中はリニアにテスト件数が増加する.テストが⾃自動 化されていない場合、全機能のリグレッションテストを⾏行行うが、 そのボリュームが増え続けてしまう. ⼿手動テストのコストを顧客は負担したがるか?

Slide 35

Slide 35 text

4.  テスト結果の評価 •  テスト結果の評価は誰がする? •  社内の品質管理理部⾨門の役割は? http://www.flickr.com/photos/billsophoto/4175299981/

Slide 36

Slide 36 text

テスト結果の評価は誰がする? 答え  チームと顧客 SIerにおける社内品質基準での画⼀一評価は、顧客に とっては意味がない. (例例)顧客のRequirement 「2011年年2⽉月28⽇日までにサービスインしたい.品質について は、正常系が動作すること、秒間3件以上のアクセスに耐えら れること」 ⇒このようなケースで社内品質基準で評価すると、出荷不不可 能な製品になってしまう. http://www.flickr.com/photos/billward/2837582102/

Slide 37

Slide 37 text

社内の品質管理理部⾨門の役割は? プロジェクトの後半ではなく、プロジェクトの提案活動、 テスト範囲の決定、テスト⽅方法の決定についてチームを⽀支 援する. 社内 品質基準 プロジェクト 品質基準 顧客の要求に あわせて テーラリング 品質管理理部⾨門 + チーム =Doneの定義

Slide 38

Slide 38 text

まとめ ü  品質とはバグの有無ではなくビジネス価値が実現 できるか否かである。 ü  テストには⽬目的が必要。⽬目的によって実施⽅方法や 範囲(完了了条件)は異異なる。 ü  ソフトウェアがニーズにマッチしているかどうか は早期から確認が必要。 ü  テスト⾃自動化は継続的な価値の創出に効果がある。 ü  テスト結果の評価は品質管理理部⾨門が⾏行行うものでは なくチームと顧客が⾏行行う。

Slide 39

Slide 39 text

http://www.flickr.com/photos/meganelizasmith/4096564203/