AAA2015 関西風と欧米風　2つのTest Automation Patterns

1 2015/06/27 AAA ２つのTest Automation Patterns

みずのり（水野のりゆき）＠WARAI（関西SWテスト勉強会）

2015/6/27 AAA ２つのTAP

関西風と欧米風２つの

Test Automation Patterns


テスト自動化パターンの紹介

先ほど紹介された謎の内容は現「.reviewrc」が構築した「テスト自動化パターン」からの抜粋となります。※共に2013春辺りから構築？

ここで、世の中にある２つのテスト自動化パターンを紹介しておきます。

関西風

欧米風

http://testautomationpatterns.wikispaces.com/

http://kencolle.github.io/AutomationPatternLanguage/index.html


テスト自動化パターン（関西）の紹介

（関西風）テスト自動化パターンですが、以下のようにgithubで公開されております。

http://kencolle.github.io/AutomationPatternLanguage/index.html



「名前と（1行程度の）簡単な説明で共通理解が出来る」用語（言語）としてまとめていることが特徴っぽい。自動化の開始、構築中、定着の段階で発生する状況を判断できます。

自動化開始

自動化構築中

自動化定着 or 終焉



先ほどのパターンは、以下のように表現されております。使い方は…先ほどのストーリー参考。

パターン名文脈（Context）問題解決

3分

クッキング自動化は組織に初めての経験で、知見が蓄積されていない。

自動化ツールのハードルが高く、導入方法が分からない。

事前に自分の環境で、ある程度の構築をして、紹介すると同時に一気に運用までもっていく。

建増し

旅館

テスト自動化が職場に導入され、少しずつ適用範囲が増えていっている。

自動化システムが、場当たり的な改修によりメンテナンス性が損なわれていってしまう。

テスト自動化が複雑なシステムであることを理解し、実装を進める前に全体像を描くことを習慣づける。

験担ぎ

テスト自動化環境が構築され一度は効果が出たが、現在は効果のある運用がされていない。

明らかなエラーが検出されたとき以外は結果を誰も確認せず、形骸化・陳腐化している。

エラーが出ていることが、現場でもみ消せないようにする。

改善コストがあわないなら、そんな自動化やめちまえ。

アンチ

自動化

「自動化は面倒臭い」という誤解が根付く。

[験担ぎ]のテストが増加し、自動テストから便益を享受できていない

自動化に対する不信感。手動テストへの回帰を望む人が多くなっている。

自動化への誤解を一つ一つといていこう。自分たちなりの活用方法をアピールしよう。

動きの怪しい自動化システムに意味は無い、別ツールも試そう。



なんかダメパターン（アンチパターン）紹介ばかりでしたので、このようなパターンも存在しますので、紹介しておきます。

パターン名文脈（Context）問題解決

全体像を

描く

3分クッキングにより、自動化の導入は進み始めているが、まだまだ初期段階である。

自動化をまず導入しては見たものの、このまま全体に適用するのは難しいように思える。

システムの全体像を描き、その中に自動テストをどうすれば効果的に適用できるかを考える。効果的ならば設計にも手を入れることを考える。

ピンを

生やす

テスト自動化をしようと思っているが、テスト対象となるソフトウェアがテスト不可能な状況。

テスト対象のソフトウェアの構造的に一連のテストをまとめてしか出来ない。

組込みボードでデバッグピンを出すように、テスト可能なインタフェースが出来るようにピンを生やす。

テスト

仕分け

シナリオベースの自動化テストで、何をテストしたいのかわからないテストコードに埋め尽くされており、価値低下。

目的不明なテストをパスすることが足かせになり、プロダクトコードのメンテナンスが困難になっている。

テストの意図を調べ、確認できなかったテストコードを捨てる。重要なシナリオを抽出して、その価値を検証するテストケースを自動化する。

自動家を

作る

超人的な自動化構築者により開発環境に自動化が現場に展開されている。

超人的構築者がいなくなることで、運用が継続できなくなり、次第に廃れて[験担ぎ]に繋がってしまう。

次世代の自動家を育て、運用を継続するだけでなく、さらなる価値を生み出し改善が出来るようにする。


TAP（欧米）の紹介

本日紹介もあった「ギア本」の原著作者でもあるDorothy Graham氏、 Seretta Gamba氏らが作成した（欧米風）テスト自動化パターン

http://testautomationpatterns.wikispaces.com/

日本語訳してみました。 http://blog.amateur-factory.jp/?eid=1444184


TAP（欧米）の紹介：全体像

大きく、「Issues」と「Patterns」に分けております。 Issuesは“よくある問題点”、Patternsは“解決策”としてまとめられています。「Process」、「Management」、「Design」、「Execution」で分類。 10個の領域に分かれております。カッコの数字はパターンの数。

Process Management Design Execution

Issues Patterns （12）（21）

