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

2. Copyright2014 Kazuhiro SUZUKI 2/78 自己紹介 鈴木一裕@kz_suzuki いわゆるSIerにて、業務システム・インフラ機器用ソフトウェアのテスト・品質管理など 『ソフトウェアの品質を学びまくる』 -もっともバズったのは、「積ん読」という言葉が国際的に普及している件 -2015年からがんばる コミュニティ末端系人財 テスト自動化研究会 探索的テスト読書会など 今回、全体まとめと翻訳パートの監修を担当 家庭と仕事を犠牲にした

3. Copyright 2014 Kazuhiro SUZUKI 3 / 78 自己紹介  俺の自動化!! ポイント❶ 呼び出す機能とパラメタをExcelで管理！ Excelなのでパラメタの追加が容易！ Excelマクロでコマンドプロンプトをキック！ポイント❷ コマンドプロンプトがTeraterm マクロを起動！ポイント❸ Teratermでテスト自動実行！マクロ同士は特に連携せず！テスト端末テスト対象テスト対象・・・全然かっこよくない。 Selenium？おいしいの？

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. 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. Copyright 2014 Kazuhiro SUZUKI 8 / 78  全体イメージはこんな感じ ❸実行 ❺物理アーキテクチャ ❻前処理 ❻後処理 ❹比較 ❼メンテナンス自動テストケース❾実行するテストケースの ❿ツールの選択、順番付け、・・・選択 ⑪ツールの導入 ❽メトリクス『Software Test Automation』とはビジネス・組織的技術的手動テストケース ❶❷全体の俯瞰・・・

9. Copyright2014 Kazuhiro SUZUKI 9/78 なぜSTAを翻訳するの？ 日本では類書が見当たらない -ソフトウェアテストの自動化について一般的な知識を網羅的に扱った書籍はなさそうだ（多分） -TABOKは概論の概論といったものであり、不十分 → STARのアウトプットとして最適だ！ Part 1は依然として有用な内容 -特定の言語やツールに依存せず、一般的な解説書として平易に読める -テスト自動化の全体像を知りたい技術者・管理者にとって価値がある！ → ここを翻訳対象にしよう！ Part 2はさすがに一部、陳腐化が・・・ -ていうか、第2部まで訳したらあと2年かかる -思い切ってSTARで書き下ろしては？（翔泳社様） → それだ！（安易な判断）

12. Copyright2014 Kazuhiro SUZUKI 12/78 第1章テスト自動化のコンテキスト テストオートメーター！ テスト自動化エンジニアのことです 英語では、test automator -各種Windowsアプリケーションで必ず校正されそうになる -automaterもよく候補に挙がる -「もしかして: udometer」（「降水量を計る器具からなる計器」・・・） テスト自動化研究会の趣旨本会では、ソフトウェアテスティングにおける重要な実践技術である「テスト自動化」（特に上層、システムテスト／受け入れテスト）について、技術領域の定義と啓蒙、およびそれを主たる価値とする「テスト自動化エンジニア」（Automator）という職業の国内における創造を推進しています。テスト自動化研究会Webサイトより

13. Copyright2014 Kazuhiro SUZUKI 13/78 第1章テスト自動化のコンテキスト 自動化以前にテストはまともなのかね？ ダメなテストを自動化してもダメなまま テストケースの4つの特性 -効果的(Effective): 欠陥をどのくらい見つけられる？ -経済的(Economic): 実行・分析・デバッグのコストはどのくらい？ -発展的(Evolvable): テスト対象の変更に、どのくらい追随しやすい？ -典型的(Exemplary): ？？？ exemplaryって何？「見せしめのテストケース」、意味がわからねえ・・・【形容詞】 1模範的な; 模範となる. 2見せしめの，戒めのための 3典型的な，代表的なWeblioより

14. Copyright2014 Kazuhiro SUZUKI 14/78 Dorothyさんに聞いてみた。第1章テスト自動化のコンテキストな、なんだってーーーΩΩΩ representativeの方が、実態に近い言葉 -positiveなテストを一気に済ませるイメージ -negativeなテストは一つずつってドリル本に書いてあった 4つの言葉をすべて「e」から始まるようにすれば、頭いい感じになると思った。翻訳する場合は、この言葉はおかしい。(笑) NOIMAGE (Dorothy 近影)

