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

1,693 views

Published on

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

slide for OpenJam of Ultimate Agilist Tokyo 2012

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,693
On SlideShare
0
From Embeds
0
Number of Embeds
511
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

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

  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

×