（14）（18）

（18）（29）

（7）（14）

Failure Patterns（4）

General Issues （7）

※例：NO PREVIOUS TEST AUTOMATION（テスト自動化やったことないねん）


パターン抜粋（Issues/Failure Patterns編）

パターン名概要

HIGH ROI EXPECTATIONS

行き過ぎたROIの期待

マネージメントとして最大のROIをテスト自動化に求めるが、

十分な投資の準備を行っていない。

NON-TECHNICAL-TESTERS

技術力のあるテスターが不在

ツールに熟練していないことが原因で、自動化されたテストケースを作成することが出来ない。

KNOW-HOW LEAKAGE

失われしノウハウ

テスト自動化のノウハウ（スクリプト作成やツールの使い方）が

既に組織から失われている

HARD-TO-AUTOMATE

テスト自動化が困難

神ExcelなどSUTがテスト自動化をほとんどサポートしていない、

もしくは全く自動化出来ない。

LONG SET-UP

セットアップ時間長ぇ

テストケース実行のための初期条件のセットアップの

手順が複雑で、時間が長くかかる。

‘MANUAL’ AUTOMATION

マニュアルな自動化テスト自動化の実行に多数のマニュアルな操作が必要な様子。

GOING FOR THE NUMBERS

もっと多くのテスト自動化だ！

（数に走る）

テスト自動化チームがテストを実施する目的を考えずに、

出来る限り多くのテストケース数を自動化しようとしてしまう。


パターン抜粋（Patterns編）


AUTOMATE WHAT'S NEEDED

必要なものを自動化せよ

開発者もしくはテストエンジニアが必要としているモノを自動化しましょう。たとえそれがテストでは無いものだとしても！

GOOD DEVELOPMENT

PROCESS

良い開発のプロセスを採用せよ

テストコードの作成にはプロダクトコード作成同様に、

良い開発プロセスを活用しましょう。

AUTOMATION ROLES

「自動化」という役割

テスト自動化チームは多数の異なるスキルと他とは異なる役割を必要とします。※なので、個別に役割を作ろう！という意味かと

SELL THE BENEFITS

利益を売りこむ意識を

マネージメント向けの情報として、

テスト自動化実施で獲得が予想される利益や、

獲得済の利益情報を提供しましょう。

TEST AUTOMATION OWNER

テスト自動化のオーナー

テスト自動化に尽力するオーナー（役割）を任命しよう。

※プロダクトオーナー相当と思われます。

KEYWORD-DRIVEN TESTING

キーワード駆動テスト

テストのふるまいを示すキーワードによってテストが駆動される。これらのキーワードには入力データと期待結果が含まれている。

VISUALIZE EXECUTION

実行状況を見える化せよ

テストを実行している際には、どのテストが現在実行しているか分かるようにしましょう。

PRIORITISE TESTS

テストの優先順位設定

簡単に実行すべきテストを選択できるようにするため、

それぞれのテストに優先順位を割り当てましょう。


TAPの紹介（使い方の一例）

最初に状況をGeneral IssuesやDiagnostic(診断)で明確にして、関連する詳細なIssuesを確認して、Patternsを適用する流れ。まあ、Dorothyさんらはコンサルの道具として使おうとしてるようです^^

General Issues

Diagnostic

Issue

Issue

Issue

Issue

Pattern

Pattern

Pattern

Pattern

診断特定対策


以下、Test Automation Patterns抜粋

ALLの項目を見たい場合はこちら

http://blog.amateur-factory.jp/?eid=1444184


参考：General Issues


EXPECTATIONS NOT MET

期待と違う！

テスト自動化がマネージャやテスト担当者、開発者の期待と違う結果となっている。

NO PREVIOUS TEST

AUTOMATION

テスト自動化やったことないねん

今まで自動化の環境が無い状況下で、テスト自動化を始めたばかりである。

NO DIRECTION

どっちに行くねん！テスト自動化に特定のゴールや戦略を持たずにつまずいてしまう。

MISSING RESOURCES

リソースの欠落

テストの自動化が、自動化担当者、テスト担当者、ルールやハードウェアの不足によって妨げられてしまう。

MISSING KNOWLEDGE

知識の欠落

自動化担当者やテスト担当者がどのように良い自動化を行うか、

ツールを活用するかを知らない。

また、SUT※1 についての限られた知見しかない場合や、新しいメンバーで生産的な状態に達するために時間がかかる状況。

MISSING SUPPORT

サポートの欠落

テスト自動化において、マネージャやテスト担当者、開発者のサポートがされない。

UNSATISFACTORY QUALITY

OF TEST AUTOMATION

不満足なテスト自動化の品質

テスト自動化が一部動作しているが、問題が多発して逆に苦しい状況に陥ってしまう。


参考：Process Issues（抜粋）


AUTOMATION DECAY