15. Copyright2014 Kazuhiro SUZUKI 15/78 第1章テスト自動化のコンテキスト 自動化で、これらは特性は改善される？ 効果と典型性は変わらない。 -この2つは、テストケース自体の特性 発展性は、場合によっては下がる -手動だと、人間が判断してちょろっとテストケースを修正したり・・・ 経済性は、初期はまず間違いなく下がる → そもそも、まずはテストを良くするべしテストの品質と、テスト自動化の品質は別物

16. Copyright2014 Kazuhiro SUZUKI 16/78 第1章テスト自動化のコンテキスト 何を自動化する？ テストのアクティビティ、I/JSTQB的には。 自動化に向いているのは、実行、比較、前後処理 -共通点: おおむね退屈 テストケース実装の自動化は？ -第15章で、状態遷移モデルに基づくテストケース生成をカバー -パスの重み付けなどを利用した優先度も提案コントロール計画分析設計実装実行評価レポート終了実行比較後処理前処理

17. Copyright2014 Kazuhiro SUZUKI 17/78 第1章テスト自動化のコンテキスト 実行の自動化の長所 量の面 -実行コストが安いので、高頻度に実行できる -テスト実行の速度が（割と）速い -テストケース追加コストが安いので、多数のテストを実行できる -リグレッションテストを気軽に実行できる -よって品質に確信が持てる自信につながる#ただしイケテスに限る 質の面 -テストの実行手順の再現性が高い -再利用しやすい -人ができないテストをできることがある。 >たとえば多人数のシミュレーションなど

18. Copyright2014 Kazuhiro SUZUKI 18/78 第1章テスト自動化のコンテキスト 自動化での留意点 技術面 -手動のテスト実行よりも技術力が必要 -コストも時間もメンテナンスにこそかかる -フレームワークや規準の確立と遵守が重要 -テストでバグゼロ= 品質OKではない >テストの7原則其の1: テストは欠陥があることしか示せない -自動化にとって欠陥がたくさん見つかるわけではない -テスタビリティを考慮することが、開発の制約になることも 組織面 -非現実的な期待を抱きがち -常に組織（特に上層部）のサポートが必要テスト工程のコストを 90%削減！摘出バグ5割増！

19. Copyright2014 Kazuhiro SUZUKI 19/78 手動の方が有利な局面も ツールは工夫も、臨機応変な対応も、探索もしてくれない 自動化で工数が浮いたなら、人ならではのテストを増強しよう！第1章テスト自動化のコンテキスト機能テスト・ストーリーテスト・プロトタイプ・シミュレーション単体テストコンポーネントテスト探索的テストシナリオユーザビリティテストアルファ/ベータパフォーマンス /負荷テストセキュリティテスト「～性テスト」 1 2 4 3 自動と手動手動自動ツールチームを支援する製品を批評するビジネス面技術面『実践アジャイルテスト』より

21. Copyright2014 Kazuhiro SUZUKI 21/78 第2章キャプチャーリプレイはテスト自動化ではない 第2章の目的 記録しただけのスクリプトじゃダメだと理解する -タイトルは言い過ぎ感ある -キャプチャーリプレイだって無能ではない。第3章参照 単純なアプリの自動化でさえ、多くの課題があると理解する -Scribbleという架空のアプリを対象に、擬似的なスクリプト言語を用いて、自動化のイメージを概観 -そして、自動化におけるハードルを把握 >キャプチャーリプレイがダメなら、どんなアプローチを取る？→ 第3章 >検証において、何をどのくらい比較する？→ 第4章 >どんなツールを使う？→ 第10章・第11章

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. Copyright2014 Kazuhiro SUZUKI 23/78 第2章キャプチャーリプレイはテスト自動化ではない 長所もあれば短所もある この後の.reviewrcのセッションでも言及ありとのこと！ 準備がほとんどいらない。すぐに記録・再生可能 操作ログを残すことができる テストの前提条件としてのデータ準備に使える他にもたとえば・・・ 構造がないので、そのままじゃ読みづらい 入力の自動化に過ぎない。検証は手動 ソフトウェアが変わると、それに追随して再記録が必要 テストケースの数に比例して増加する・・・

