背景・効果

過去、ベリサーブではさまざまなお客様の元でテスト自動化支援を行ってきました。自動化を支援し始めた頃、当社の支援内容の質が常駐するエンジニア個人のスキルに依存していることがありました。この時に問題となっていたのは、

という点です。
結果として、手戻りが大きくなるといったことが発生していました。
あるお客様ではうまくいき、別のお客様ではうまくいかないといったことをなくすため、テスト自動化の標準プロセスを定義することにしました。標準プロセスは、テスト全体で、今、何を検討すべき工程かを把握し、テスト自動化で、誰が・いつ・何をすべきかを明確にします。

標準プロセスを定義するまでの過程

標準プロセスを定義する以前から、社内には「テスト自動化エンジニアのロールおよびスキル定義」が存在しました（表１）。

しかし、これだけでは実際のプロジェクトを進める上で役割の違いがわかりづらいという声があり、テスト自動化に必要な作業の検討には不十分でした。そこで各ロールと結びつく形でテスト自動化のプロセスを定義し、どのプロセスをどのロールが担当するのかを明確にすることで、これらの問題が解消できるだろうと考えました。まずはベリサーブ社内でテスト自動化の技術推進活動をしている有志の一人がプロセスのたたき台を作成しました（図１）。
このたたき台に対し、他の技術推進活動のメンバーからフィードバックを受け、それらを反映させる形で進めていきました。
例えば、このたたき台では、以下のようなフィードバックがありました。

「自動テストスクリプトの話、自動テストシステムの話、自動テスト全体の話が混在している」
「自動テストのコーディングは、実際には設計と実装を含んでいるはず」

さらに、テスト自動化のプロセスはそれ単体で存在するわけではなく、テスト全体のプロセスと対応付けが必要だと考えたため、手動を含むテスト全体のプロセスを含めることにしました。プロセスの大枠を作成し、さらに言葉の定義や意味合いを社内外の定義と整合性がとれるようにするなどの調整を行った結果、定義したテスト自動化のプロセスが図２です。

テスト自動化のプロセス定義

ここからは、実際に定義したテスト自動化のプロセスについて具体的に説明します。
現在ではさらに詳細化および一部変更を予定していますが、大まかなプロセスの骨組み自体は前述の図の通りです。

１．全体像

テスト自動化はそれ自体を独立して考えるものではなく、サービスやプロダクトのテスト全体の中で考えるものです。そのため、手動テストのプロセスと対応付けてテスト自動化のプロセスを定義しました。
大きなプロセスとして以下の3つを設定しています。

自動テストの実装·運用に関するプロセス ③～⑥（図中：自動テストプロセス）では、自動テストツールやライブラリを使って自動テストを作り、運用する流れを定義しています。
自動テストシステムの構築・運用に関するプロセス ⑦～⑩（図中：自動テストシステムプロセス）では、実装した自動テストを実行して結果を確認するCI（Continuous Integration：継続的インテグレーション※１）などの仕組みを構築して運用する流れを定義しています。
マネジメントプロセス ⑪（図中：マネジメントプロセス）は1本の流れになっていますが、テスト自動化を含んだプロジェクト全体のマネジメント・コントロールを行います。本質的にはシステム開発のプロジェクトの連営と同じですが、作業工数の見積や考えられるリスクの洗い出しなどに関しては、テスト自動化に関する知見が必要になります。

※１　ソフトウェア開発において、ビルドやテストを頻繁に繰り返し行うことにより問題を早期に発見し、開発の効率化や品質の改善、納期の短縮を図る手法。

２．全体要求分析とPoC ①②

テスト自動化プロジェクトの最初の工程では、プロジェクト全体の要求分析とPoC（Proof of Concept: 概念実証）を行います。
要求分析 ① は、主に【テスト自動化プランナー】が担います。本工程では以下のような点についてヒアリングや検討を行い、全体の計画を立てます。

要求分析の内容を基に、テスト自動化に使用するツールの候補選定も行います。
PoCは【テスト自動化プランナー】と【自動テストシステムアーキテクト】が担当します。本工程では、要求分析で検討した全体の進め方や選定しだツールで小規模なトライアルを行い、テスト自動化の導入可否の調査と、テスト自動化の費用対効果の検討を行います。

３．自動テスト実装 ③～⑥

PoCの後、自動テストの実装～運用のプロセスが続きます。
テストの自動化を行う流れは、システム開発によく似ています。自動テストが満たすべき要件をまとめ、設計を行い、その後実装を行います。
最初の自動テストスクリプト要求分析 ③ は、【テスト自動化プランナー】が担当します。本工程では以下のような点について調査・検討を行います。

事前に行った全体要求分析 ① と重複する部分も出てきますが、PoC ② を行ったことによって方針が変わった点や、新たな課題が必ず出てきます。PoCの結果を踏まえた上での自動テストスクリプト要求分析 ③ を行います。
次の自動テストスクリプト実装 ④ は、主に【テスト自動化エンジニア】が担います。本工程では、テスト自動化ツールまたは何らかのプログラミング言語とライブラリなどを使用して、自動テストスクリプトを書いていきます。「テスト自動化作業」と言うと、この段階をイメージしがちですが、本稿で説明しているように実際にはその前後の作業が多く、かつ重要でもあります。