自動化の腐敗

テスト自動化が現在もしくはしばらくの間保守されておらず、

次第に腐敗して使われなくなる様子。

BUGGY SCRIPTS

バグだらけの

スクリプト

自動化のスクリプトが十分にテストされていないために問題が多数発生する。

LATE TEST CASE DESIGN

テスト設計が遅い

自動化のテストケースがSUTが実装された後で書かれてしまう。

※テストケースを作ることで、早い段階で不具合が発見できる効果を生かしていない、という意味に取ることも出来ます。

NON-TECHNICAL-

TESTERS

技術力のあるテスターが不在

ツールに熟練していないことが原因で、自動化されたテストケースを作成することが出来ない。

RANDOM AUTOMATION

（考えない）ランダムな自動化何を自動化するか？がアドホックに決められている状態。

STALLED AUTOMATION

自動化の失速

自動化が試されるが、決して地上を離れることが無い（上手く定着して効果が出ない）。


参考：Management Issues（抜粋）


HIGH ROI

EXPECTATIONS

行き過ぎた

ROIの期待

マネージメントとして最大のROIをテスト自動化に求めるが、

十分な投資の準備を行っていない。

ADEQUATE SUPPORT

不十分なサポート

テスト自動化チームがマネージャ層、テスト設計者、

他のスペシャリストから適切な支援を受けていない。

INADEQUATE TEAM

不十分なチーム

・自動テストチーム自体が無い、もしくはゼロから作られている

・自動化を実施している人が必要な役割を与えられていない

・テスト自動化チームの一部もしくは全メンバーが

テスト自動化を行う行為に向いていない

KNOW-HOW LEAKAGE

失われしノウハウ

テスト自動化のノウハウ（スクリプト作成やツールの使い方）が

既に組織から失われている

SUT REMAKE

プロダクトの作り直し

SUTに大量の変更が行われる。もしくはゼロからソースが

書き直される。

UNREALISTIC

EXPECTATIONS

非現実的な期待

管理層が非現実な期待をテスト自動化が出来ることに

期待してしまう。そしてその実現はできない。


参考：Design Issues（抜粋）


CAN'T FIND

WHAT I WANT

アレ、何処にあるんだっけ？

スクリプト、ファイル、データセットは存在しているが、何処にあるか思い出すことが出来ない。

HARD-TO-AUTOMATE

テスト自動化が困難

SUTがテスト自動化をほとんどサポートしていない、もしくは全く自動化出来ない。

LONG SET-UP

セットアップ時間長ぇ

テストケース実行のための初期条件のセットアップの手順が複雑で、時間が長くかかる。

REPETITIOUS TESTS

反復が多くくどいテスト

テストケースが同じ動作を異なるデータで繰り返す様子。

※同値分割の同一同値内でデータをまわすなど

REPETITIOUS TESTS

早すぎたんだ、

腐ってやがる…

テスト自動化の開始が未熟なアプリに対してあまりに早い構築を行ってしまう。もしくはアプリやプロダクトにノイズ的な報告をするだけの悪い側面を示してしまう。

UNAUTOMATABLE TEST

CASES

自動化出来ないテストケース

存在しているテストケースが自動化不可能。もしくは、不可能でないにしろ困難。


参考：Execution Issues（抜粋）


ERRATIC TEST

不規則なテスト自動化されたテストが成功したり失敗したりランダムに変わる。

FALSE FAIL

虚偽の失敗

テストがSUTの問題によるものでは無く、テスト自動化のテストウェア（ツール）もしくは環境によるものであること。

FALSE PASS

虚偽の成功たとえ実際にはエラーを含んでいたとしてもSUTが成功と示す様子。

INEFFICIENT

EXECUTION

非効率な実行

テスト自動化の実行がアドホックもしくは非常に融通が利かないものである。結果として、テストの一部を実行できることが出来ず「全部かゼロか」という状況となっている。

INEFFICIENT

FAILURE ANALYSIS

非効率な不具合解析

不具合の解析が困難で時間がかかる様子。

‘MANUAL’

AUTOMATION

マニュアルな自動化

テスト自動化の実行に多数のマニュアルな操作が必要な様子。


参考：Failure Patterns（抜粋）


FRAMEWORK

COMPETITION

フレームワーク競争

異なるチームが異なるフレームワークを構築し、統合・連携しようとしない。

GOING FOR THE

NUMBERS

もっと多くのテスト自動化だ！

（数に走る）

テスト自動化チームがテストの強固さを考えずに、出来る限り多くのテストケース数を自動化しようとしてしまう。

THE NIGHT TIME

FALLACY

夜間だけの設備

夜間の実行をターゲットとすることで、非効率的なテスト自動化に繋がってしまう。

TOOL MUSHROOMING

ツールの急増

