『Experiences of Test Automation』 Chapter6. Project 1:Failure!, Project2:Success! を読んだ

お疲れさまです。@yoshikiitoです。

『Experiences of Test Automation』の各章を順不同で読んでるので、感想兼読書メモを残しておこうと思います。

Chapter6の概要

Ane Clausenが経験した2つのプロジェクト(失敗例と成功例)を通して、テスト自動化を成功させるためには何が必要なのかが書いてあります。

ツールとしてQCとUFTを使ったと書いてあるのですが、そこまでツールに依存した話は出てきません。QC上の各要素の構成をこうしたらうまくいった、的な話は出てきますが、他のツールでも応用が効きそうです。

テスト自動化を成功させるコツ

導入部分には

Many useful lessons are described in this chapter, such as good communication (including using the walls), limited scope of the early automation efforts, good use of standards in the automation, a good structure (looking for common elements), and keeping things simple.

と書かれています。つまり

  • 良好なコミュニケーション
  • 限られたスコープで早期に結果を得る
  • 自動化のスタンダードを踏襲する
  • 構成をうまく作る(共通部分を探す)
  • シンプルに保つ

です。
初見だとgood communicationのカッコのincluding using the wallsが「壁を使うこと」?と思いますが、失敗プロジェクトのほうを読んだらわかりました。
各プロジェクトに散らばった自動化を導入する役割の人が自動化に専念できず、あちこちから割り込みが入ってしまって(本の中では”peace and quiet”な時間がとれなかった、とあります)、それが失敗の一つの要因になった、ということでした。
つまりコミュニケーションは大事だけれども、適切に壁を設けて、自動化に集中できる環境をつくることが大事!ということですね。

ここは大筋納得できるものの、例えば開発者と話をしながらテスト対象の作りについて話をしたり(要素が一意に特定出来ないなんて有り得ないよ、とか)、手動でテストしてる人が「この辺のテストめんどくさくてつらい」という愚痴を聞いたり、そういう時間も必要といえば必要ですよね。
こういった時間の使い方は舵取りが難しそうなものの、おそらく「舵を取れる状態にある」というのが大事で、他人が自動化担当の時間の使い方を握ってる状態だとダメ、ということですね。

この辺を踏まえた上で、特にプロジェクト成功に寄与したのはパイロットプロジェクトを行ったことです。

3ヶ月のパイロットプロジェクトを実施

パイロットプロジェクト=トライアル、くらいで理解しました。

ここでは3ヶ月のパイロットプロジェクトを行って、

  • 最初の1ヶ月
    • タスクの理解
    • ツールの理解
    • 自動化エンジニア同士のノウハウ共有
    • パイロットプロジェクトにおけるスコープの整理
  • 後の2ヶ月
    • 実際のテストを自動化

という分け方で行ったそうです。
最初の1ヶ月で自動化を進める準備を整えて、マネージャ層の理解やサポートも得た上で計画を作成。
次の2ヶ月で実際に自動化。

自動化エンジニアの立場からすると「このくらい準備いるよね!」と思う気持ちもありつつ、実際の業務でこれだけ準備して自動化できるパターンもそうそう多くはなさそうだな、と思って読んでました。
特にテストの自動化に着手する動機として

  • 時間がない
  • 人手が足りない
  • お金がない

あたりが挙がることが多いので、そんな状況で3ヶ月間かけて準備します、は辛いよね・・・というのもわかります。

そこらへんの、テスト自動化の準備期間を短くする工夫みたいなのも(個人レベルではなく)考えないといけないですね。

この最初の1ヶ月の準備ののち、2ヶ月間実際のテストを自動化してみて、この章の著者のAneさんたちの会社では「Go!」が出たそうです。

再度、テスト自動化を成功させるための5つのコツ

  • Tasks and responsibilities must be agreed on and known in the organization.
  • Make a pilot project and define clear goals.
  • Ensure common understanding and knowledge; document best practice and standards.
  • Understand the whole business application to ensure the right structure and size of test cases.
  • “Keep it simple.”

言ってること自体は導入部分と同じなので、主張で実例をサンドイッチした構成の章、ということですね。
ただ実例を読んだ後で出されると、やっぱり「そうだよね、大事だよね」と思えます。

周りの理解をなんとか得つつ、テスト自動化の準備は念入りに行う。準備というのは、ゴールを明確にしてパイロットプロジェクトを行うことだったり、ツールの知識・ツールに依存しない自動化のノウハウなどを自動化エンジニア間で共有したり、ビジネス面をきちんと理解することだったり、です。

テスト自動化をやったころある(かつそれなりにつらい思いもしたことある)身としてはとても納得のいく章でした。

ABOUTこの記事をかいた人

都内でテストエンジニア&ブロガーをやっている@yoshikiitoです。 ソフトウェアエンジニアの学習方法や成長するための考え方、会社に依存せず自分の力で生きていけるエンジニアになる方法などについて興味があります。 こういった方法や考え方、自分が試したことなどをブログを通じて発信します。 仕事は主にソフトウェアテストやテスト自動化。 趣味は浦和レッズと読書と技術書を買って積むこと。 技術評論社から本を出すのが夢