Transcript

• 1. + システムテスト自動化のア ンチパターン デブサミ2015 2015/02/19 太田健一郎 テスト自動化研究会 株式会社SHIFT
• 2. + アジェンダ  Test Automation Patterns  システムテスト自動化標準ガイド  アンチパターンとIssues  Process Issues  Execution Issues  Design Issues  Management Issues
• 3. + Test Automation Patterns  http://testautomationpatterns.wikispaces.com/  Seretta Gamba, Dorothy Graham, Mark Fewsterの3人が中心に なってまとめているテスト自動化のパターンです  パターンを適用すべき問題が発生しているIssuesとPatternsから 構成されています  ユニットテストのパターンはxUnit Test Patternsに譲り、インテグ レーション以降、主にシステムテスト自動化のパターンにフォー カスしています  元々、パターン・ランゲージのようなパターン間の関係について の記述は弱かったのですが、現在はソフトウェア・パターン関係 のメンバーも参画し、単なるパターン・カタログからパターン・ ランゲージに進化し始めています
• 4. + システムテスト自動化 標準化ガイド  前述のDorothy GrahamとMark Fewsterが執筆した名著 "Software Test Automation"をテ スト自動化研究会(STAR)の有 志が翻訳しました  システムテスト自動化のアーキ テクチャとプロセスを解説して います
• 5. + アンチパターンとIssues  Test Automation Patternsでは実はアンチパターンそのものは 扱っていません  Failure Patternsという明らかに失敗のパターンは4つ解説して います  何らかのアンチパターンもしくは無策の状態でテスト自動化に 取り組んで、問題が出ている状態をIssuesとして解説していま す
• 6. + Issueのフォーマット  Issue name  Issueを端的に表す名前を書 きます  Issue Summary  Issueの概要を記述します  Category  Issueがどのカテゴリに属す るかを記述します  Process/Management/Design /Execution  Examples  Issueの実例をいくつか記述し ます  Questions  Issueを解決するパターンに至 るための質問を列挙します  Resolving Patterns  Most recommended:  Issueを解決する最適なパ ターンを解説と共に列挙し ます  Other useful patterns:  Issueの解決をサポートする 他のパターンを列挙します
• 7. + Patternのフォーマット  Pattern name  パターンを端的に表す名前を 書きます  Pattern Summary  パターンの概要を記述します  Category  パターンがどのカテゴリに属 するかを記述します  Process/Management/Design/ Execution  Context  このパターンが有用もしくは 有用でないコンテキストを説 明します  Description  パターンが果たす役割を詳細に説明 します  Implementation  パターンをどのように実践するかを コンテキスト毎に説明します  Potential problems  このパターンを適用した場合には考 慮すべき問題について列挙します  Issues addressed by this pattern  このパターンによって解決される Issueを列挙します  Experiences  このパターンを適用した経験を解説 者の名前と共に解説します
• 8. + 5つのIssue  General Issues  最終的に個々のIssueに分解される一般的なIssueで階層化されています (次ページのMind Map)  自分たちの組織内で挙がってくるIssueが漠然としているときにブレー クダウンして個々のIssueにたどり着くために有用です  Specific Issues  Process Issues  テスト自動化プロセス自体が原因で発生するIssuesです  Management Issues  プロジェクトマネジメント上で発生するIssuesです  Design Issues  保守性を含めたテスト自動化アーキテクチャ上で発生するIssuesです  Execution Issues  自動テストを実行する時に発生するIssuesです
• 9. + General IssuesのMind Map
• 10. + Specific IssuesのMind Map
• 11. + Test Automation PatternsのMind Map
• 12. + Process Issues  INADEQUATE COMMUNICATION  SHARE INFORMATION  WHOLE TEAM APPROACH  NO INFO ON CHANGES
• 13. + INADEQUATE COMMUNICATION  Issue Summary  手動のテスターは自動テストが何をしているか知らず、逆にテスト自動化チームは手 動のテストチームが何を必要としているか知りません  開発者は開発側の変更がテスト自動化にどのような影響を与えるかを理解していなし、 知らないし、気にかけていません  Category  Process  Examples  テストケースがテスト自動化エンジニアが理解できるように書かれていません  テスト自動化エンジニアは他のテスターや専門家のサポートを必要としていますが、 彼らにその時間はありません  テスト自動化エンジニアが知っていれば簡単に自動化出来るようなことを手動のテス ターがしています  テスターと開発者が物理的に離れて仕事をしています  開発者が自動テストを壊したり中断することを気にかけないでSUTを修正しています
• 14. + INADEQUATE COMMUNICATION  Questions  テスターとテスト自動化エンジニアは同じチームですか？そうでない場合なぜです か？  開発者は新しいコンポーネントを使用するときにテスト自動化エンジニアに通知して いますか？  チームメンバーが個人的に会う頻度はどれくらいですか？テレコンや生のミーティン グはどれくらいですか？  チームメンバーは互いのことを知っていますか？時差や言語の差はありますか？  同じ役割のチームメンバーは同じくらいの経験やノウハウがありますか？同じ"言語"を 話しますか？  Resolving Patterns  Most recommended :  SHARE INFORMATION : このパターンはどの規模の自動化にも有用です  WHOLE TEAM APPROACH : 開発チームがアジャイルプロセスを使用して本パター ンを適用しているなら、このIssueは発生しません  Other useful :  GET ON THE CLOUD : 分散チームで働いている場合、本パターンが有用です
• 15. + SHARE INFORMATION  Pattern summary  マネージャや、開発者、他のテスターやお客様に情報を求めると同時に提供しま しょう  Category  Process  Context  このパターンは新しいメンバーがチームに参画した時にマネジメントやテスター、 開発者とコミュニケーションを取る必要があるときに有用です  逆に既に知識が充分にある状態で単独で仕事を進める場合には向いていません  Description  テスト自動化には多くの人が関わりますが、必要とする情報は人によって異なり ます。しかし、多くは明示的に教えてもらわなければ、分かりません。そのため、 必要なときに適切な情報を共有する必要があります
• 16. + SHARE INFORMATION  Implementation  マネジメントにテスト自動化プロジェクトの進捗を知らせるようにしましょう。どのようなメトリックスを彼らが必要と しているかを聞き、どれが容易に取得でき、できないかを説明しましょう。また、定期的に最も適切なフォーマットで概 要を報告しましょう  マネジメントがテスト自動化に期待していることを言ってもらいましょう。このようにすれば、彼らが"UNREALISTIC EXPECTATIONS"を頂いているかをすぐに知ることができ、また伝えることもできます  何をやっているのかを他の人達と共有しましょう。何かを説明すると新しいアイディアが浮かぶこともありますし、話し 合いが始まることもあります  問題や質問があるときは"ASK FOR HELP"パターンを適用しましょう。自分が悩んでいる問題は、実は他の人が既に解決 していたりします  テスターや開発者の話を聞きましょう。なぜそれをやっているのか、なぜそのようにやっているのか尋ねましょう。必要 なことがわかれば、元々自分たちで考えていたより、よいサポートを得られるでしょう  開発者にSUTがテスト自動化に影響を与える場合には常に連絡を貰えるようにお願いしましょう  などなど、コミュニケーションは口頭以外にもレポートや文書、Wiki、黒板など様々なものがあります。組織で最適なも のを使用しましょう  Potential problems  コミュニケーション、特にEmailでのコミュニケーションは誤解が生じやすいです  コミュニケーションは適切なレベルと受取手を定義する必要があります。そうでないとむしろ無視されたり、悪化したり します  Issues addressed by this pattern  INADEQUATE COMMUNICATION ほか多数のIssues
• 17. + WHOLE TEAM APPROACH  Pattern summary  テスターやプログラマなどを始めとするロールがワンチームで対象の製品コード ともにテスト自動化を推進していきます  Category  Process  Context  このパターンはアジャイル開発で最も有用ですが、他のコンテキストでも役に立 ちます。このパターンはチームが一人の場合には有効ではありません  Description  開発チームの全員が協力して製品コードの開発と共にテスト自動化を進めていき ます。テスターは何をテストすべきかを理解しており、プログラマは保守性の高 い自動テストを書くのを助けます。DBAやシステム管理者など別のロールも同様 にテスト自動化へ貢献します
• 18. + WHOLE TEAM APPROACH  Implementation  アジャイル開発をしているなら、すでにソフトウェア開発だけでなく、 テストでも、テスト自動化でもwhole-teamアプローチを実践している はずです  アジャイル開発をしていない場合でもチームが一緒にテスト自動化をす る一連の原則は役立ちます。共有する知識は広くなり"SHARE INFORMATION"、自動化が容易になります。また、自動化を理解して いる組織の異なる領域のメンバーの協力も得られます  Potential problems  "FULL TIME JOB"として自動化を担当していない場合、優先度の高い他 のタスクによって、自動化への時間を割けない場合があります  Issues addressed by this pattern  INADEQUATE COMMUNICATION 他多数のIssues
• 19. + NO INFO ON CHANGES  Issues summary  開発側の変更がテスト自動化エンジニアに共有されません、もしくは適切なタイミングで共有されません  Category  Process  Examples  テスト対象のシステムの以下の変更がコミュニケーションが適切にされていないと自動化に悪影響を与えます  新しい開発環境  新しいプログラミング言語  新しいOS  新しいGUIコンポーネント  画面遷移の順序  データベースの構造  データベースのトリガー  Questions  変更の担当はだれですか？  誰が通知すべきですか？開発者は知っていますか？
• 20. + NO INFO ON CHANGES  Resolving Patterns  SHARE INFORMATION : 本パターンを適用するとこのIssueを一度 に取り除くことができます  SHORT ITERATION : フィードバック・サイクルを短くすれば、問 題はより早く効率的に見つかります  WHOLE TEAM APPROACH : アジャイル開発を採用している場合、 本パターンを適用しましょう。アジャイル開発をしていない場合で も、開発やテスト自動化を本パターンで改善できるか確認してみま しょう
• 21. + Management Issues  HIGH ROI EXPECTATIONS  DO A PILOT  SET CLEAR GOALS  UNREALISTIC EXPECTATIONS
• 22. + HIGH ROI EXPECTATIONS  Issue Summary  マネジメントはテスト自動化のROIを最大化させることを望んでいますが、十分な投資ができ ていません  Category  Management  Examples  マネジメントは高価なテストツールを買えば、テスト自動化には十分だと考えています  マネジメントはテスト自動化をすればたくさんのバグを見つけてくれるものだと期待してい ます  マネジメントはテスト自動化をすればテスターが少なくできると考えています  マネジメントはツールを変更する必要が無いと考えており、なぜテストウェアのアーキテク チャに労力を割く必要があるのか疑問に思っています  Questions  マネジメントはテスト自動化に何を期待していますか？テスターは何を期待していますか？  ビジネスプランは練られていますか？
• 23. + HIGH ROI EXPECTATIONS  Resolving Patterns  More recommended :  AUTOMATE GOOD TESTS : 本パターンを適用すれば、高いROIをよ り早くもたらすテストケースを自動化の対象にできます  DO A PILOT : テスト自動化がどれだけコストがかかり、何をもたら すかを判断するために本パターンを適用してテスト自動化を開始し ます  MAINTAINABLE TESTWARE : 長期的なROIのためには本パターンを 適用します。短期的には必ずしも必要ありません  SHARE INFORMATION : 現実的な自動化を達成し、マネジャーの期 待を現実的なものにするためにはコミュニケーションが必要です  Other useful patterns :  SET CLEAR GOALS : 利害関係者全員を同じ船に乗せるために本パ ターンを適用します  他多数のパターン
• 24. + DO A PILOT  Pattern summary  最適な自動テストの方法を明らかにするためにパイロット・プロジェクトから始めます  Category  Management  Context  このパターンはゼロから自動化プロジェクトを始めるときに役立ちますが、自動化が期待通 りの結果を出していない場合の理由を探る場合にも有用です  このパターンは1度切りや使い捨てのスクリプトの場合には不要です  Description  対象のアプリケーションに最適な自動テストの方法を探るためにパイロット・プロジェクト から始めます  このようなパイロットの利点は時間とスコープを区切って実施するため、問題と解決策を見 つけることに専念しやすいことです  パイロット・プロジェクトでは大量のテストを自動化することを期待する人はいませんが、 どのツールが適切か、適切な設計は何かなどを発見できます
• 25. + DO A PILOT  Implementation  始めにパイロット・プロジェクトで下記のような目的を達成する"SET CLEAR GOALS"パターンを適用します  対象アプリケーションでテスト自動化が成功すること示します  テスト自動化アーキテクチャを決定します  テスト自動化が望むROIを実現することを示します  アプリケーションとツールの経験値を上げます  SUTに最適な"RIGHT TOOLS"を選択するために複数のツールを試します。しかし、可能なら"PREFER FAMILIAR SOLUTIONS" (慣れたソリューションを選択し)、最初からノウハウが利用できる状態にします  "MIX APPROACHES"を恐れないようにします  最初に必要なスキルを持つメンバーを集められるかを判断します ("AUTOMATION ROLES")  例えば、"STEEL THREAD"を自動化し、”TAKE SMALL STEPS"パターンを適用します。こうするとどのよう な問題に直面するか分かるようになります。例えば、"TESTABLE SOFTWARE"になっているかなどです  Potential Problem  欲張らないようにします。ゴールを設定しすぎると、それを達成するのに多くの問題が発生します  Issues address by this pattern  HIGH ROI EXPECTATION 他複数のIssues
• 26. + SET CLEAR GOALS  Pattern summary  初期に明確で全員に理解できる自動化の目的を定義します  Category  Management  Context  このパターンはゴールが異なっている場合でも常に適用出来ます。最初にテスト 自動化を考えるときを始め、自動化を開始したとき、自動化がうまくいったとき、 自動化を再開したときなど常に目的とゴールを理解している必要があります  Description  自動化の目的を最初に明確に定義していれば、後で期待と違った結果が出たとし ても、落胆することはなくなるでしょう  マネジャーに何がうまくいくのか行かないのかを伝えましょう  ゴールは達成できたかできなかったかを説明できるように測定可能である必要が あります
• 27. + SET CLEAR GOALS  Implementation  ゴールはコンテキストやタイミングによって異なりますが、下記のような例があります  選択したリグレッションテストは手動テストよりx倍速く、y回実施する必要があります  手動で実行するのが難しすぎるテストを自動化の対象にします。どれかを明確にします  手動テストを補助するタスクを自動化対象とします  自動リグレッションテストが繰り返し実行できることを保証します  繰り返しの退屈なテストからテスターを解放し、探索的テスト時間を使えるようにします  Not good goals  良くありがちな誤りはテストのゴールと自動化のゴールを混同してしまうことです。この場合、ゴールが「自 動テストは多くのバグを見つけるべきである」のようになります  Potential problems  すべてのテストケースを自動化するのは不可能もしくは適切でないかもしれないというのをマネジメントに念 を押すのを忘れないようにしましょう  Issues addressed by this pattern  HIGH ROI EXPECTATIONS  UNREALISTIC EXPECTATIONS 他複数のIssues
• 28. + UNREALISTIC EXPECTATIONS  Issue summary  テスト自動化ができるとできないことにかかわらず、非現実な期待は存在します  通常自動化に非現実な期待をしているのはマネジャーです。「銀の弾丸」を期待 していることもあります  他にも非現実な期待をしている人がいる可能性もあります。例えば、テスターは 自動テストが人間と同じような障害検知能力を持っていると思っているかもしれ ませんし、開発者はテストを自動化すれば、テスターはもはや不要と考えている かもしれません  Category  Management  Examples of unrealistic expectations  すべての手動テストが自動化されるべきである  自動テストが通過したら、もはやソフトウェアには欠陥はない  どんな手動テスターでもこのテストツールを使えば自動テストが書ける  自動テストにメンテナンスは不要もしくは非常に小さなコストである
• 29. + UNREALISTIC EXPECTATIONS  Questions  マネジャーは自動化が会社に何をしてくれると期待していますか？  マネジャーが自動化について理解した元ネタはなんですか？  マネジャーは自動化の限界を知っていますか？  マネジャーは自動化に更に投資が必要だと考えていますか？  マネジャーは自動化の利益をどう測定していますか？  Resolving Patterns  Most recommended :  DO A PILOT : まだ自動化を開始していないなら、本パターンを適用 してできることとできないこと、必要なリソースなどを明らかにし ましょう  SHARE INFORMATION : 既に自動化を始めているのなら本パターン が有用です。上記で挙げたような非現実な期待をしている人がいた ら、なぜ現実的でないのかを説明する必要があります
• 30. + Design Issues  DATE DEPENDENCY  DATE INDEPENDENCE  INTERDEPENDENT TEST CASES  INDEPENDENT TEST CASES  SORCERER'S APPRENTICE SYNDROME  ONE CLEAR PURPOSE
• 31. + DATE DEPENDENCY  Issue Summary  テストが特定の日付に依存しています  Category  Design  Examples  テストケースは何かが起こった時間もしくは経過を検証しています  期待結果は作成日時の出力を含んでいます  Questions  テストケースは日付の問題を回避するように修正できますか？  期待値は他の方法でチェックできますか？  Resolving Patterns  Most recommended :  DATE INDEPENDENCE : 本パターンを提供すればこのissueのいくつかを解決出来ます
• 32. + DATE INDEPENDENCE  Pattern summary  日付に依存せずテストケースを書くようにします  Category  Design  Context  テストケースや期待結果に日付への依存がある場合にこのパターン を適用します  Description  可能なら"DATE DEPENDENCY"を避けるようにテストケースと期 待結果を再設計します。それができないなら、適切な初期条件を設 定します
• 33. + DATE INDEPENDENCE  Implementation  現在日付を日付フィールドのデフォルトとして使用できるか開発者に聞いてみま す。できなければ、スクリプト内で現在日付を設定します  現在日付からの差を求め日付として設定します  (現在日付を保存した後)事前処理で、システム日付を自分の期待する日付に設定 します。テストが終わった後現在日付に戻します  期待値に実際の日付ではなく、日時の差分を使います  開発者に日付の表示をブロックするようなスイッチを作ってくれるようにお願い します  日付の表示部分を無視するような比較ツールを使います  Potential problems  システム日付を変更した後、テストが失敗したら、すぐに気づかない場合誤った 日付のままシステムが動作する可能性があります  Issues addressed by this pattern  DATE DEPENDENCY
• 34. + INTERDEPENDENT TEST CASES  Issue Summary  テストケースが互いに依存しており、特定の順番でしか実行できません  Category  Design  Examples  前のテストケースの結果が次のテストケースの初期状態となっているため、特定の順番でし かテストケースを実行できません  Questions  誰がテストケースを設定しましたか？  手動テストをそのまま自動化しましたか？  Resolving Patterns  Most recommended :  FRESH SETUP  INDEPENDENT TEST CASES
• 35. + INDEPENDENT TEST CASES  Pattern summary  各自動テストケースは自己完結するようにします  Category  Design  Context  継続的でかつ効果的なテスト自動化をしたときに本パターンは必須 です  Description  自動テストケースは互いに独立して実行できるようにしておくべき です。そうすれば、個別に実行できて、前のテストの失敗が後続の テストに影響を与えることはなくなります
• 36. + INDEPENDENT TEST CASES  Implementation  各テストは実行前に"FRESH SETUP"を実行します。各テストはリソースへ独占 的にアクセスします  テストが中断した場合、後続のテストが正常に動作するようにSUTやツールをリ セットする必要があります  自己完結したテストとは一つのテストケースが全アプリケーションをテストする というものではありません。逆に各テストはビジネスルールに基づいた1つの明 確な目標を持つべきです  Possible problems  手動テストはセットアップの時間を削減するために連続して実行されることがあ ります。自動化が効率的になるようにテストケースを再設計する必要があります  初期化が非常に複雑で時間がかかる場合、本パターンではなく、"CHAINED TESTS"パターンを適用すべきです  Issues addressed by this pattern  ERRATIC TEST 他複数のIssues
• 37. + SORCERER'S APPRENTICE SYNDROME  Issue Summary  より効率的な解決策を探さずに手動テストをそのまま自動化しようとします  Category  Design  Examples  手動テストのステップをそのまま自動テストに変換しようとします  この方法によって非効率でかつ複雑かつもろいテスト自動化システムができます  Questions  誰がテストケースを自動化設計をしますか？自動テストは単なる手動テストのコ ピーですか？  Resolving Patterns  Most recommended :  ONE CLEAR PURPOSE 他複数のパターン
• 38. + ONE CLEAR PURPOSE  Pattern summary  各テストは1つの明確な目的だけを持つようにします  Category  Design  Context  効率的で分化された保守性の高いテストウェアを開発するにはこのパターンを適用します  使い捨てのスクリプトには必要ありません  Description  テスト結果は単一のビジネスルールに基づいた1つの明確な目的だけを持つべきです  Implementation  http://hillside.net/europlop/europlop2011/submission/shepherd.cgi?token=8319165de3b08999af1a3d180bc366 025678684d&action=download&label=1309193739_6  Issues addressed by this pattern  SORCERER'S APPRENTICE SYNDROME 他複数のIssues
• 39. + Execution Issues  ERRATIC TEST  FAIL GRACEFULLY  RIGHT INTERACTION LEVEL  FALSE FAIL  FALSE PASS  INEFFICIENT EXECUTION  TEST SELECTOR  ‘MANUAL’ AUTOMATION  UNATTENDED TEST EXECUTION  ONE-CLICK RETEST
• 40. + ERRATIC TEST  Issue summary  自動テストが成功したり失敗したりします  Category  Execution  Examples  多くのテストは成功しますが時折失敗するものがあります。再実行する と成功します  同一のデータベースに対して自動テストを並行実行してデータが混在し てテストが失敗します  あるテストが失敗してシステムを不正な状態にして、後続のテストがす べて失敗します  自動テストはテスト環境の特定のデータが不変だと仮定しています。例 えば、テスターの管理の下初期データが投入されることを前提にしてい ます
• 41. + ERRATIC TEST  Questions  そのテストは先行するテストが実行されると常に失敗しますか？そ れとも先行するテストが失敗すると失敗しますか？  同時に実行しているテストはありますか？  自動テスト自体が充分にテストされてしますか？  テスト環境の変更の影響は受けますか？不変な何かを仮定していま すか？テスト環境の変更を監視していますか？  Resolving Patterns  FAIL GRACEFULLY : テストの失敗が不正な状態を作り出している 可能性がある場合本パターンを適用します  RIGHT INTERACTION LEVEL : 最も効果の高いレベルでSUTをテ ストするためには本パターンを適用します
• 42. + FAIL GRACEFULLY  Pattern summary  テストが失敗した場合、システムと環境を回復し、後続のテストに影響を与えないようにします  Category  Execution  Context  本パターンは自動テストをまとめて失敗させたくないときに有用です  各テストの失敗を分析する必要があるときには本パターンは向いていません  Description  例外をキャッチし、システムと環境をリセットしてからテストを終了するように実装します  Potential problems  本パターンは"FRESH SETUP"とは真逆のアプローチで、こちらはテストは復帰処理を実装しません  Issues addressed by this pattern  ERRATIC TEST
• 43. + RIGHT INTERACTION LEVEL  Pattern summary  SUTとテストが相互作用するレベルとリスクに気を付けます  Category  Design  Context  本パターンはテスト自動化を開始もしくはSUTとの相互作用を変更した ときに有用です  Description  SUTとテストが相互作用する方法やレベルには複数あることを理解する のが重要です  レベルことに別の実装が必要になりますが、同時に偽陽性と偽陰性のリ スクがあります  SUTへの侵入レベルが高くなるとテスト失敗のリスクが高まります
• 44. + RIGHT INTERACTION LEVEL  Implementation  テストを自動化する場合、SUTとどのような方法で相互作用するか決める必要があります  エンド・ユーザーが使うのと同じ方法(同じインタフェースで)自動テストも実装します。 特に組み込みシステムでハードウェアを使ったテストでこのアプローチがよく取られます。 ソフトウェアのみのアプリケーションではあまり使われることはありません  UI自動化 : GUI経由で自動テストを実行するとSUTの環境も変更されます。SUTの侵入レ ベルは高くなりますが、偽陽性および偽陰性のリスクは高まります  テスト自動化はAPI上で行われることもあります。この方法は自動テストを実装しやすい です。このテストは非常に強力で効率的ですが、SUTへの侵入レベルは最も高くなります  Potential Problems  相互作用のレベルが異なると侵入度合いも異なります  Issues addressed by this pattern  ERRATIC TEST  FALSE FAIL  FALSE PASS
• 45. + FALSE FAIL  Issue summary  SUTのエラーではなく、テスト自動化テストウェアやテスト自動化環境 が原因でテストが失敗します  Category  Execution  Examples  自動テスト開発中には考慮していなかったウィンドウのポップアップで テストが失敗します  初期状態が他のテストによって破壊されてテストが失敗します  テスト単独で実行すると成功しますが、テストスィートとして実行する と必ず失敗します  テスト実行のマシンで別の何かが動いていてテストが失敗します  別のアプリケーションにデータベースが破壊されたり、変更されたりし てテストが失敗します
• 46. + FALSE FAIL  Questions  初期条件は正しく設定されていますか？  テストケース間に依存関係はありますか？  テスト自体を充分にテストしましたか？  Resolving Patterns  Most recommended :  INDEPENDENT TEST CASES : テストスィートとして実行したときにテスト が失敗する場合本パターンを適用します  RIGHT INTERACTION LEVEL : SUTとは最も効果的なレベルで相互作用する ようにします  他複数のパターン  Other useful patterns :  SHARE INFORMATION : 本パターンは開発者が自動化に影響を与える変更を 学ぶのに役立ちます  他複数のパターン
• 47. + FALSE PASS  Issue summary  SUTがエラー状態なのにテストが成功してしまいます  Category  Execution  Examples  自動テストはSUTに対して実行していますが、期待結果の比較をしていないので常に成功してしまいます  エラーの結果が期待値で書き換えられてしまって、比較が常に成功しています  エラーのあるSUT環境で自動テストが開発されて、検証されることなくエラー値が期待結果になってしまって います  Questions  期待結果は正しく取得されていますか？  テスト自体を充分にテストしましたか？  Resolving Patterns  Most recommended :  RIGHT INTERACTION LEVEL : SUTとは最も効果的なレベルで相互作用するようにします
• 48. + INEFFICIENT EXECUTION  Issue summary  自動テストの実行が非常に遅いです  Category  Execution  Examples  UIの同期のために自動テストが非常に遅いです  個別の機能をテストするためにサブセットを選んだり、異なるリグレッ ションテストを選んだりするのが困難です  自動テストの実行に非常に時間がかかるので最後のリリース前にしか使 えず、デイリービルドに使えません  テストの準備と後始末が自動化されていないため、手動での介在が必要 です
• 49. + INEFFICIENT EXECUTION  Questions  テストの実行にどれくらいかかりますか？問題はなんですか？  どのアクティビティにどれだけ時間がかかっていますか？時間がか かっているのは、セットアップですか？クリーンアップですか？  テストは並列実行できますか？  GUIではなくAPI経由でテストを実行できますか？  Resolving Patterns  Most recommended :  INDEPENDENT TEST CASES : 本パターンはテストを分割して 異なったマシンで並列実行させる場合に有用です  TEST SELECTOR : テストの実行に含めるかを選択できる複数の 選択基準をテストケースに割り当てることができます
• 50. + TEST SELECTOR  Pattern summary  テスト実行に含めるかを選択できる複数の選択基準をテストケースに割 り当てます  Category  Design  Context  本パターンは自動テストが沢山あり、全実行が時間的に難しくなってい る場合に必要になります  Description  本パターンの必要性は自動化を始めたタイミングでは明確ではありませ んが、大規模な自動化をしたくなった場合に考慮する必要があることが 分かってきます
• 51. + TEST SELECTOR  Implementation  テストの記述やテストドキュメントの一部として、特定のテストを 識別するタグをつけることができます。例えば、スモークテストや、 特定機能のリグレッションテスト、最後に見つかったバグテスト、 テストの作成者などです。タグを指定して実行することにより上記 のサブセットが実行できます  Potential problems  自動化の最初に本パターンを考慮しておかないと、後で実装するに は困難になります  Test Selectorの標準は明確に定義しておく必要があります  Issues addressed by this pattern  INEFFICIENT EXECUTION
• 52. + ‘MANUAL’ AUTOMATION  Issue summary  自動テストを動かすのにたくさんの手作業が必要です  Category  Execution  Examples  テストスィートの初期状態は手動で設定する必要があります  テストによってはウィンドウやコンポーネントが自動でハンドリングできず、手 動で実行する必要があります  あるテストを再実行するのに他のテストを手動で無効にする必要があります  自動テストの開始が手動です  自動検証は単純なものしかなく、テストが成功しているか失敗しているかを判断 するには目視が必要です  テスト結果をレポートするのに手作業が必要です  ツールを統合するのに手作業が必要でかつ時間とコストがかかり間違えやすいで す
• 53. + ‘MANUAL’ AUTOMATION  Questions  現在の自動テストはSUTを信頼できるレベルで実行していますか？  初期状態は自動的に設定されますか？できていないとしたらなぜで すか？  Resolving Patterns  Most recommended :  UNATTENDED TEST EXECUTION : 本パターンを使えば、 Examplesの1つ目と4つ目を解消できます  ONE-CLICK RETEST : 本パターンはExamplesの3つ目を解決す るのに役立ちます
• 54. + UNATTENDED TEST EXECUTION  Pattern summary  自動テストは自動的に開始し、単独で実行できるようにすべきです  Category  Execution  Context  本パターンは自動テストを長期にわたって続けていく場合に有効で す  Description  自動テストは自動的に開始、単独で実行できるように設定されてい る場合最も高いROIが得られます。結果はテスターがテストの失敗 を確認できるように設定すべきです
• 55. + UNATTENDED TEST EXECUTION  Implementation  テストを単独で実行するためには、それをサポートするインフラが必要になります  DEDICATED RESOURCES : 他のユーザーによる破壊を避けるために専用のマシン 上でテストをします  テストケースが互いに影響を及ぼさないように"INDEPENDENT TEST CASES"を設 計します  失敗したテストによってテストスィート全体が失敗しないように"FAIL GRACEFULLY"します  Potential problems  色弱の人には色ではテストの成功失敗が分からないかもしれません  テストは致命的な障害から回復する必要があるかもしれませんが、ビルトインではそ の機能はないかもしれません  Issues addressed by this pattern  INEFFICIENT EXECUTION  'MANUAL' AUTOMATION  NO PREVIOUS TEST AUTOMATION
• 56. + ONE-CLICK RETEST  Pattern summary  特定のテストを再実行するにはクリック1発のように容易であるべきです  Category  Execution  Context  本パターンは失敗したテストを再実行したい場合に役立ちます  Description  特定のテストを再実行するのをできるだけ容易にしましょう  "TEST AUTOMATION FRAMEWORK"にサポートがあるなら、テストケースを選択し、1クリックで実行できるはずです  Implementation  "PRIORITISE TESTS"ができるなら、必要なテストを選択して、優先順位付けを変更するのは比較的容易なはずです  Issues addressed by this pattern  INEFFICIENT FAILURE ANALYSIS  'MANUAL' AUTOMATION
• 57. + Another Design Patterns Selenium Design Patterns and Best Practices  Seleniumを使ったGUIテストのデザイ ンパターンとベストプラクティスを解 説した書籍です  残念なテストコードから始めて各種の デザインパターンとベストプラクティ スを適用しながら品質の高いテスト コードへと変えていく手法が見事です  書籍のコードはRubyですが、Web上 にJavaリソースもあります  本セッションはそのJavaソースを 使って最初のいくつかのデザインパ ターンを解説します  Kindleなら¥1,424 !!  2015/08に太田&玉川監訳でオライ リーさんから翻訳書が出版 !!