25. Copyright2014 Kazuhiro SUZUKI 25/78 第3章スクリプティングの技法 キャプチャーリプレイがダメなら、どうするんだ？ テストスクリプトの構造は、いくつかのレベルに分けられる TABOK(テスト自動化知識体系)による分類リニアスクリプトレベル1 構造化スクリプト ※TABOKでは明示的な扱いなしレベル2 共有スクリプト ※TABOKでは「機能分割フレームワーク」データ駆動スクリプトレベル2 キーワード駆動スクリプトモデルベース ※STAではスクリプティングの技法に含めない第12章第13章第15章

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. Copyright2014 Kazuhiro SUZUKI 28/78 構造化スクリプトからデータ駆動スクリプトへ スクリプトのデータを変数として切り離す データを変えることで、テストケースの追加が容易 テストケースのシナリオは変えられない A:ログイン B:登録 C:変更 Z:ログアウト第3章スクリプティングの技法 a1 b1 c1 元のテストスクリプト A:ログイン B:登録 C:変更 Z:ログアウト a1 b1 c1 a2 b2 c2 データ分割されたスクリプト追加されたスクリプト

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

32. Copyright2014 Kazuhiro SUZUKI 32/78 第4章自動比較 結果の比較こそ、退屈で、自動化したいプロセス！ でも、「何を」「どれだけ」「どのように」比較する？ たとえば、「新規ユーザの登録」をした場合、・・・画面の表示結果だけ確認すればいい？データベースのレコードは？画面全体を比較する？値だけ比較する？実行しながら比較？実行後に比較？毎回変わるようなID・日付けはどう扱う？何をどれだけどのように

33. Copyright2014 Kazuhiro SUZUKI 33/78 第4章自動比較 比較の感度: 差分をどのくらい意識するのか センシティブな比較 -できるだけ多くの情報を比較する -小さな差分でも検出しやすいi.e. 興味のない差分まで検出しがち -動的比較* センシティブだと、テスト実行の時間やメンテコスト大 -同じ差分で何度もコケるはめに・・・ ロバストな比較 -必要最低限の情報に絞って比較する -余計な差分に惑わされずに済むi.e. 予想外の差分を見逃しがち -情報が少ないと、テストがコケた時の分析が大変・・・ 使い分け方の例 -回帰テストなど、安定を確かめるテストはセンシティブに。 -機能追加などでの詳細な確認では、狙った部分のみでロバストに。擬陽性擬陰性

34. Copyright2014 Kazuhiro SUZUKI 34/78 第4章自動比較 比較のタイミング: いつ比較するのか 動的比較 -テストケースを実行しながら比較する -途中段階にしか現れないものも比較できる -スクリプト中に比較処理が追加するので、複雑になることも 実行後比較 -テストケースを実行した後に比較する -テスト実行とは分けて処理することもできる -実装の候補として、シェルスクリプトなども考えられる ※その場合は、テスト実行自動化ツールとの連携が難しい STAでは、自動化ツールへの依存が小さい実行後比較の方が手厚い。

35. Copyright2014 Kazuhiro SUZUKI 35/78 第4章自動比較 単純な比較と複雑な比較:どう比較するのか 単純な比較 -ありのままの姿で比較する 複雑な比較 -本質的でない部分、比較する必要のない部分に対処する -grep、sed、awkを使った置換・比較のtips 「フィルタ」へ -比較に使う置換は「フィルタ」として再利用。ツール化も可能 -非プログラマから実装を隠蔽

37. Copyright2014 Kazuhiro SUZUKI 37/78 第4章自動比較 いろいろな種類の出力 テキスト万歳 データベースのレコード、バイナリデータ -ダンプしたり、テキスト変換したりできないか -なるべくツールに依存しないように！ CUI系の画面 -文字列が正しい、だけでいいのか？ -太字・イタリック・色といった属性が大事なことも GUI系の画面 -たとえばメッセージを考えてみても、メッセージの内容なのか、表示属性なのか、画面に適切に表示されているかなのか 画像、音声、動画、・・・