内作で開発されたテストツールが、役に立つユーティリティだったものが巨大かつ広大なテスト自動化フレームワークに進化する様子。


参考：Process Patterns（抜粋）


ASK FOR HELP

助けを求めよ

何でもTry&Errorを自分でやるコトで時間を無駄にする代わりに、周りの人に助けを求めましょう。

AUTOMATE WHAT'S

NEEDED

必要なものを自動化せよ

開発者もしくはテストエンジニアが必要としているモノを自動化しましょう。たとえそれがテストでは無いものだとしても！

CHECK-TO-LEARN

学ぶためにテスト自動化

状況の確認をしよう

存在する自動化テストウェアの状況確認によって新しいメンバーの学びに繋げましょう。

GOOD DEVELOPMENT

PROCESS

良い開発のプロセスを採用せよ

テストコードの作成にはプロダクトコード作成同様に、良い開発プロセスを活用しましょう。

GOOD PROGRAMMING

PRACTICES

良いプログラミングプラクティスを採用せよ

ソフトウェア開発と同様に良いプログラミングプラクティスを活用しましょう。

TAKE SMALL STEPS

小さなステップで進めよう価値に繋がるような小さな仕事を見つけて積み重ねましょう。


参考：Management Patterns（抜粋）


DEDICATED RESOURCES

リソースを奉げよ

テスト自動化チームをフルタイム活動可能として、ツールや機器を必要に応じて用意出来るようにしましょう。

AUTOMATION ROLES

「自動化」という役割

テスト自動化チームは多数の異なるスキルと他とは異なる役割を必要とします。※なので、個別に役割を作ろう！という意味。

DO A PILOT

パイロットプロジェクトで調査せよ

パイロット（調査向け）プロジェクトを立ち上げ、アプリケーションに最も適したテスト自動化を探索しましょう。

PLAN SUPPORT

ACTIVITIES

計画は活動をサポートせよ

計画された時間とリソースはプロジェクトのゴールでは無く、活動をサポートするものである。

SELL THE BENEFITS

利益を売りこむ意識を

マネージメント向けの情報として、テスト自動化前、もしくはテスト自動化実施中における獲得可能もしくは獲得済利益の情報を提供しましょう。

SET CLEAR GOALS

明確なゴールの設定非常に早期の段階からプロジェクトの目的を定義しましょう。

TESTABLE SOFTWARE

テスト可能なソフトウェア

SUTにおける実装のどのような種類がテスト自動化を困難で不

可能にしているかを明らかにして、出来る限り早期から解決策を見つけましょう。


参考：Design Patterns（抜粋）


AUTOMATE GOOD

TESTS

良いテストを自動化せよ

良いテストのみを自動化することは、最大のROIをもたらします。

CAPTURE-REPLAY

キャプチャ＆リプレイ

マニュアルのテストを適切なツールを用いて自動化して、テストを再度実施するためにその手順を再生させましょう。

DATA-DRIVEN TESTING

データ駆動テスト

テストケースはスクリプトとして記述して、データのみ記述された他のファイルからデータを読み込ませましょう。

DOMAIN-DRIVEN

TESTING

ドメイン駆動テスト

テストケースを記述するテストエンジニア向けに

DSL（ドメイン特化言語）を構築しましょう。

KEYWORD-DRIVEN

TESTING

キーワード駆動テスト

テストのふるまいを示すキーワードによってテストが駆動される。これらのキーワードには入力データと期待結果が含まれている。

MODEL-BASED TESTING

モデルベーステスト

SUTのモデルからテストケースを作成する。典型的には、テストケース自動生成ツールを用いて行う


参考：Execution Patterns（抜粋）


BENCHMARK TEST

ベンチマークテスト

全種類のテストケースのパターン実行に向けた基準となるテストケースでベンチマークできるようにしましょう。

※多くのテストはあれど、「このグループのテストはこのテストケースをやればまず大丈夫！」という少数のテストケースを活用しようという意味かと

FAIL GRACEFULLY

美しく失敗せよ

テストの失敗時には、システム及び環境をリストアして、成功するテストに影響を及ぼさないようにしましょう。

PARALLELIZE TESTS

テストの並列化実行時間を短縮するために、テストは並列化して実施しましょう。

PRIORITISE TESTS

テストの優先順位設定

簡単に実行すべきテストを選択できるようにするため、それぞれのテストに優先順位を割り当てましょう。

VISUALIZE EXECUTION

実行状況を見える化せよ

テストを実行している際には、どのテストが現在実行しているか分かるようにしましょう。

UNATTENDED TEST

EXECUTION

介護のいらない

テスト自動実行

自動テストは自動的に始まって、

付き添いの人が不要な実行体系にしましょう。

Technology

AAA2015 関西風と欧米風 2つのTest Automation Patterns

AAA2015 関西風と欧米風　2つのTest Automation Patterns