Upgrade to Pro — share decks privately, control downloads, hide ads and more …

20110127_devloveテストの話.pdf

Ryutaro YOSHIBA
April 13, 2012
100

 20110127_devloveテストの話.pdf

Ryutaro YOSHIBA

April 13, 2012
Tweet

Transcript

  1. テスト範囲や内容の決め⽅方 •  範囲は  ⽬目的  に依存する •  範囲は  ROI  に依存する • 

    範囲は  リスク  に依存する ⇒テスト範囲や内容とその完了了の条件は WFでもアジャイルでも重要 http://www.flickr.com/photos/benbunch/4816136249/
  2. •  システムが競争⼒力力の源泉になる •  サービスやシステムの早期のマーケットへの投⼊入が、⼤大 きなリターンにつながる •  逆にいえば、いくら品質が良良くても、マーケットへの投 ⼊入が遅れれば、⼤大きなビジネスチャンスを失う可能性も ある ビジネスによる判断

    顧客の要求例例 「2011年年2⽉月28⽇日までにサービスインしたい.品質につ いては、正常系が動作すること、秒間3件以上のアクセ スに耐えられること」 http://www.flickr.com/photos/maysbusinessschool/4418165194/
  3. 2.  テストの⼿手法 •  WFにおける課題 •  アジャイルにおけるテストに対する考 え⽅方 •  テストの4象限 • 

    テストの⼿手法 •  ⾃自動化・モニタリング •  外注、パートナー混成チームにおける 品質の作り込み http://www.flickr.com/photos/crystalcampbell/3454977037/
  4. アジャイルでの品質の作りこみ Scrumの場合 Cancel Gift  wrap Return スプリント 2~∼4週間 返品 スプリントゴール

    スプリント バックログ 出荷可能な製品の 積み上げ プロダクトバックログ クーポン ギフト包装 クーポン キャンセル 24時間 単体テスト、結合テスト、 受け⼊入れテストがスプリン ト単位(もしくはリリース単 位)で⾏行行われる.
  5. 【⾃自動と⼿手動】 機能テスト ストーリーテスト プロトタイプ シミュレーション 【⼿手動】※1 探索索的テスト シナリオテスト ユーザビリティテスト ユーザー受⼊入テスト

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

    アルファ版、ベータ版 【⾃自動化】 単体テスト コンポーネントテスト 【ツール】 パフォーマンステスト 負荷テスト セキュリティテスト 第1象限 第2象限 第3象限 第4象限 技術⾯面(技術的品質) ビジネス⾯面(ビジネス的品質) チ ー ム を ⽀支 援 製 品 を 批 評 ツール・⼿手法のマッピング(例例) TDD xUnit PMD,  CPD  … Jmeter WebScarab RatProxy ValGrind  … Selenium Cucumber Rspec FitNess  … CI推奨 CI推奨 CI必須 ⼀一部CI可能
  7. 単体テスト⾃自動化/TDDとは? XPのプラクティスの中で、最も単体で導⼊入しやすいプラクティスの1つである。 基本的な⽅方法 失敗するテストを書く できる限り早く、テストがパスするような最⼩小限のコード本体を書く リファクタリングをする 適⽤用範囲 通常では、独⽴立立性の⾼高いクラスやファンクションへの適⽤用が良良い。 GUIや分散オブジェクト、⾃自動⽣生成されたコード、DBのスキーマに関するテスト は導⼊入が難しい。

    既存システムにおいて、テストが準備されていない場合に、部分的に導⼊入するの は難易易度度が⾼高い。従って新規プロジェクトの初期から導⼊入することが望ましい。 問題点 開発者が仕様を誤解していた場合、誤解に基づくテストコードが作成されるため、 誤解の検知は保証できない。あくまで開発者が作成するコードが、開発者が認識識 するテストコードに適合していることのみが保証される。
  8. チーム構成別リスク検出 外注する場合の注意点 品質定義、テスト範囲について委託先に任せているケースが⾮非常に多いが、最 終的に⼤大きなリスクを発注者が背負うことになる。従って 品質定義、テスト範囲、テスト⽅方法、網羅羅性(カバレージ指標)について発注時 に伝えるとともに、⼯工期中随時発注者側がチェックできる仕掛けを⽤用意する。 (例例:レポジトリ環境の提供、委託者作成のソースコードの⾃自動チェック、⾃自 動ビルド) パートナー混成チームの注意点 チームの要員不不⾜足をパートナー(派遣契約等)混成チームで補うことがあるが、

    要員のスキルの把握が事前にできないケースが多いため、特定のコーダーが作 成したモジュールに問題が頻発するといった結果になることが多い。 従って、外注する場合と同じように参画の段階で、品質定義、テスト範囲、テ スト⽅方法等を⼗十分に伝える必要がある。また継続的レビューや⾃自動チェックも 必要 なるべく⾃自動化してリスクを⾃自動で検出できる仕掛けを作る ことが望ましい
  9. 初期開発とエンハンス開発 初期開発 エンハンス開発 要員 ⼊入れ替わりはすくない ⼊入れ替わりが多い スキル エース級やアーキテク トの存在 エース級やアーキテク

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