39. Copyright2014 Kazuhiro SUZUKI 39/78 第5章テストウェアアーキテクチャ テスト自動化によって増殖するファイルたち・・・ 「正しくドキュメントが編集されたことを確認」するには？ドキュメント（編集前）差分レポートログテスト仕様書共有スクリプトドキュメント（編集後）固有のスクリプト共有スクリプトドキュメント（比較用）比較ツールテストケースの数が増えるとn倍テストの回数が増えるとn倍

40. Copyright2014 Kazuhiro SUZUKI 40/78 第5章テストウェアアーキテクチャ 管理なしだと破綻は必定。 第5章は、使用・生成される作成物の論理的な関係と、維持するための物理的なアーキテクチャについて言及 -テストスクリプトの、プログラムとしてのアーキではない アーキテクチャは、自動化の初期から意識して適用する！ 自動か手動か、どのテストレベルか、によらないアーキテクチャ

41. Copyright2014 Kazuhiro SUZUKI 41/78 第5章テストウェアアーキテクチャ テストウェア テストに使用・生成されるすべての作成物（artifact） テストウェアの課題 とにかく種類と数が多くなる 共有スクリプトなど、効率的に再利用できないといけない -既存スクリプト探索時間は最大2分説 対象ソフトウェアに追随してテストウェアも変わる -どうやってバージョン管理する？ -旧バージョンのソフトウェアのためのテストウェアを取り出せるか？ 環境ごとにテストウェアも変わる -同じ機能を持った別のスクリプトをどう管理する？

42. Copyright2014 Kazuhiro SUZUKI 42/78 第5章テストウェアアーキテクチャ テストウェアの区別 テスト資料（Test materials） -テストが実行可能になる前に必要なテストウェア作成物 テスト結果（Test results） -テストの出力ドキュメント（編集前）差分レポートログテスト仕様書共有スクリプトドキュメント（編集後）固有のスクリプトドキュメント（比較用）比較ツールテスト資料テスト結果生成物 2次生成物

43. Copyright2014 Kazuhiro SUZUKI 43/78 テストケース第5章テストウェアアーキテクチャ さらに分類し、テストウェアライブラリで管理テストセットスクリプトセットデータセットユーティリティセットドキュメント（編集前）テスト仕様書共有スクリプト固有のスクリプトドキュメント（比較用）ツール類共有データ 1つ以上のテストケースの集まり テストレベル、目的などに応じて分割 テストセット内のテストウェアは、そのテストセットでのみ使用される 目的に応じて束ね、テストスイートに・・・ 複数のテストケースで使用するスクリプトと、そのドキュメントなど 2つ以上のテストセットから参照されデータ。たとえばデータベースの基本的なデータエントリ スタブ、コンバータ、比較ツール、・・・関連ドキュメント関連ドキュメント

46. Copyright2014 Kazuhiro SUZUKI 46/78 第6章前処理と後処理の自動化 テストケース実行前後の作業こそ退屈です。 大まかな分類してみると・・・ -ファイルの生成・削除・再配置 -テストケースの事前条件を満たしているかのチェック -入力や比較のための変換 まとまって現れるので、共通化しやすい 手動の特徴である想像力などもあまりいらない範囲 -本当かな？ 実行が手動であっても、前処理と後処理の自動化は有効

47. Copyright2014 Kazuhiro SUZUKI 47/78 第6章前処理と後処理の自動化 それでも細かい配慮事項は多い。 テストが異常終了した際に、データをどう保全するか テストケースごとに処理を行うか、テストセット単位で行うか -たとえばデータベースの生成とデータの復元 前後処理をどんなツールで実装するのか たとえばシェルスクリプトで実装した場合、テスト自動化ツールとどのように統合するのか長谷川さんのセッションでも言及あります！

51. Copyright2014 Kazuhiro SUZUKI 51/78 第7章保守性の高いテストを構築する 長いテストでコケると、その地点以降の欠陥は隠れたまま 長いとそれだけ、失敗の際の解析も大変 複雑になるほど、メンテナンスもつらくなる短いテストケースから始めよう。長いテストケースは、手動でやるのがいいのかも。機械がやるテストながら、長くて複雑なテストケースがイイ!!? 確かにややこしいテストは機械におまかせしたいが・・・

