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.

テスト自動化の現場から~テスト自動化の保守の話~

2,023 views

Published on

自動化したテストは一度作ったら終わりではなく、テスト対象への仕様追加や仕様変更、テスト環境の変化などに適応していかなければなりません。この発表では、実際の現場で起きた自動化の失敗例や、成功例をご紹介します。

Published in: Engineering
  • D0WNL0AD FULL ▶ ▶ ▶ ▶ http://1lite.top/7IupV ◀ ◀ ◀ ◀
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

テスト自動化の現場から~テスト自動化の保守の話~

  1. 1. 株式会社 ウェブレッジ 浦山 さつき テスト自動化の現場から ~テスト自動化の保守の話~
  2. 2. 株式会社 ウェブレッジ 優しいシステム、ステキな品質。 サービス検証事業 ユーザビリティ調査 現状サイト分析 ヒューリスティック調査 システム検証事業 請負検証 常駐検証 品質改善コンサルティング 自動化コンサルティング
  3. 3. 自己紹介 浦山 さつき  仕事 エンプラ・金融系システムのテスト テスト設計、テスト自動化、マネジメント、教育  所属コミュニティ テスト自動化研究会 しなてす  書籍 『システムテスト自動化標準ガイド』共訳  登壇 WACATE2015夏 CEDEC2014 JaSST ’14 Tohoku JaSST ’13 Tokyo 他
  4. 4. 自己紹介 自動化したシステムの紹介 店舗情報ポータルサイトの品質管理業務 顧客管理システムのテスト 自動化あるある 自動テストの保守 本セッションの流れ
  5. 5. 店舗情報ポータルサイトの品質管理業務 自動化したシステムの紹介①
  6. 6. 店舗情報ポータルサイト開発でのお話 店舗情報 ポータル サイト 情報検索 一般ユーザー • 約60万件の店舗情報を扱うWEBサービス 店舗情報 クーポン配信 店舗 店舗情報 クーポン登録 システム 管理者 新規登録
  7. 7. システム詳細 • 月に100コンテンツ/機能のリリースが行われる 社員数1800名の企業が運用しているシステム 品質管理部は、リリース前のテストからクレーム解消施策 など、顧客満足度向上のために幅広く対応していた
  8. 8. 体制イメージ 品質管理部 システム開発部 A案件 企画部 B案件 C案件 … ③リリース判定結果 フィードバック ②依頼
  9. 9. 品質管理部の仕事 • 顧客満足度を上げるための様々な施策 リリース判定 各コンテンツの機能障害検知、速度調査 店舗情報の公開、非公開確認 リンク切れチェック 機能、非機能の確認 競合比較、パフォーマンス調査 公開されている情報のコンプライアンスチェック 開発チームへのフィードバック 等
  10. 10. 顧客満足度を上げるための様々な施策 例 新規登録・更新 反映 各コンテンツの機能障害検知、速度調査 施策 • 機能障害を検知する 仕組みの導入 • 障害の定義 • 許容時間の定義 店舗 クレーム 店舗情報 ポータル サイト
  11. 11. 情報検索 公開日 顧客満足度を上げるための様々な施策 例 店舗情報 ポータル サイト 新規登録 店舗情報の公開確認 施策 • 公開日に情報が表示 されるか確認 システム 管理者 クレーム
  12. 12. 自動化の背景 0.0 0.5 1.0 1.5 2.0 2.5 2011 2012 2013 2014 2015 倍 ユニークユーザー数 有料加盟店舗数 5万件 を突破
  13. 13. 自動テストのライフサイクル ①影響調査 ②修正箇所と 修正方法の 特定 サービス追加要件 テスト実施 報告 リリース ③修正 及び 試行 毎日
  14. 14. 顧客管理システムのテスト 自動化したシステムの紹介②
  15. 15. 顧客管理システム開発でのお話 顧客管理 システム お客様情報 新規登録 -個人情報 -支払方法 ‐サービス内容 変更窓口 • 数千万人の顧客情報を取扱うクライアントシステム 顧客 在庫管理 システム 料金管理 システム
  16. 16. システムの詳細 • 開発規模は月1000人以上 • リリース後の不具合が致命傷 数時間でニュース沙汰 信頼失墜 大損害
  17. 17. システムテストチーム 体制イメージ テスト自動化チーム ×10人 ・回帰テストの自動化 ・自動テストの運用 開発チーム A機能 B機能 C機能 … A機能 B機能 C機能 …
  18. 18. テスト対象システムのライフサイクル ①199X年 新規開発 ⑤サービス終了 ②設計 影響調査 ③修正の実施 ④テスト ⑥201X年 システム刷新 サービス追加要件 リリース 3か月毎
  19. 19. 自動テストのスコープ ①199X年 新規開発 ⑤サービス終了 ②設計 影響調査 ③修正の実施 ④-1 ユニットテスト ⑥201X年 システム刷新 サービス追加要件 リリース ④-2 統合テスト ④-3 システムテスト ④-4 受入れテスト ④-3 システムテスト
  20. 20. 自動テストのライフサイクル ①2005年 新規開発 ⑤不要な テストの除外 ⑥2011年 テスト自動化 システム刷新 3か月毎 ②影響調査 ③修正の実施 ④試行 サービス追加要件 テスト実施 及び リリース判定
  21. 21. 数年保守し続けた経験から 自動テストの保守あるあるを ご紹介します
  22. 22. テスト自動化の保守あるある 自動化の現場から
  23. 23. あるある1 自動テストの認知度が低い
  24. 24. 事象 急に動かなくなる自動テスト • ある朝、いつも通り出勤したら、 定期実行しているテストに大量のエラーが!! • 品質管理チームを介さないリリースが入っていた>< 事例1
  25. 25. 対策 伝達体制の強化と回避策の規定 • 伝達体制の強化 • 把握できていない箇所で問題が起きた時の 回避策を用意 いつまでに報告が必要か確認 手動実行でかかる時間を予め算出 報告しなければならない時間から逆算し、修正にかけられ る時間を算出 修正が間に合わない場合は手動で実行 事例1
  26. 26. 事象 チケットの後回し • 不具合の報告をしたが、いつまで経っても改修され ない。 • 他のチームが報告した不具合は着手されているよう だ。 事例2
  27. 27. 対策 有力者に協力を仰ぐ • 上層部からの連携 • 認知されている部署への協力を仰ぐ 事例2
  28. 28. あるある2 構造化されていないスクリプト
  29. 29. 事象 修正が追いつかない • 影響範囲が大きすぎて、修正が追いつかない! • 似たようなスクリプトが多すぎる!! Test1 Test2 Test4Test3 事例1
  30. 30. 対策 スクリプトの構造化 • スクリプトの構造化が有効。 レベル1 Linear Script Frameworks レベル2 Data-driven Frameworks Functional Decomposition Frameworks レベル3 Keyword-Driven Frameworks Model-based Framework TABOK Segment 2: Macroscopic Process Skills Skill Category 4: Test Automation Frameworks
  31. 31. 対策 スクリプトの構造化 例 Class サービス設定画面 Function ユーザー名(Name) TextBox(“UserName”).Type Name Function ログイン Button(“Login”).Click Class 検索画面 Function 検索(id) TextBox(“UserId”).type id Button(“Serch”).Click Function 種別選択(item) SelectBox(“UserId”).select item パラメタ なにを順番どこに どうする スクリプトスクリプトスクリプト 事例2 操作順 操作画面 値 1 検索 A 2 種別選択 変更
  32. 32. 対策 スクリプトの構造化 例 パラメタ なにを順番どこに どうする スクリプトスクリプトスクリプト 操作順の変更操作対象の変更 設定値の変更 変更箇所が 見つけやすい 事例2
  33. 33. あるある3 サーバーのパンク
  34. 34. 事象 画面キャプチャでログサーバーがパンク • 保守し続けて半年、見たことのないエラーが出た。 • ツールの初期設定のまま実行していたら、ログの容 量でパンク!! 事例2
  35. 35. 対策 キャプチャ取得や保存タイミングの整理 • エビデンスやログの解析に不要な画面キャプチャの 削除 • 過去ログの保存ルールを決定 事例2
  36. 36. あるある4 放ったらかしのテストケース
  37. 37. 事象 テストしていないところからのバグ発見 • テストの保守を怠った結果、 テストケース以外の箇所からデグレードを発見! 事例2
  38. 38. 対策 テストの草刈り • テストを自動化して満足することなかれ。 • テスト自身の保守も忘れずに。 テストケースの追加と削除 修正に伴う自動テストのテストも忘れずに。 事例2
  39. 39. 対策 テストの草刈り タイミング ②影響調査 ③修正の実施 ④試行 サービス追加要件 テスト実施 及び リリース判定 テストケースの保守 事例2
  40. 40. あるある5 担当者の撤退
  41. 41. 事象 主担当者が抜けたら自動テストが回らない • 数年来の自動化担当が抜けた • 次の担当者が決まらない • 上層部への一時的な引き継ぎによって、自動化が 途絶える 事例2
  42. 42. 対策 担当者同士での引き継ぎをしよう • 後継者と十分な引き継ぎ期間が必要 • 学習コストを下げる工夫をする 不必要な作り込みをしない 秘伝のタレを作らない ドキュメントは定期的に更新する 事例2
  43. 43. まとめ
  44. 44. 参考 テスト自動化標準ガイド 7章 保守性の高いテストを構築する 7.2 テストメンテナンスの要因 テストケースの数 テストデータの量 テストデータの形式 テストケースの実行時間 テストケースのデバッグ能力 テストの相互依存性 命名規則 テストの複雑性 テストドキュメンテーション
  45. 45. 自動テストも 保守が必要です。 お忘れなく
  46. 46. ご清聴 ありがとうございました

×