2013年12月1日、オラクル青山センターでシステムテスト自動化カンファレンス（STAC）が開催されました。私自身はテスト自動化研究会（STAR） のコミッターですが、今回縁あってカンファレンスのレポート役をさせていただくことになりました。
それではさっそく報告に入りましょう。
よりよいテスト自動化のためにちょっと考えてみませんか？―スコープ、ROI、プロセスを中心に―（STAR）
今回のカンファレンスの位置づけと全体の方向づけを行うものです。このカンファレンスで扱われるテストは「ソフトウェアのユーザに価値がある単位で行われるテスト」 、一般的にはシステムテスト、受け入れテストと呼ばれるテストレベルになります。
次にテスト自動化の目的を考えましょう。代表的なものとしては効率化したい、手動ではできないテストをしたい、などが挙げられますが、大事なことはただ自動化してもよい自動化にはならないということです。
近江さんはここで、良い自動化のポイントとして3つ挙げました。
スコープ
ROI（Return On Investment）
プロセス
自動化には手間も時間もかかるので、自動化しておいしいところを絞る必要があります。スコープとは具体的にはテストレベル、テストタイプ、テストプロセスが挙げられます。
ROIに関しては時間による変化を考えることが重要です。ツール、テストプロセス、人、プロダクトに対して導入前と導入後の保守フェーズでかかる費用に違いが生まれます。
プロセスに関してはテスト対象を自動化しやすい形に変更するなど、開発側と協働で進める必要がでてくるかもしれません。ただし実行とレポーティングは工数が減るので、これらとのトレードオフになります。
最後に全体のまとめとして、テストは自動化により柔軟になり、幅が広がる。テスト自動化を通じて、よりよいテスト、よりよいプロジェクト、よりよいプロダクトを目指してくださいとのことでした。
事例から見るテスト自動化のポイント森田誠、川口慎一郎（TABOK関西）
「現代に舞い降りた漆黒のJenkins使い」前川さん、「 ガイアがオレにささやくメガネ男子」森田さん、「 オレのコードで踊り狂えテスト自動化マニア」川口さんの発表です。
左から、前川さん、川口さん、森田さん
TABOKとはTest Automation Body Of Knowledgeの略で、米国ATI（Automated Testing Institute）が出している自動化に関する知識体系です。本講演はSTARとほぼ同時期にTABOKの勉強を始められたTABOK関西からの発表になります。
TABOK関西ではテスト自動化のアンチパターンを集めてみました。
「3分クッキング」
→事前に自前で自動化環境を用意し、紹介すると同時に一気に運用へ
「自動化ハイ」「建て増し旅館」
→自動化しすぎて、管理コストが増大してくる
「原住民蜂起」
→メンテできなくなったテストのおかげで手動に戻る
「インディージョーンズ」
→自動化しようと成果物をあさると、昔誰かが試みたテストが出てくる
→たいてい失敗プロジェクトの名残で呪われている
続いて川口さんから「ファクトリーオートメーションにおけるシステムテスト自動化」と題して、より具体的な事例の紹介です。
ファクトリーオートメーション（FA）の世界は超ミッションクリティカルです。そんな中であらゆる環境の変化に対応した巨大自動化システムを構築したのですが、動かすためにかかる労力が半端なく結局お蔵入りとなってしまいました。そこでそもそも何のために自動化しているのか、という原点に立ち返って考えてみたところ、表面上見えていた行為と、人がやっていた仕事の差が見えてきたそうです。
自動化の難しさは、決して人間が頭を使ってやってきた仕事は置き換えられません。自動化で成功するには、獲得した技術を適用するときに、プロセスの流れが最適になるように技術をはめていくこと、そして効果の計測と改善を繰り返すことです。
最後に出てきた立石一真（オムロン創業者）の「機械にできることは機械に任せ、人はより活動てきな分野で活動を楽しむべき」という言葉が印象に残りました。
発表資料
スマートフォンアプリのテスト自動化をはじめよう（STAR）
午後の部は主にSTARコミッターからの事例報告やデモがメインになります。
長谷川さんは現役のスマートフォンアプリ開発者です。そのため、あくまで開発者の立場から現在のスマートフォンアプリの自動テスト環境について発表を行いました。
まず現状として、スマートフォンの世界では、ユニットテストはiOS/Androidともに充実していて普及率も十分ですが、システムテストはUIの頻繁な変更などがあるため自動化しにくい状況にあります。
そこで長谷川さんは
という軸で説明を行いました。
欲張らないROIとしては、自動化の目的を「テスト実行時間の短縮」「 複数のOSバージョン・機種で実行できる」に絞り込むのがいいようです。
がんばらないテストスクリプトとしては、日時など変動する値を無理に比較しない、機種依存の問題は内容次第で目視確認するなど、自動化する範囲を限定すべきということでした。ただしすべての画面は網羅しつつ、テストケースの絞り込みを行い現実的な実行時間に納めることが重要ととのことです。
デモではGenymotionエミュレータに対して、MonkeyTalkを使ってサンプルAndroidアプリの操作をキャッチ＆リプレイしていました。Selenium IDEでのWebブラウザ操作とほとんど変わらない印象を持ちました。
自動化フレームワークの詳細については資料のスライドをご覧ください。
発表資料
ATDD実践入門（STAR）
きょんさんは名古屋でテストアーキテクトをされています。元々テスト嫌いで、嫌いなものをなくすためにテストを勉強しているとのことです。今回はTDDからATDDに発展した流れについての発表です。
TDDは主にSmalltalk界隈で行われていたプラクティスをKent Beckが形式知したものだそうです。
レッド：動作しないテストを書く
グリーン：テストを動作させるように本体コードを書く
リファクタリング：重複を取り除く
という流れで進めていきます。
ATDDはXPそのものではありませんが、ユーザのための受け入れテストのTDDとして
仕様を顧客と話し合う
仕様について顧客と一緒に付随する条件を表で書く
受け入れテストを実装
プロダクトの実装
受け入れテストの成功と十分な実装を確認して完了する
という流れで実行されます。
最後にまとめとして、ATDDはプラクティスとして非常にまともだが、コンテキストに合わせて取り入れることが必要ということでした。
ATDD, BDDなどで使われるツール群の詳細、参考書籍については資料をご覧ください。
発表資料
http://kyon-mm.bitbucket.org/blog/html/_static/slides/stac2013/atdd.html
モデルベースドテスト入門―テスト詳細設計を自動化しよう―（STAR）
テストの自動化というと通常はテスト実行、結果のレポートあたりを思い浮かべますが、実はテスト設計においてにおいても自動化は可能、というお話です。
モデルとは、システムの振る舞いや性質を特定の観点で抽象化したものです。モデルにはいろいろ種類がありますが、ここでは
を扱います。
モデルベースドテストとは、モデルを活用してテスト成果物を生成する技術のことです。モデルを生成の対象とするため、ブラックボックステストに分類されます。
それでは上記3モデルを使ったモデルベースドテストについて説明します。
状態遷移モデル
UMLでいう状態遷移図を状態遷移表に変換します。例えば2つの状態間の遷移だけ網羅すればいい場合には0スイッチカバレッジを100％にする、という言い方をします。これはモデルが巨大になってくると人が生成するのは難しくなってきますが、朱峰さんはUMLモデリングツールastah*のプラグインを利用したデモを行いました。
論理モデル
システムの構成要素間の論理関係に着目するモデルです。ここでは原因結果グラフ（CEG）を例として挙げていました。CEGはAND, OR, NOTなどの論理構造から論理的にあり得ない組みあわせテストを間引く技術です。デモではCEGTestと呼ばれるフリーのツールでCEGからディシジョンテーブルを自動生成する例を紹介していました。
組みあわせモデル
システムの構成要素間の組みあわせをモデリングしたものです。ここでは組みあわせテスト技法の代表であるオールペア法の例としてPICT、そのフロントエンドとしてのPICTMasterの紹介がありました。
モデリングは設計にも重要なスキルですが、テスト、特に自動化テストにおいても重要な技術であると締めくくられました。
発表資料
ライトニング自動化テストデモ
以降のデモは15分間のライトニング形式による事例紹介です。
手動テストからの移行大作戦（STAR）
「刺身にタンポポ」とはネットスラングで、刺身に食用菊を載せるような単調な作業のことです。ここでは刺身タンポポなテストこそ自動化の対象と位置づけます。
例題として、とある「ホテルの予約システム」に対する自動化テストを考えます。
入力値があいまい
入力値が細かいところまで書かれていないテストケースの場合、デフォルト値を入れるデータシートを作成し、何も指定されていない場合はデフォルト値が適用されるようにします。
操作内容があいまい
これに対しては1通りの操作をトレースし、入力値、操作をデータテーブルから読み込んで補完できるように中抜きします。
判定方法があいまい
どんなときにどうなるかをはっきりさせます。
できあがったテスト自動化システムはテストケース、データシート、ログが別になったもので、それぞれライフサイクルが異なるようにできます。
最後にテストの自動化の前に、必要なテストかどうか確かめましょうということでした。
発表資料
激しいUI変更との戦い（STAR）
玉川さんは第三者検証会社で自動テストツールの導入支援などをされています。今回の発表はSeleniumの自動テストをベースに、いかに仕様変更を耐え抜くかという話です。
度重なる仕様変更は、プロジェクトが佳境のときは仕方がない面もあります。しかしテストスクリプトの可読性が低いと、エラー時の対応が取りにくいなど、メンテがされなくなる弊害があります。
そこで玉川さんは2つの作戦を考えました。
作戦1：テストしづらい製品コードはあえて指摘する
作戦2：テストケースの「素」をメンテする
作戦1に関して、開発側にテストのために変更を要求するのは、そもそもコミュニケーションがうまくいっていないと難しいところです。
作戦2では、3つのステップで詳細化していきました。
テスト対象と会話するための基本動作を定義
基本動作と対象を組み合わせて操作用言語（DSL）を作る
個別のテストシナリオを作る
基本的な考え方はキーワード駆動テストと呼ばれる、テストスクリプトの抽象化技法です。抽象度を上げることでテストの再利用性を高めたり、テストシナリオが書きやすくなったりします。
発表資料
テスト自動化の事例紹介による有償ツールの選択ポイント（STAR）
藤井さんは日本HPでテストツールのデリバリやコンサルタントをされています。今回は有償ツールの効果的な使い方についての事例紹介とデモです。
事例では、Webリッチクライアントで構築された基幹システムで、変更が多発し毎日リリース、毎日不具合という状態が続いていました。藤井さんは変更対応とリリース判断可能な改善策を依頼されました。
そこでHPの製品QTP（QuickTest Professional）とALM（Application Lifecycle Management）の登場です。QTPはキャッチ＆リプレイツールとして会場のアンケートでもかなり知名度が高かったのですが、今回はテスト管理ツールALMとの連携のお話です。
ALMを使ってQTPスクリプトをバージョン管理し、テストの進捗状況のレポーティング、実行フローのまとめなどを行った結果、テストカバレッジと品質が向上し、変更に強い体制が構築できたそうです。
惜しむらくは15分では短く、デモの時間が十分とれなかったことです。もう少し見たかったです。
組み込み開発での実機テストの自動化の一つの考え方（STAR）
井芹さんは組み込み開発のテストコンサルで、現在は車載システムのテスト支援に従事されています。
組み込み開発ではタイミング依存のバグや実行環境の変更の激しさなどから、テストの自動化は重要な意味を持っています。自動化によってテスト条件のスケーラビリティが向上したり、回帰テストが効率化したり、制御や観測の選択肢が増えるそうです。ただ自動化には組み込み固有の事情が発生します。全体的な傾向として環境構築が難しいということです。
次にテストの責務・負荷を分散しましょうというお話です。
責務の分散とは、システムテストに閉じないで本来の品質やテストの目的に立ち返って、組み込み固有の制約に対応するということです。
また、負荷分散ですが、構築が難しい組み込みのビルド環境やテスト環境は、開発の段階から徐々に育てていき、多方面で活用することでリスク分散ができるというお話でした。
組み込み系に閉じず、自動化が難しいエンプラ系の案件にも通じる話だと思いました。
発表資料
テスト自動化のこれまでとこれから（STARアドバイザ）
辰巳さんはSTAR発足のきっかけを作って作ってくださった方です。主に富士通のメインフレームOSの開発・品質保証から、テスト・品質に関わる活動に移行され、著作多数。日本におけるテストの生き字引といっても過言ではないでしょう。
最初の自動化に関する論文は1962年の“ Automatic Program Testing” だそうです。今から50年前ということなります。テストという作業が始まってすぐテスト自動化への取り組みも始まったようです。ただ、その内容はテスト手順の標準化や計算時間の節約の話だったようです。
70年代から自動化の取り組みが始まり、主に内製のツール類が充実してきました。
80年代からUNIXオープン化の流れが始まり、1985年にPCの最初の商用テストツールを開発したAutoTester社が設立されています。テストツールベンダとして有名なMercury社が設立されたのも1989年です（2006年にHPが買収） 。
90年代に移り、商用ツールがかなり充実してきて、テスト自動化の技術の体系化も進み始めました。1995年にはテスト自動化の最初の書籍と言われている『Automated Testing Handbook』が出版されています。
さて、現在の状況ですが、90年代終わりから2000年の初めにかけてオープンソースのテストツールが出てきました。
その中で最も有名なSeleniumですが、名前の由来をご存知でしょうか？ Seleniumは非金属元素のセレンで、水銀の毒性を軽減する効果があります。Seleniumの作者Jason Huggins氏（近々来日されます）はMercury社の製品QTPの代替ソフトを考えていた時に、セレンが水銀中毒（Mercury Poisoning）の治療に使われることからこの名前を思いついたそうです。
最後はテスト自動化のこれからについてです。海外の学会でもさまざまな技術トピックがありますが、その中でもキーワードとして上がって来たのがTesting as a Service（TaaS）です。TaaSはクラウドにおけるテストと同時にクラウドを使ったテストを意味します。すでに提供会社がいくつか存在するようです。
結びにテスト自動化エンジニア（Test Automator）への期待を述べました。AutomatorはISTQB（テストの国際資格）でもExpertと称される非常に高度な技術の必要な職業であり、テスト全体の実行計画や管理などから自動化の範囲を定めていくような技能が求められます。今なら世界の先駆者になれるそうです。
これまでの歴史を振り返りながら、まだまだ自動化にはやり残したことがある。未来につながる重要な仕事であることを実感させられた講演でした。
発表資料
まとめ
本カンファレンスは日本で最初のテスト自動化に特化したカンファレンスとして重要な意味を持つと思います。どちらかというと自動化についてあまり関心のない現場が多い中で、特に立石一真氏（オムロン創業者）の「自動化は人間が創造的な仕事をするためにある」という言葉が印象に残りました。テスト自動化の意味を今一度考える機会になればいいなとスタッフの一員として思いました。
それと会場の暖かい雰囲気（熱気？）もよかったと思います。特定のベンダに特化しないコミュニティ主導の、そしてスタッフみなさんの暖かい「お・も・て・な・し」があったこそ、この暖かい雰囲気が生まれたのだと思いました。懇親会のライトニングトークも盛り上がりました。
最後に私が本会議場に貼り付いていたために受講できなかったチュートリアルの資料を紹介して、このまとめを終わりたいと思います。
チュートリアルを担当された伊藤さん
実践で学ぶ、効率的な自動テストスクリプトのメンテナンス