52. Copyright2014 Kazuhiro SUZUKI 52/78 第7章保守性の高いテストを構築する 特殊な形式では、直接の編集が難しい アプリケーション側で形式が変更になった場合、作ってしまったデータセットの作り直しで泣く ニュートラルな形式なら、変換プロセスのみの更新で済むできるだけテキスト形式で保持しよう。（ただし、わたしはExcelが大好きです）データセットは、アプリケーション固有の形式で持つのが一番!!? 確かにテストごとの変換の手間はないが・・・

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) ” 聞き飽きた引用ですね。

57. Copyright2014 Kazuhiro SUZUKI 57/78 DDP(Defect Detection Percentage) その工程までの発見された全欠陥のうち、その工程で発見された欠陥の割合 機能ごとの分類、深刻度による重み付け、・・・ DDPの低下= テストの欠陥検出能力の低下 DFP(Defect Fix Percentage) 既知の欠陥のうち、修正された欠陥の割合 徹底性 コードカバレッジとか、画面上の部品全部とか 自動的に計測できるものも多い ROI(ReturnOnInvestment） @ITの太田さんの記事に詳しい第8章メトリクステスト自動テスト

58. Copyright2014 Kazuhiro SUZUKI 58/78 保守性: ソフトウェアの更新に追随できるか？ 更新の発生頻度、更新にかかる時間、・・・ ユーザビリティ:フレームワークは使いやすい？ テストの追加の容易さ、トレーニングの時間、・・・ 堅牢性:テストを安定して進められる？ テストがつまづく頻度、原因調査の時間、・・・ 移植性:他のプラットフォームでも使える？ 効率性:テストの効率は上がっている？ テスティングのアクティビティに要する時間の比率 全体工数 テスト失敗時の分析に時間がかかり始める第8章メトリクステスト自動テスト

59. Copyright2014 Kazuhiro SUZUKI 59/78 信頼性:判定結果は信頼できる？ 擬陽性と擬陰性 いわゆるソフトウェアのreliabilityとちょっと違う 柔軟性: 素早くテストに着手できる？ サブセットを取り出すことの簡単さとか 過去のバージョンのとりだしやすさとか。 井芹さんの『テスト自動化の品質モデルの扱い』では、「テスト環境の品質」として整理自動テストの品質モデルとして、さらに、「テスタビリティの品質」と「テスト設計の品質モデル」を定義第8章メトリクステスト自動テスト

62. Copyright2014 Kazuhiro SUZUKI 62/78 まだまだ検討すべきことが！第9章その他の課題自動化の優先順位実行するテストの選択テストの実行順序の決定テストステータス、結果のレポート手動テストケース1 手動テストケース2 手動テストケース3 手動テストケース4 手動テストケース5 手動テストケース1 手動テストケース2 手動テストケース3 手動テストケース4 手動テストケース5 手動テストケース1 手動テストケース3 手動テストケース4 ❶ ❸ ❹ ❷ ❸ ❶ ❷

63. Copyright2014 Kazuhiro SUZUKI 63/78 第9章その他の課題 自動化の優先順位 すべてのテストケースを自動化しないといけないわけではない 優先順位づけする基準はいくつもある。 -手軽に自動化できるものから？ -重要な機能から？ -担当者のストレスになっている項目から？ 手っ取り早く成果が見えることも、組織としては大事 実行するテストの選択 目的に応じて、適切なテストセットを素早く選べなくては -たとえばテストタイプごと、前回実行時に「失敗」だったもののみ、・・・

64. Copyright2014 Kazuhiro SUZUKI 64/78 第9章その他の課題 テスト実行順序 テストケースをグルーピングし、論理的に階層化する -たとえば、スモークテスト的な上層と、機能を細かく検証する下層。上層でこけたら、下層のテストは実行しない -実行環境ごとにグルーピングすることも テストステータス 「成功」と「失敗」だけでは必ずしもうまくいかない 既知の未修正欠陥による「期待された失敗」 -複数の欠陥のうち、一部だけを修正して再テストを行う場合 -自動テストで忘れられがちな、「失敗」に対する調査時間 -最初からテスト対象にしない？逆にすべて「失敗」に倒す

65. Copyright2014 Kazuhiro SUZUKI 65/78 第9章その他の課題 進捗のモニタリング さまざまなメトリクスを盛り込んだレポート -テストケース数（指定、実行、成功、失敗、・・・） -エラーメッセージ、差分ファイル -テスト失敗の原因のサマリ -経過時間 SQiP2014でBest Report Future Awardを受賞された、楽天の荻野恒太郎さんの発表がすごく面白いです。このデータの取得も自動化しよう！

69. Copyright2014 Kazuhiro SUZUKI 69/78 そもそも、ツールで解決できる問題なのか？第10章テスト自動化ツールの選択購入プロセス要件の把握チーム作り制約の把握市場の調査デモ評価・決定 自動化しても、テスト自体がよくなるわけではない -リグレッションテストの時間がない？ -静的解析やインスペクションでは？ -解決策はツールじゃない、場合も 投資効果検討書 -テスティングに要する工数、欠陥の見逃しによるコスト、ツールのイニシャルコスト、ラニングコスト、・・・ -定量化できない要素もあり 制約を的確に把握 -ハードウェア、既存の開発ツール -コスト、社内政治、・・・

70. Copyright2014 Kazuhiro SUZUKI 70/78 ここでやっと、ツールの調査開始第10章テスト自動化ツールの選択購入プロセス要件の把握チーム作り制約の把握市場の調査デモ評価・決定 候補となるツールのリスト作成 -『テストツールまるわかりガイド』 -選定のための点数付け -絞り込み 自作か購入か -市場にいいものがなければ、自作 -自作は見た目がしょぼく、使いづらいかもしれないが、ニーズに対応しやすい ツール自体の情報の収集 -評価レポート -MLやユーザグループ

71. Copyright2014 Kazuhiro SUZUKI 71/78 ここでやっと、ツールの調査開始第10章テスト自動化ツールの選択購入プロセス要件の把握チーム作り制約の把握市場の調査デモ評価・決定ベンダーがいる前提だけど・・・ 自動化のデモのために -基本ルートのテストケースと、「悪夢」のようなケースを事前に -さらに、中間的なケースを当日に -対象となるアプリケーションでよく起こる種類の変更に基づくメンテナンス 定量評価 -テストケースの記録のための時間 -比較で検出できた差分の数、・・・ -購入までのプロセスを明確に、・・・

73. Copyright2014 Kazuhiro SUZUKI 73/78 購入よりも、実は導入こそがハードル第11章組織内へのツールの導入導入プロセスロールの割当変革の管理コミットメント確保パイロットプロジェクト段階的導入継続的改善 人は変革に対抗する・・・！ -今のままでいい、変えたくないという人の抵抗は大きい -ツールがもたらすメリットを地道に広めていく広報活動が重要 さまざまなロールが必要 -自動化のエヴァンジェリスト -文化を変革してく人 -ツールの責任者 -上層にいる支援者 上層部からのコミットメント -購入時点で途切れてはダメ -金・人といったリソースと、「変革を進めるんだ」という態度の両方

74. Copyright2014 Kazuhiro SUZUKI 74/78 一気に進めると危険第11章組織内へのツールの導入導入プロセスロールの割当変革の管理コミットメント確保パイロットプロジェクト段階的導入継続的改善 問題は小さいうちに摘む -「成功」の基準を決めたうえで試行。楽観的な基準を立て過ぎない -小さいパイロットだからこその失敗も 段階的に導入する -パイロットの欠陥を、ダメな面も含めて広める。生産性は、当初は下がる -教育やトレーニングの準備 -変化の公式f(a, b, c) > z a: 現状に対する不満 b: 共有された将来のビジョン c:aからbに至る工程に関する知識 z:変革に必要となる心理的なコスト ひたすら改善！

76. Copyright2014 Kazuhiro SUZUKI 76/78 テストがしょぼければ、自動化してもしょぼい 自動化で欠陥をたくさん見つけられるわけではない 問題がないと教えてくれるわけでもない 自動化では、メンテナンスコストこそ重い だからこそドキュメントの整備を忘れるな 標準と規律なしには長続きしない えらい人のサポートが継続的に重要 自動化で浮いた時間で、人間ならではのテストを！ STAで繰り返し強調されること

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

Kazuhiro Suzuki

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