Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

ビジネス的に高価値なアジャイルテスト

1,983 views

Published on

http://ultimateagilist.doorkeeper.jp/events/1823

slide for OpenJam of Ultimate Agilist Tokyo 2012

Published in: Technology
  • Hello! I can recommend a site that has helped me. It's called ⇒ www.HelpWriting.net ⇐ So make sure to check it out!
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

ビジネス的に高価値なアジャイルテスト

  1. 1. ビジネス的に高価値なlean/agile テスト実践 2012/11/17(Sat) tchikuba@bilcom
  2. 2. about tchikuba 所属  ビルコム株式会社 自社サービス  ReBuy http://rebuy.jp/  Okkru https://okkru.jp 役割  開発 PM  PM = Playing Manager いいね!  Linux 、ビール、宇宙平和 facebook/twitter  tchikuba
  3. 3. 自社サービス: ReBuy
  4. 4. 自社サービス: Okkru
  5. 5. 本題。テストの目的はシステム品質を担保すること。ではシステム品質をどう担保するか?
  6. 6. waterfall な品質担保フロー 原則各フェーズ毎にチェック  要件定義  基本設計  詳細設計 高価値!  単体試験  結合試験  受入試験 各フェーズ毎の納品物チェック 各フェーズ毎のレビュー 受入試験で要件担保 要件変化がない前提・・・
  7. 7. lean/agile なテストではシステム品質をどう担保するか?
  8. 8. テスト自動化が肝 Project としてテスト自動化は主 に以下の通り  受入試験:ユーザ主動線をカバー  結合/単体試験:ユニットテスト テスト自動化の優先度  ビジネス価値:単体<結合<受入  開発フェーズ:単体>結合>受入
  9. 9. 必要な実行環境の要件 環境を用途により分ける必要性 ( ビルド ) デプロイ自動化 リポジトリ変更をタイムリーにハン ドル デプロイ時に必ずテストを自動実行 開発者にタイムリーに通知 本番環境でユーザテスト実施 デザインモックをタイムリーに最新 化
  10. 10. 実行環境 環境 (LAMP)  開発環境:開発コード  ステージング環境:リポジトリ最新コード  本番環境:ある時点のリビジョン Capistrano  環境毎のデプロイをコマンド化  DB 更新 (migrate)  facebook グループに更新内容を通知 Jenkins  テストケース実行  ステージング環境自動デプロイ  本番環境用フローチェック  デザインモック最新化 Facebook  テストユーザ  開発者用グループ 実装  ブランチ非採用  フラグ採用: β 版 view,js,css のみ
  11. 11. lean/agile なテスト結果、もたらされた価値
  12. 12. たくさんあるので抜粋 イケてないコードを発見し凹む 要件の迷走をコードに見出す リファクタリングに挑戦 S 級障害を未然に防止 外部要因が明確になる 要件を開発起点で洗練
  13. 13. 以上 T.Chikuba@bilcomfacebook/twitter :  tchikuba
  14. 14. 【 FYI 】テストフレームワーク種別 当 Project 環境は LAMP なので PHPUnit を採用 採用している PHPUnit は大別して以 下の通り  単体試験用  PHPUnit_Framework_TestCase  Zend_Test_PHPUnit_ControllerTestCase  受入試験用 PHPUnit_Extensions_Selenium2TestCase ※ 単体試験用の 2 つとは全く別モノなので注 意!
  15. 15. 【 FYI 】 PHPUnit_Framework_TestCase 主に Model の単体試験に採用 複数の Model を多用する ServiceModel は setUp メソッド内に て MOCK_OBJECT を定義して疎結 合化  if(!defined(MOCK_OBJECT)) define(MOCK_OBJECT, true);  $this->getModel(‘[Model 名 ]’);  ※直接 new× 単体の Model で完結する Model はス テージング環境 DB に接続して試験
  16. 16. 【 FYI 】 Zend_Test_PHPUnit_ControllerTestCase 主に Controller の単体試験に採用 以下環境でサポート外なので注意  Zendframework1.x  PHPUnit3.6 以降 とはいえ意外と便利なので PHPUnit3.7 系でも無理やり使 用 無理やり使用 tips  テストケース落ちでも unserialize エラーが発生し実際のエ ラーの中身が不明  なので /usr/share/pear/PHPUnit/Util/PHP.php の 238 行目付 近をまさぐってテスト実行結果を /tmp 等に出力  出力内容に実際のエラーが記述されている MOCK_OBJECT は基本必ず setUp() 内で定義 新規に手を入れる Action のテストケースをまず作成 結果、 Controller 実装における 3 大原則を守れるように  フローコントロールに注力するよう実装  Model データ引き回しは厳禁  セッションを多用しない
  17. 17. 【 FYI 】 PHPUnit_Extensions_Selenium2TestCase 現在本番環境デプロイ直後に Capistrano→Jenkins で自動実行 ユーザが実行する遷移を忠実に再現 クリティカルな問題を未然に防ぐ対 策  ホントはステージング環境でも動かし たい CentOS で動く SeleniumServer に対 して実行 webDriver の擬似ブラウザで動作確 認
  18. 18. 【 FYI 】Selenium2 のメリット/デメリット メリット  htmlunit が使える  Selenium1 系だと htmlunit が使用不可 ( そうだっ た)  最新なので更新が多頻度 デメリット  SeleniumIDE によるテストコード生成が出来な い  IDE によるケースが既にあれば移植の手間  ただし移植は比較的容易  ドキュメント皆無  github と戦う  フレームワークチェック用のテストコード参照で 書ける
  19. 19. 【 FYI 】結合試験デバッグtips テストコードサンプル  https://github.com/sebastianbergmann テスト対象 html  https://github.com/sebastianbergmann

×