レポート

自動化はキャズムを超えたか?!「システムテスト自動化カンファレンス2014」参加レポート

この記事を読むのに必要な時間:およそ 5 分

師走も半ばの2014年12月14日,東京赤坂のヤフー株式会社の会議室をお借りして,昨年に続き2回目となる「システムテスト自動化カンファレンス2014(STAC2014)」が開催されました。今年のテーマは「広く普及しキャズムを超えてきたシステムテスト自動化について,そのアーキテクチャやパターンについても考えていこう」というものです。なんとイベントの受付開始から24時間を待たずに191名の定員が埋まり,最終的には200名近いキャンセル待ちが出るという超人気イベントとなりました。今回はイベントの内容と共に現場の熱気もお伝えしたいと思います。

STAC2014はテスト自動化研究会(STAR)によって運営されています。STARは「テスト自動化技術における高度なスキルを検討・定義し,それを広く世に広く啓蒙する」ことを目的として2012年に発足し,本カンファレンスを主催しているコミュニティでもあります。「テスト自動化エンジニア/Test Autometor」という職業を作っていきたいという熱い思いには個人的にも強く共感しています。

また今回のイベントに合わせるように,STARメンバーが中心となって翻訳した『システムテスト自動化標準ガイド』という書籍が発売されました。この本は以下のような2部構成になっています。

  • 第1部:原著である『Software Test Automation』の第1部の翻訳
  • 第2部:日本のエンジニアによる書き下ろしのケーススタディ※1

本カンファレンスはこの書籍とリンクするような形で進められましたので,各セッションをより深く理解するためには『システムテスト自動化標準ガイド』のご一読をお勧めします。

※1)
原著の第2部は内容が少し古いため,翻訳対象外としたとのこと。

開会の挨拶:松木 晋祐

STARのメンバーである松木さんから開会の挨拶です。はじめにSTARの趣旨,スコープ,これまでの実績などが紹介されました。続いて,今回の参加者の業務分野や自動化経験などのアンケート結果が紹介されました。

松木氏による開会挨拶

松木氏による開会挨拶

今回のテーマの前提として「キャズムを超えた」と言っていましたが,参加者を見ると経験が無い方が約半数とキャズムを超えてない可能性があるので,本日皆さんとキャズムを超えたいと思います!と冗談混じりに言っていました。しかし,逆に考えると経験の無い多くの方がこのようなイベントに参加すること自体が,システムテスト自動化への関心の高まりを示していると考えてよいと思います。

1時間でわかるSTA:鈴木 一裕

『システムテスト自動化標準ガイド』3章の翻訳と監修を行った鈴木さんが1時間でわか(った気になれ)るSTAというテーマで発表しました。STAとはシステムテスト自動化標準ガイドの原著であるSoftware Test Automationの略語になります。

鈴木 一裕氏

鈴木 一裕氏

大きなカンファレンスなどでの発表は初めてという鈴木さんでしたが,緊張も見せずに「タイトルは1時間でわかるとなっていますが,1時間でわかることはないので本を買ってください!」といきなり言い放ちました。会場からは笑いがこぼれ,少し固かった雰囲気がほんわかと和みました。

鈴木さんは翻訳したSTA第1部の11章すべてを紹介してくれましたが,今回は印象に残ったところをピックアップしてお伝えします。また各章と自動化の対応づけを以下の図を使って説明していました。一口に自動化といっても人によって定義は様々であるため,このようなマップは講演者と参加者の話のコンテキストを合わせる上でとても有用だと感じています。

全体図

全体図

第1章

この本では「自動化する以前にテストはまともですか?」ということが一貫して言われています。個人的な経験からも,自動化が難しいと言っている人の中には,元々のテストの方に問題がある人がそこそこの割合で存在しているようです。

さらに自動化の長所や留意点などを伝えてくれましたので,ここでも一部紹介したいと思います。個人的に気になったところは組織の非現実的な期待を抱きがちというところです。どうしてもマネージャー層や経営層は自動化に過度な期待をしまいますので,自動化でできること/できないこと,投資や得られるリターン,メンテナンスコストなどもはっきりさせておくことが重要だと感じました。

長所
  • 量の面/テストケース追加コストが安いので多数のテストケースを実行できる
  • 量の面/リグレッションテストを気軽に実行できる
  • 質の面/テストの実行手順の再現性が高い
留意点
  • 技術面/手動のテストよりも技術力が必要
  • 技術面/テストでバグ0=品質OKではない
  • 組織面/非現実的な期待を抱きがち

第3章

テスト自動化知識体系(TABOK)によると,テストスクリプトは以下の3レベルに分けられています。

Level1: リニアスクリプト,構造化スクリプト
Level2: 共有スクリプト,データ駆動スクリプト
Level3: 構造化スクリプト,キーワード駆動スクリプト

より良いテスト自動化のためにはキャプチャ時に記述されたリニアスクリプトをそのまま使うのではなく,構造を変えることでスクリプティングのレベルを上げていく必要があるとのことです。

リニアスクリプト+分岐+反復+呼び出し
→ 構造化スクリプト
構造化スクリプト+機能分割
→ 共有スクリプト
構造化スクリプト+データの切り離し
→ データ駆動スクリプト
構造化スクリプト+機能分割+データの切り離し+機能の抽象化(キーワード化)
→ キーワード駆動スクリプト

ただし全てレベルが高ければよいというわけではなく,プロジェクト規模や期間に応じた選択,さらに高レベルのアプローチでは規律の徹底が必要ということでした。

第6章

テストの前処理・後処理は複雑で退屈な作業です。一方同じような処理を実施していることが多いため切り出しやすく自動化しやすいという特徴があります。仮にテストの実行が手動でも,前処理・後処理を自動化するだけでも意味があるとのことです。

著者プロフィール

nemorine(ねもりん)

JaSST東北実行委員長/仙台ソフトウェアテスト勉強会運営/JaSST北海道実行委員/TEF道 にぎやかし担当/AgileJapan仙台サテライト実行委員。仙台の某半導体メーカに勤める開発エンジニア。北海道と仙台をこよなく愛す。開発も大好きだが,いいものを作るためには品質も大事だと気付き,ソフトウェアテストのイベントに参加するようになる。2012年から仙台ソフトウェアテスト勉強会を企画運営し,2013年5月に東北初となるJaSST東北を立ち上げた。

Twitter:@nemorine

バックナンバー

2014年

バックナンバー一覧

コメント

コメントの記入