1時間で分かるSTA (Software Test Automation) #stac2014

32,150 views

Published on

テスト自動化カンファレンス2014(stac2014)の発表資料です。
『システムテスト自動化 標準ガイド』のガイドになっております。
内容に興味をもっていただければ、ぜひ『標準ガイド』を手にとってみてください。

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

No Downloads
Views
Total views
32,150
On SlideShare
0
From Embeds
0
Number of Embeds
24,011
Actions
Shares
0
Downloads
143
Comments
0
Likes
57
Embeds 0
No embeds

No notes for slide

1時間で分かるSTA (Software Test Automation) #stac2014

  1. 1. Copyright2014 Kazuhiro SUZUKI 60minutes STA 1時間でわか(った気になれ)るSTA 2014年12月14日 stac2014@ヤフー株式会社様 鈴木一裕@kz_suzuki
  2. 2. Copyright2014 Kazuhiro SUZUKI 2/78 自己紹介 鈴木一裕@kz_suzuki いわゆるSIerにて、業務システム・インフラ機器用ソフトウェアの テスト・品質管理など 『ソフトウェアの品質を学びまくる』 -もっともバズったのは、「積ん読」という言葉が国際的に普及している件 -2015年からがんばる コミュニティ末端系人財 テスト自動化研究会 探索的テスト読書会など 今回、全体まとめと翻訳パートの監修を担当 家庭と仕事を犠牲にした
  3. 3. Copyright 2014 Kazuhiro SUZUKI 3 / 78 自己紹介  俺の自動化!! ポイント❶ 呼び出す機能とパラメタをExcelで管理! Excelなのでパラメタの追加が容易! Excelマクロでコマンドプロンプトをキック! ポイント❷ コマンドプロンプトがTeraterm マクロを起動! ポイント❸ Teratermでテスト自動実行! マクロ同士は特に連携せず! テスト端末 テスト対象テスト対象 ・・・全然かっこよくない。 Selenium?おいしいの?
  4. 4. Copyright2014 Kazuhiro SUZUKI 4/78 お話しすること 『Software Test Automation』とは? なぜ翻訳するの? 『システムテスト自動化標準ガイド』とは?
  5. 5. Copyright2014 Kazuhiro SUZUKI 5/78 お話の前に プレゼンターは心が弱いです。 積極的な「うなずき」が推奨されます。 積極的な「首かしげ」は推奨されません。 「何言ってるのかわからない」ランプが5回点滅したら、 それは「ホ・ン・ヲ・カ・エ」のサインです。 翔泳社様の特設ブースがあります。 ちょっと安いはずです。
  6. 6. Copyright2014 Kazuhiro SUZUKI 6/78 『SoftwareTestAutomation』とは 著者:Mark Fewster, Dorothy Graham -英国の著名なソフトウェアテストコンサルタント -Graham氏はJaSST’13 Tokyoで基調講演 発売日:1999/8/25 -決して新しい本ではないが、テスト自動化に関する 2014年の調査で、「最も有名で、最も読まれ、最 もおすすめできる本」として多くの票を獲得 物理的なスペック:600ページ、926g -同著者による『Experiences of Test Automation』 (672ページ)との併せ持ちで筋力アップにも効果あり STARで輪読していたTABOK(テスト自動化 知識体系) は、本書を大いに参考にしている ようである!
  7. 7. Copyright2014 Kazuhiro SUZUKI 7/78 Part 1:Techniques for Automating Test Execution テスト自動化において考慮すべき事項を網羅的に扱う -Chapter 1~2: 概論 -Chapter 3~9: 技術的な側面 -Chapter 10~11: ビジネス・組織的な側面 ドメイン・言語・ツールへの依存性が低い Part 2: Test Automation Case Studies テスト自動化の実例をたんまり 扱っている対象が一部、古い 実例については、原著らが新しく別の書籍を出している 『SoftwareTestAutomation』とは
  8. 8. Copyright 2014 Kazuhiro SUZUKI 8 / 78  全体イメージはこんな感じ ❸実行 ❺物理アーキテクチャ ❻前処理 ❻後処理 ❹比較 ❼メンテナンス 自動テストケース❾実行するテストケースの ❿ツールの選択、順番付け、・・・ 選択 ⑪ツールの 導入 ❽メトリクス 『Software Test Automation』とは ビジネス・組織的技術的 手動テスト ケース ❶❷全体の俯瞰 ・・・
  9. 9. Copyright2014 Kazuhiro SUZUKI 9/78 なぜSTAを翻訳するの? 日本では類書が見当たらない -ソフトウェアテストの自動化について一般的な知識を 網羅的に扱った書籍はなさそうだ(多分) -TABOKは概論の概論といったものであり、不十分 → STARのアウトプットとして最適だ! Part 1は依然として有用な内容 -特定の言語やツールに依存せず、一般的な解説書 として平易に読める -テスト自動化の全体像を知りたい技術者・管理者 にとって価値がある! → ここを翻訳対象にしよう! Part 2はさすがに一部、陳腐化が・・・ -ていうか、第2部まで訳したらあと2年かかる -思い切ってSTARで書き下ろしては?(翔泳社様) → それだ!(安易な判断)
  10. 10. Copyright2014 Kazuhiro SUZUKI STAの中身をご紹介します。
  11. 11. Copyright 2014 Kazuhiro SUZUKI 11 / 78 ❸実行 ❺物理アーキテクチャ ❻前処理 ❻後処理 ❹比較 ❼メンテナンス 自動テストケース❾実行するテストケースの ❿ツールの選択、順番付け、・・・ 選択 ⑪ツールの 導入 ❽メトリクス 第1章テスト自動化のコンテキスト ビジネス・組織的技術的 手動テスト ケース ❶❷全体の俯瞰 ・・・
  12. 12. Copyright2014 Kazuhiro SUZUKI 12/78 第1章テスト自動化のコンテキスト テストオートメーター! テスト自動化エンジニアのことです 英語では、test automator -各種Windowsアプリケーションで必ず校正されそうになる -automaterもよく候補に挙がる -「もしかして: udometer」 (「降水量を計る器具からなる計器」・・・) テスト自動化研究会の趣旨 本会では、ソフトウェアテスティングにおける重要な実践技術である「テスト自 動化」(特に上層、システムテスト/受け入れテスト)について、技術領域の 定義と啓蒙、およびそれを主たる価値とする「テスト自動化エンジニア」 (Automator)という職業の国内における創造を推進しています。 テスト自動化研究会Webサイトより
  13. 13. Copyright2014 Kazuhiro SUZUKI 13/78 第1章テスト自動化のコンテキスト 自動化以前にテストはまともなのかね? ダメなテストを自動化してもダメなまま テストケースの4つの特性 -効果的(Effective): 欠陥をどのくらい見つけられる? -経済的(Economic): 実行・分析・デバッグのコストはどのくらい? -発展的(Evolvable): テスト対象の変更に、どのくらい追随しやすい? -典型的(Exemplary): ??? exemplaryって何? 「見せしめのテストケース」、意味がわからねえ・・・ 【形容詞】 1模範的な; 模範となる. 2見せしめの,戒めのための 3典型的な,代表的なWeblioより
  14. 14. Copyright2014 Kazuhiro SUZUKI 14/78 Dorothyさんに聞いてみた。 第1章テスト自動化のコンテキスト な、なんだってーーーΩΩΩ representativeの方が、実態に近い言葉 -positiveなテストを一気に済ませるイメージ -negativeなテストは一つずつってドリル本に書いてあった 4つの言葉をすべて「e」から始まるようにすれば、 頭いい感じになると思った。 翻訳する場合は、この言葉はおかしい。(笑) NOIMAGE (Dorothy 近影)
  15. 15. Copyright2014 Kazuhiro SUZUKI 15/78 第1章テスト自動化のコンテキスト 自動化で、これらは特性は改善される? 効果と典型性は変わらない。 -この2つは、テストケース自体の特性 発展性は、場合によっては下がる -手動だと、人間が判断してちょろっとテストケースを修正したり・・・ 経済性は、初期はまず間違いなく下がる → そもそも、まずはテストを良くするべし テストの品質と、テスト自動化の品質は別物
  16. 16. Copyright2014 Kazuhiro SUZUKI 16/78 第1章テスト自動化のコンテキスト 何を自動化する? テストのアクティビティ、I/JSTQB的には。 自動化に向いているのは、実行、 比較、前後処理 -共通点: おおむね退屈 テストケース実装の自動化は? -第15章で、状態遷移モデルに基づくテストケース生成をカバー -パスの重み付けなどを利用した優先度も提案 コントロール 計 画 分 析 設 計 実 装 実行 評 価 レ ポ ー ト 終 了 実 行 比 較 後処理 前処理
  17. 17. Copyright2014 Kazuhiro SUZUKI 17/78 第1章テスト自動化のコンテキスト 実行の自動化の長所 量の面 -実行コストが安いので、高頻度に実行できる -テスト実行の速度が(割と)速い -テストケース追加コストが安いので、多数のテストを実行できる -リグレッションテストを気軽に実行できる -よって品質に確信が持てる自信につながる#ただしイケテスに限る 質の面 -テストの実行手順の再現性が高い -再利用しやすい -人ができないテストをできることがある。 >たとえば多人数のシミュレーションなど
  18. 18. Copyright2014 Kazuhiro SUZUKI 18/78 第1章テスト自動化のコンテキスト 自動化での留意点 技術面 -手動のテスト実行よりも技術力が必要 -コストも時間もメンテナンスにこそかかる -フレームワークや規準の確立と遵守が重要 -テストでバグゼロ= 品質OKではない >テストの7原則其の1: テストは欠陥があることしか示せない -自動化にとって欠陥がたくさん見つかるわけではない -テスタビリティを考慮することが、開発の制約になることも 組織面 -非現実的な期待を抱きがち -常に組織(特に上層部)のサポートが必要 テスト工程のコストを 90%削減! 摘出バグ5割増!
  19. 19. Copyright2014 Kazuhiro SUZUKI 19/78 手動の方が有利な局面も ツールは工夫も、臨機応変な対応も、探索もしてくれない 自動化で工数が浮いたなら、人ならではのテストを増強しよう! 第1章テスト自動化のコンテキスト 機能テスト ・ストーリーテスト ・プロトタイプ ・シミュレーション 単体テスト コンポーネントテスト 探索的テスト シナリオ ユーザビリティテスト アルファ/ベータ パフォーマンス /負荷テスト セキュリティテスト 「~性テスト」 1 2 4 3 自動と手動 手動 自動 ツール チ ー ム を 支 援 す る 製 品 を 批 評 す る ビジネス面 技術面 『実践アジャイルテスト』より
  20. 20. Copyright 2014 Kazuhiro SUZUKI 20 / 78 ❸実行 ❺物理アーキテクチャ ❻前処理 ❻後処理 ❹比較 ❼メンテナンス 自動テストケース❾実行するテストケースの ❿ツールの選択、順番付け、・・・ 選択 ⑪ツールの 導入 ❽メトリクス 第2章キャプチャーリプレイはテスト自動化ではない ビジネス・組織的技術的 手動テスト ケース ❶❷全体の俯瞰 ・・・
  21. 21. Copyright2014 Kazuhiro SUZUKI 21/78 第2章キャプチャーリプレイはテスト自動化ではない 第2章の目的 記録しただけのスクリプトじゃダメだと理解する -タイトルは言い過ぎ感ある -キャプチャーリプレイだって無能ではない。第3章参照 単純なアプリの自動化でさえ、多くの課題があると理解する -Scribbleという架空のアプリを対象に、擬似的なスクリプト言語を用いて、 自動化のイメージを概観 -そして、自動化におけるハードルを把握 >キャプチャーリプレイがダメなら、どんなアプローチを取る?→ 第3章 >検証において、何をどのくらい比較する?→ 第4章 >どんなツールを使う?→ 第10章・第11章
  22. 22. Copyright2014 Kazuhiro SUZUKI 22/78 iTunesで「john lennon」を検索、をUWSCで記録 第2章キャプチャーリプレイはテスト自動化ではない MMV(1107,22,47)※マウスの移動を記録 ACW(GETID(“iTunes”,“iTunes”),-8,-8,1382,722,0)※要素は座標指定 BTN(LEFT,CLICK,1107,22,78)※マウスのクリックを記録 KBD(VK_J,CLICK,1360)※キー入力を1字ずつ指定 KBD(VK_O,CLICK,1312) KBD(VK_H,CLICK,234) KBD(VK_N,CLICK,250) id = GETID("", "Shell_TrayWnd", -1) id = GETID("iTunes", "iTunes", -1) SENDSTR(id, "john lennon love", 1, True) ●UWSC: 低レベル記録 ●UWSC: 高レベル記録 操作は明確だが、目的はわかりづらい。 いらない情報だらけ。※もちろん役に立つこともあるよ
  23. 23. Copyright2014 Kazuhiro SUZUKI 23/78 第2章キャプチャーリプレイはテスト自動化ではない 長所もあれば短所もある この後の.reviewrcのセッションでも言及ありとのこと! 準備がほとんどいらない。 すぐに記録・再生可能 操作ログを残すことができ る テストの前提条件としての データ準備に使える 他にもたとえば・・・ 構造がないので、そのまま じゃ読みづらい 入力の自動化に過ぎない。 検証は手動 ソフトウェアが変わると、それ に追随して再記録が必要 テストケースの数に比例して 増加する・・・
  24. 24. Copyright 2014 Kazuhiro SUZUKI 24 / 78 ❺物理アーキテクチャ ❻前処理 ❻後処理 ❹比較 ❼メンテナンス 自動テストケース❾実行するテストケースの ❿ツールの選択、順番付け、・・・ 選択 ⑪ツールの 導入 ❽メトリクス 第3章スクリプティングの技法 ビジネス・組織的技術的 手動テスト ケース ❶❷全体の俯瞰 ・・・ ❸実行
  25. 25. Copyright2014 Kazuhiro SUZUKI 25/78 第3章スクリプティングの技法 キャプチャーリプレイがダメなら、どうするんだ? テストスクリプトの構造は、いくつかのレベルに分けられる TABOK(テスト自動化知識体系)による分類 リニアスクリプト レベル1 構造化スクリプト ※TABOKでは明示的な扱いなし レベル2 共有スクリプト ※TABOKでは「機能分割フレームワーク」 データ駆動スクリプト レベル2 キーワード駆動スクリプト モデルベース ※STAではスクリプティングの技法に含めない 第12章 第13章 第15章
  26. 26. Copyright2014 Kazuhiro SUZUKI 26/78 リニアスクリプトから構造化スクリプトへ 分岐により、スクリプトに判定という柔軟性をもたせる 反復により、スクリプトの冗長性を減らす 呼び出しにより、スクリプトを小さい単位に分ける 第3章スクリプティングの技法
  27. 27. Copyright2014 Kazuhiro SUZUKI 27/78 構造化スクリプトから共有スクリプトへ スクリプトを機能ごとに切り離し、再利用する 共有スクリプトの組み合わせによるテストケースの追加が容易 変数はスクリプトに含まれたまま 第3章スクリプティングの技法 A: ログイン B: 登録 C: 変更 Z: ログアウト a1 b1 c1 A: ログイン B: 登録 Z: ログアウト a1 b1 元のテストスクリプト 機能分割された スクリプト 追加されたスクリプト A:ログイン B:登録 C:変更 Z:ログアウト a1 b1 c1
  28. 28. Copyright2014 Kazuhiro SUZUKI 28/78 構造化スクリプトからデータ駆動スクリプトへ スクリプトのデータを変数として切り離す データを変えることで、テストケースの追加が容易 テストケースのシナリオは変えられない A:ログイン B:登録 C:変更 Z:ログアウト 第3章スクリプティングの技法 a1 b1 c1 元のテストスクリプト A:ログイン B:登録 C:変更 Z:ログアウト a1 b1 c1 a2 b2 c2 データ分割された スクリプト 追加されたスクリプト
  29. 29. Copyright2014 Kazuhiro SUZUKI 29/78 さらに、キーワード駆動スクリプトへ スクリプトの機能を分割し、データも切り離す 各機能を「キーワード」として抽象化し、実装を隠蔽する キーワードとデータの組み合わせで、スクリプトを柔軟に追加 ドメインエキスパート・テストエンジニアと、オートメーターを分離 第3章スクリプティングの技法 A: ログイン B: 登録 C: 変更 Z: ログアウト a1 b1 c1 A: ログイン B: 登録 Z: ログアウト a2 b2 元のテストスクリプト 機能とデータを分割 されたスクリプト 追加されたスクリプト A:ログイン B:登録 C:変更 Z:ログアウト a1 b1 c1
  30. 30. Copyright2014 Kazuhiro SUZUKI 30/78 ただし、レベルが高い=最適、ではない プロジェクトの規模や期間に応じた選択が肝要 どのアプローチでも、ドキュメンテーションは必須 レベルの高いアプローチほど、規律の徹底が必要になる 第3章スクリプティングの技法
  31. 31. Copyright 2014 Kazuhiro SUZUKI 31 / 78 ❸実行 ❺物理アーキテクチャ ❻前処理 ❻後処理 ❹比較 ❼メンテナンス 自動テストケース❾実行するテストケースの ❿ツールの選択、順番付け、・・・ 選択 ⑪ツールの 導入 ❽メトリクス 第4章自動比較 ビジネス・組織的技術的 手動テスト ケース ❶❷全体の俯瞰 ・・・
  32. 32. Copyright2014 Kazuhiro SUZUKI 32/78 第4章自動比較 結果の比較こそ、退屈で、自動化したいプロセス! でも、「何を」「どれだけ」「どのように」比較する? たとえば、「新規ユーザの登録」をした場合、・・・ 画面の表示結果だけ確認すればいい? データベースのレコードは? 画面全体を比較する?値だけ比較する? 実行しながら比較?実行後に比較? 毎回変わるようなID・日付けはどう扱う? 何を どれだけ どのように
  33. 33. Copyright2014 Kazuhiro SUZUKI 33/78 第4章自動比較 比較の感度: 差分をどのくらい意識するのか センシティブな比較 -できるだけ多くの情報を比較する -小さな差分でも検出しやすいi.e. 興味のない差分まで検出しがち -動的比較* センシティブだと、テスト実行の時間やメンテコスト大 -同じ差分で何度もコケるはめに・・・ ロバストな比較 -必要最低限の情報に絞って比較する -余計な差分に惑わされずに済むi.e. 予想外の差分を見逃しがち -情報が少ないと、テストがコケた時の分析が大変・・・ 使い分け方の例 -回帰テストなど、安定を確かめるテストはセンシティブに。 -機能追加などでの詳細な確認では、狙った部分のみでロバストに。 擬陽性 擬陰性
  34. 34. Copyright2014 Kazuhiro SUZUKI 34/78 第4章自動比較 比較のタイミング: いつ比較するのか 動的比較 -テストケースを実行しながら比較する -途中段階にしか現れないものも比較できる -スクリプト中に比較処理が追加するので、複雑になることも 実行後比較 -テストケースを実行した後に比較する -テスト実行とは分けて処理することもできる -実装の候補として、シェルスクリプトなども考えられる ※その場合は、テスト実行自動化ツールとの連携が難しい STAでは、自動化ツールへの依存が小さい実行後比較の 方が手厚い。
  35. 35. Copyright2014 Kazuhiro SUZUKI 35/78 第4章自動比較 単純な比較と複雑な比較:どう比較するのか 単純な比較 -ありのままの姿で比較する 複雑な比較 -本質的でない部分、比較する必要のない部分に対処する -grep、sed、awkを使った置換・比較のtips 「フィルタ」へ -比較に使う置換は「フィルタ」として再利用。ツール化も可能 -非プログラマから実装を隠蔽
  36. 36. Copyright2014 Kazuhiro SUZUKI 36/78 第4章自動比較 なお、比較は、しょせん比較です。 「事前に定義した期待値と一致したかどうか」だけ。 間違った期待値に一致するかもしれないし・・・ 比較の対象になっていないところがおかしいかもしれないし・・・ 人間みたいに気を利かせてくれないし・・・
  37. 37. Copyright2014 Kazuhiro SUZUKI 37/78 第4章自動比較 いろいろな種類の出力 テキスト万歳 データベースのレコード、バイナリデータ -ダンプしたり、テキスト変換したりできないか -なるべくツールに依存しないように! CUI系の画面 -文字列が正しい、だけでいいのか? -太字・イタリック・色といった属性が大事なことも GUI系の画面 -たとえばメッセージを考えてみても、メッセージの内容なのか、表示属性なの か、画面に適切に表示されているかなのか 画像、音声、動画、・・・
  38. 38. Copyright 2014 Kazuhiro SUZUKI 38 / 78 ❸実行 ❺物理アーキテクチャ ❻前処理 ❻後処理 ❹比較 ❼メンテナンス 自動テストケース❾実行するテストケースの ❿ツールの選択、順番付け、・・・ 選択 ⑪ツールの 導入 ❽メトリクス 第5章テストウェアアーキテクチャ ビジネス・組織的技術的 手動テスト ケース ❶❷全体の俯瞰 ・・・
  39. 39. Copyright2014 Kazuhiro SUZUKI 39/78 第5章テストウェアアーキテクチャ テスト自動化によって増殖するファイルたち・・・ 「正しくドキュメントが編集されたことを確認」するには? ドキュメント (編集前) 差分 レポート ログ テスト 仕様書 共有 スクリプト ドキュメント (編集後) 固有の スクリプト 共有 スクリプト ドキュメント (比較用) 比較 ツール テストケースの数が増えるとn倍 テストの回数が増えるとn倍
  40. 40. Copyright2014 Kazuhiro SUZUKI 40/78 第5章テストウェアアーキテクチャ 管理なしだと破綻は必定。 第5章は、使用・生成される作成物の論理的な関係と、 維持するための物理的なアーキテクチャについて言及 -テストスクリプトの、プログラムとしてのアーキではない アーキテクチャは、自動化の初期から意識して適用する! 自動か手動か、どのテストレベルか、によらないアーキテクチャ
  41. 41. Copyright2014 Kazuhiro SUZUKI 41/78 第5章テストウェアアーキテクチャ テストウェア テストに使用・生成されるすべての作成物(artifact) テストウェアの課題 とにかく種類と数が多くなる 共有スクリプトなど、効率的に再利用できないといけない -既存スクリプト探索時間は最大2分説 対象ソフトウェアに追随してテストウェアも変わる -どうやってバージョン管理する? -旧バージョンのソフトウェアのためのテストウェアを取り出せるか? 環境ごとにテストウェアも変わる -同じ機能を持った別のスクリプトをどう管理する?
  42. 42. Copyright2014 Kazuhiro SUZUKI 42/78 第5章テストウェアアーキテクチャ テストウェアの区別 テスト資料(Test materials) -テストが実行可能になる前に必要なテストウェア作成物 テスト結果(Test results) -テストの出力 ドキュメント (編集前) 差分 レポート ログ テスト 仕様書 共有 スクリプト ドキュメント (編集後) 固有の スクリプト ドキュメント (比較用) 比較 ツール テスト資料 テスト結果 生成物 2次生成物
  43. 43. Copyright2014 Kazuhiro SUZUKI 43/78 テストケース 第5章テストウェアアーキテクチャ さらに分類し、テストウェアライブラリで管理 テストセット スクリプトセット データセット ユーティリティセット ドキュメント (編集前) テスト 仕様書 共有スクリプト 固有の スクリプト ドキュメント (比較用) ツール類 共有データ 1つ以上のテストケースの集まり テストレベル、目的などに応じて分割 テストセット内のテストウェアは、そのテスト セットでのみ使用される 目的に応じて束ね、テストスイートに・・・ 複数のテストケースで使用するスクリ プトと、そのドキュメントなど 2つ以上のテストセットから参照され データ。たとえばデータベースの基本 的なデータエントリ スタブ、コンバータ、比較ツール、・・・ 関連ドキュメント 関連ドキュメント
  44. 44. Copyright2014 Kazuhiro SUZUKI 44/78 第5章テストウェアアーキテクチャ これでやっと、「テスト資料」は整理できたが? テスト実行のたびに出力される生成物は・・・ バージョン管理は・・・ 環境ごとのテストウェアは・・・ 長谷川さんのセッションでも言及あります!
  45. 45. Copyright 2014 Kazuhiro SUZUKI 45 / 78 ❸実行 ❺物理アーキテクチャ ❻前処理 ❹比較 ❼メンテナンス 自動テストケース❾実行するテストケースの ❿ツールの選択、順番付け、・・・ 選択 ⑪ツールの 導入 ❽メトリクス 第6章前処理と後処理の自動化 ビジネス・組織的技術的 手動テスト ケース ❶❷全体の俯瞰 ・・・ ❻後処理
  46. 46. Copyright2014 Kazuhiro SUZUKI 46/78 第6章前処理と後処理の自動化 テストケース実行前後の作業こそ退屈です。 大まかな分類してみると・・・ -ファイルの生成・削除・再配置 -テストケースの事前条件を満たしているかのチェック -入力や比較のための変換 まとまって現れるので、共通化しやすい 手動の特徴である想像力などもあまりいらない範囲 -本当かな? 実行が手動であっても、前処理と後処理の自動化は有効
  47. 47. Copyright2014 Kazuhiro SUZUKI 47/78 第6章前処理と後処理の自動化 それでも細かい配慮事項は多い。 テストが異常終了した際に、データをどう保全するか テストケースごとに処理を行うか、テストセット単位で行うか -たとえばデータベースの生成とデータの復元 前後処理をどんなツールで実装するのか たとえばシェルスクリプトで実装した場合、テスト自動化ツールとど のように統合するのか 長谷川さんのセッションでも言及あります!
  48. 48. Copyright 2014 Kazuhiro SUZUKI 48 / 78 ❸実行 ❺物理アーキテクチャ ❻前処理 ❻後処理 ❹比較 ❼メンテナンス 自動テストケース❾実行するテストケースの ❿ツールの選択、順番付け、・・・ 選択 ⑪ツールの 導入 ❽メトリクス 第7章保守性の高いテストを構築する ビジネス・組織的技術的 手動テスト ケース ❶❷全体の俯瞰 ・・・
  49. 49. Copyright2014 Kazuhiro SUZUKI 49/78 第7章保守性の高いテストを構築する テストウェアのメンテナンスは忘れられがち! メンテコストは実は、手動より自動で効いてくる 手動は実行しながら修正できる。自動だと失敗に終わる 顧客情報で「電話番号」が増えたら?電話番号とは何? 第7章はアンチパターン集
  50. 50. Copyright2014 Kazuhiro SUZUKI 50/78 第7章保守性の高いテストを構築する テストデータや期待結果も必要 同様に、メンテナンスコストがかかる 実行時間が長時間化する 価値があるテストケースなのか?という観点での 「草刈り」が必要 テストケース数は、多ければ 多いほどイイ!!? 高度なアプローチであれば、ケースの追加は簡単だけど・・・
  51. 51. Copyright2014 Kazuhiro SUZUKI 51/78 第7章保守性の高いテストを構築する 長いテストでコケると、その地点以降の欠陥は 隠れたまま 長いとそれだけ、失敗の際の解析も大変 複雑になるほど、メンテナンスもつらくなる 短いテストケースから始めよう。 長いテストケースは、手動でやるのがいいのかも。 機械がやるテストながら、長くて 複雑なテストケースがイイ!!? 確かにややこしいテストは機械におまかせしたいが・・・
  52. 52. Copyright2014 Kazuhiro SUZUKI 52/78 第7章保守性の高いテストを構築する 特殊な形式では、直接の編集が難しい アプリケーション側で形式が変更になった場合、 作ってしまったデータセットの作り直しで泣く ニュートラルな形式なら、変換プロセスのみの 更新で済む できるだけテキスト形式で保持しよう。 (ただし、わたしはExcelが大好きです) データセットは、アプリケーション 固有の形式で持つのが一番!!? 確かにテストごとの変換の手間はないが・・・
  53. 53. Copyright2014 Kazuhiro SUZUKI 53/78 第7章保守性の高いテストを構築する テスト結果は、OK/NGさえ わかれば十分だ!!? テストウェアの名前は、個々人の 自由な発想で命名しよう!!? などなど、保守性を損なうアンチパターンを事前 に知っておきましょう。 → 詳しくは.reviewrcや午後の伊藤さんのセッ ションでも!
  54. 54. Copyright 2014 Kazuhiro SUZUKI 54 / 78 ❸実行 ❺物理アーキテクチャ ❻前処理 ❻後処理 ❹比較 ❼メンテナンス 自動テストケース❾実行するテストケースの ❿ツールの選択、順番付け、・・・ 選択 ⑪ツールの 導入 ❽メトリクス 第8章メトリクス ビジネス・組織的技術的 手動テスト ケース ❶❷全体の俯瞰 ・・・
  55. 55. Copyright2014 Kazuhiro SUZUKI 55/78 第8章メトリクス “ Measure what is measurableand make measureable what is not so. -Galileo Galilei (1564-1642) ” “ If you can not measureit, you cannot improve it. -LordKelvin(1824-1907) ” 聞き飽きた引用ですね。
  56. 56. Copyright2014 Kazuhiro SUZUKI 56/78 「測る」対象として、テストと自動テストは別物 どちらか一方となれば、まずはテストを測るべし そもそもテストがダメなら、自動化してもダメ 測る目的を、明確に! 第8章メトリクス テスト 自動 テスト >
  57. 57. Copyright2014 Kazuhiro SUZUKI 57/78 DDP(Defect Detection Percentage) その工程までの発見された全欠陥のうち、その 工程で発見された欠陥の割合 機能ごとの分類、深刻度による重み付け、・・・ DDPの低下= テストの欠陥検出能力の低下 DFP(Defect Fix Percentage) 既知の欠陥のうち、修正された欠陥の割合 徹底性 コードカバレッジとか、画面上の部品全部とか 自動的に計測できるものも多い ROI(ReturnOnInvestment) @ITの太田さんの記事に詳しい 第8章メトリクス テスト 自動 テスト
  58. 58. Copyright2014 Kazuhiro SUZUKI 58/78 保守性: ソフトウェアの更新に追随できるか? 更新の発生頻度、更新にかかる時間、・・・ ユーザビリティ:フレームワークは使いやすい? テストの追加の容易さ、トレーニングの時間、・・・ 堅牢性:テストを安定して進められる? テストがつまづく頻度、原因調査の時間、・・・ 移植性:他のプラットフォームでも使える? 効率性:テストの効率は上がっている? テスティングのアクティビティに要する時間の比率 全体工数 テスト失敗時の分析に時間がかかり始める 第8章メトリクス テスト 自動 テスト
  59. 59. Copyright2014 Kazuhiro SUZUKI 59/78 信頼性:判定結果は信頼できる? 擬陽性と擬陰性 いわゆるソフトウェアのreliabilityとちょっと違う 柔軟性: 素早くテストに着手できる? サブセットを取り出すことの簡単さとか 過去のバージョンのとりだしやすさとか。 井芹さんの『テスト自動化の品質モデルの扱 い』では、「テスト環境の品質」として整理 自動テストの品質モデルとして、さらに、「テスタ ビリティの品質」と「テスト設計の品質モデル」を 定義 第8章メトリクス テスト 自動 テスト
  60. 60. Copyright2014 Kazuhiro SUZUKI 60/78 第8章メトリクス おすすめのスターターキット テスト 自動 テスト 重大な欠陥のDDP 自動化に要する時間 自動スクリプトの保守に要 する時間 実行できるテストケース数、 回数など
  61. 61. Copyright 2014 Kazuhiro SUZUKI 61 / 78 ❸実行 ❺物理アーキテクチャ ❻前処理 ❻後処理 ❹比較 ❼メンテナンス 自動テストケース❾実行するテストケースの ❿ツールの選択、順番付け、・・・ 選択 ⑪ツールの 導入 ❽メトリクス 第9章その他の課題 ビジネス・組織的技術的 手動テスト ケース ❶❷全体の俯瞰 ・・・
  62. 62. Copyright2014 Kazuhiro SUZUKI 62/78 まだまだ検討すべきことが! 第9章その他の課題 自動化の 優先順位 実行するテス トの選択 テストの実行 順序の決定 テストステータス、 結果のレポート 手動テスト ケース1 手動テスト ケース2 手動テスト ケース3 手動テスト ケース4 手動テスト ケース5 手動テスト ケース1 手動テスト ケース2 手動テスト ケース3 手動テスト ケース4 手動テスト ケース5 手動テスト ケース1 手動テスト ケース3 手動テスト ケース4 ❶ ❸ ❹ ❷ ❸ ❶ ❷
  63. 63. Copyright2014 Kazuhiro SUZUKI 63/78 第9章その他の課題 自動化の優先順位 すべてのテストケースを自動化しないといけないわけではない 優先順位づけする基準はいくつもある。 -手軽に自動化できるものから? -重要な機能から? -担当者のストレスになっている項目から? 手っ取り早く成果が見えることも、組織としては大事 実行するテストの選択 目的に応じて、適切なテストセットを素早く選べなくては -たとえばテストタイプごと、前回実行時に「失敗」だったもののみ、・・・
  64. 64. Copyright2014 Kazuhiro SUZUKI 64/78 第9章その他の課題 テスト実行順序 テストケースをグルーピングし、論理的に階層化する -たとえば、スモークテスト的な上層と、機能を細かく検証する下層。 上層でこけたら、下層のテストは実行しない -実行環境ごとにグルーピングすることも テストステータス 「成功」と「失敗」だけでは必ずしもうまくいかない 既知の未修正欠陥による「期待された失敗」 -複数の欠陥のうち、一部だけを修正して再テストを行う場合 -自動テストで忘れられがちな、「失敗」に対する調査時間 -最初からテスト対象にしない?逆にすべて「失敗」に倒す
  65. 65. Copyright2014 Kazuhiro SUZUKI 65/78 第9章その他の課題 進捗のモニタリング さまざまなメトリクスを盛り込んだレポート -テストケース数(指定、実行、成功、失敗、・・・) -エラーメッセージ、差分ファイル -テスト失敗の原因のサマリ -経過時間 SQiP2014でBest Report Future Awardを受賞された、 楽天の荻野恒太郎さんの発表がすごく面白いです。 このデータの取得も 自動化しよう!
  66. 66. Copyright 2014 Kazuhiro SUZUKI 66 / 78 ❸実行 ❺物理アーキテクチャ ❻前処理 ❻後処理 ❹比較 ❼メンテナンス 自動テストケース❾実行するテストケースの ❿ツールの選択、順番付け、・・・ 選択 ⑪ツールの 導入 ❽メトリクス 第10章テスト自動化ツールの選択 ビジネス・組織的技術的 手動テスト ケース ❶❷全体の俯瞰 ・・・
  67. 67. Copyright2014 Kazuhiro SUZUKI 67/78 ツールの購入、そして導入は、一大プロジェクト 第10章テスト自動化ツールの選択 購入 プロセス 導入 プロセス ロール の割当 変革の 管理 コミット メント確 保 パイロッ トプロ ジェクト 段階的 導入 継続的 改善 要件の 把握 チーム 作り 制約の 把握 市場の 調査 デモ 評価・ 決定
  68. 68. Copyright2014 Kazuhiro SUZUKI 68/78 ある程度の規模であれば、選定のチームが必要 第10章テスト自動化ツールの選択 購入 プロセス 要件の 把握 チーム 作り 制約の 把握 市場の 調査 デモ 評価・ 決定 選択と評価の責任をもつ、各部 門の代表者を集める 多様なスキルが必要 将来のオートメーターもメンバーに
  69. 69. Copyright2014 Kazuhiro SUZUKI 69/78 そもそも、ツールで解決できる問題なのか? 第10章テスト自動化ツールの選択 購入 プロセス 要件の 把握 チーム 作り 制約の 把握 市場の 調査 デモ 評価・ 決定 自動化しても、テスト自体がよく なるわけではない -リグレッションテストの時間がない? -静的解析やインスペクションでは? -解決策はツールじゃない、場合も 投資効果検討書 -テスティングに要する工数、欠陥の 見逃しによるコスト、ツールのイニシャ ルコスト、ラニングコスト、・・・ -定量化できない要素もあり 制約を的確に把握 -ハードウェア、既存の開発ツール -コスト、社内政治、・・・
  70. 70. Copyright2014 Kazuhiro SUZUKI 70/78 ここでやっと、ツールの調査開始 第10章テスト自動化ツールの選択 購入 プロセス 要件の 把握 チーム 作り 制約の 把握 市場の 調査 デモ 評価・ 決定 候補となるツールのリスト作成 -『テストツールまるわかりガイド』 -選定のための点数付け -絞り込み 自作か購入か -市場にいいものがなければ、自作 -自作は見た目がしょぼく、使いづらい かもしれないが、ニーズに対応しやす い ツール自体の情報の収集 -評価レポート -MLやユーザグループ
  71. 71. Copyright2014 Kazuhiro SUZUKI 71/78 ここでやっと、ツールの調査開始 第10章テスト自動化ツールの選択 購入 プロセス 要件の 把握 チーム 作り 制約の 把握 市場の 調査 デモ 評価・ 決定 ベンダーがいる前提だけど・・・ 自動化のデモのために -基本ルートのテストケースと、「悪 夢」のようなケースを事前に -さらに、中間的なケースを当日に -対象となるアプリケーションでよく起こ る種類の変更に基づくメンテナンス 定量評価 -テストケースの記録のための時間 -比較で検出できた差分の数、・・・ -購入までのプロセスを明確に、・・・
  72. 72. Copyright 2014 Kazuhiro SUZUKI 72 / 78 ❸実行 ❺物理アーキテクチャ ❻前処理 ❻後処理 ❹比較 ❼メンテナンス 自動テストケース❾実行するテストケースの ❿ツールの選択、順番付け、・・・ 選択 ⑪ツールの 導入 ❽メトリクス 第11章組織内へのツールの導入 ビジネス・組織的技術的 手動テスト ケース ❶❷全体の俯瞰 ・・・
  73. 73. Copyright2014 Kazuhiro SUZUKI 73/78 購入よりも、実は導入こそがハードル 第11章組織内へのツールの導入 導入 プロセス ロール の割当 変革の 管理 コミット メント確 保 パイロッ トプロ ジェクト 段階的 導入 継続的 改善 人は変革に対抗する・・・! -今のままでいい、変えたくないという 人の抵抗は大きい -ツールがもたらすメリットを地道に広 めていく広報活動が重要 さまざまなロールが必要 -自動化のエヴァンジェリスト -文化を変革してく人 -ツールの責任者 -上層にいる支援者 上層部からのコミットメント -購入時点で途切れてはダメ -金・人といったリソースと、「変革を進 めるんだ」という態度の両方
  74. 74. Copyright2014 Kazuhiro SUZUKI 74/78 一気に進めると危険 第11章組織内へのツールの導入 導入 プロセス ロール の割当 変革の 管理 コミット メント確 保 パイロッ トプロ ジェクト 段階的 導入 継続的 改善 問題は小さいうちに摘む -「成功」の基準を決めたうえで試行。 楽観的な基準を立て過ぎない -小さいパイロットだからこその失敗も 段階的に導入する -パイロットの欠陥を、ダメな面も含め て広める。生産性は、当初は下がる -教育やトレーニングの準備 -変化の公式f(a, b, c) > z a: 現状に対する不満 b: 共有された将来のビジョン c:aからbに至る工程に関する知識 z:変革に必要となる心理的なコスト ひたすら改善!
  75. 75. Copyright2014 Kazuhiro SUZUKI 超かいつまむと、こんな感じです。
  76. 76. Copyright2014 Kazuhiro SUZUKI 76/78 テストがしょぼければ、自動化してもしょぼい 自動化で欠陥をたくさん見つけられるわけではない 問題がないと教えてくれるわけでもない 自動化では、メンテナンスコストこそ重い だからこそドキュメントの整備を忘れるな 標準と規律なしには長続きしない えらい人のサポートが継続的に重要 自動化で浮いた時間で、人間ならではのテストを! STAで繰り返し強調されること
  77. 77. Copyright2014 Kazuhiro SUZUKI 77/78 翻訳について 英 語 か ら 入 力 技 術 的な 理 解 日 本 語 で 出 力 レ ビ ュ ー 全体的な整合性 用語・用字の統一 訳注などの補強・・・ レ ビ ュ ー テスト 実装 設計(済) ビッグバンテスト によるデスマ・・!! ユーザ受け入れテストお願いします! ユーザ受け 入れテスト
  78. 78. Copyright2014 Kazuhiro SUZUKI 質問は後のセッションの 方々へどうぞ!

×