自動テストスクリプトメンテナンス ⑤ は【自動テストシステム運用エンジニア】が担当します。本工程では、実装した自動テストが安定して正しく実行されているか日々の結果を確認したり、自動テストが動かなくなっている場合に問題点の調査と対応を行ったりします。一度作成した自動テストのメンテナンスが必要になるタイミングには、以下のようなものがあります。

このように、一度テストを自動化しても、使い続けるには継続的なメンテナンス作業が必要になります。
自動テスト結果分析 ⑥ は、【自動テストシステム運用エンジニア】が担当します。本工程では、実行した自動テストの結果を基に分析を行います。分析対象となるのは主に結果がNG（Fail）になってしまったケースで、テスト対象に本当に不具合があるのか、それとも自動テストスクリプト／システム側の問題なのかなどの切り分けが必要になります。
分析のために必要な情報の追加や変更、自動テストレポートの表示方法などは、自動テストシステムと連携しながら継続的に改善を行うポイントです。改善は、【自動テストプロジェクトマネージャ】や【自動テストシステムアーキテクト】が中心となって行います。

４．自動テストシステム構築～運用 ⑦～⑩

自動テストシステムの構築から運用までのプロセスについて説明します。自動テストの実装～運用と並行する形で進行し、これらの構成は主に【自動テストシステムアーキテクト】が担当します。
自動テストシステムに関しても、最初に以下のような点について要求分析 ⑦ を行います。

次に、PoC ② や要求分析 ⑦ の結果を基に、自動テストシステムの設計 ⑧ を行います。設計時には、ISTQB (International Software Testing
Qualifications Board) のTest Automation Engineerシラバスで定義されているGeneric Test Automation Architectureや、過去の類似プロジェクトなどを参考にします。
アーキテクチャの設計ができたら、次の自動テストシステム実装 ⑨ でシステムを構築します。自動テストスクリプト実装 ④ で作成した自動テストを実際に自動テストシステム上で動作させながら進めていきます。
自動テストシステムの構築後は、自動テストシステムのメンテナンス ⑩ を継続します。本工程で発生するメンテナンスとしては、例えば以下のようなものがあります。

５．プロジェクトマネジメント ⑪

テスト自動化のプロセス全体において、要求分析 ① やPoC ②、自動テストスクリプトの実装～運用 ③～⑥ や、自動テストシステムの構築～連用 ⑦～⑩ などの各工程のマネジメントとコントロールを行います。この工程は【自動テストプロジェクトマネージャ】が担当します。
テスト自動化を含むプロジェクトのマネジメントを行う場合は、テスト自動化に関する知見が必要になってきます。プロジェクトマネージャは、必ずしも実務担当者と同じレベルでコーディングやシステム構築ができる必要はありません。しかし、JSTQB（Japan Software Testing
Qualifications Board）のテストマネージャシラバスにある「テストツールおよび自動化」の章に書かれているような内容について理解しておいたほうが、プロジェクト全体の進行がスムーズになると考えます。

標準プロセス定義の効果

ここまで、テスト自動化プロジェクトにおけるベリサーブ社内の標準プロセスをご紹介してきました。この標準プロセスの設定によって、以下のような効果が得られました。

１．会社としての提供サービスの品質が向上した

プロセス定義以前ではテスト自動化全体を担当する【自動テストプロジェクトマネージャ】のスキルに依存していた部分が、担当者のスキルに寄らず一定レベル以上のサービス品質で提供することが可能になりました。

２．テスト自動化に必要な準備や発生する作業についての説明・合意形成がしやすくなった

過去のテスト自動化プロジェクトの際、お客様の中には「本当にこれだけの人数・期間・作業が必要なのか？」「もっと効率よくできるのではないか？」と考える方もいらっしゃいました。しかし、標準プロセスを用いて、いつ・何をすべきなのか、どういったスキルを持ったメンバーが必要なのかを説明することで納得していただくことができ、プロジェクトに関わる全員で認識を合わせながら進んでいくことができるようになりました。

おわりに

今回紹介した標準プロセス定義は最初期に策定したもので、以降、さまざまなテスト自動化プロジェクトの知見を取り込みながらアップデートしています。しかし、根幹の部分は変わっていません。標準となるプロセス自体は詳細化しすぎると汎用性が無くなるため、ある程度抽象度の高いものにしつつ、テスト対象のドメインや開発スタイルなどに合わせた個別適用例の蓄積などを継続的に行っています。

日本においてもテスト自動化の事例や公開情報が増えてきており、ポイントを絞った工夫に関する情報や「テスト自動化の落とし穴」などのアンチパターンに関する情報は入手しやすくなっています。しかし、テスト自動化全体を通してプロジェクトをどう進めていくかに関してはそれほど多くない印象です。
「テスト自動化に着手したいけれども、どう始めていいかわからない」「どう進めていいかわからない」といったことに迷われている方は、ベリサーブまでご相談ください。

この記事をシェアする