前回まではシステムテストの自動化に用いるツールの選定方法について説明しました。
テスト自動化ツールを適切に選ぶことで、チームでの開発・テストが効果的に行えるようになるでしょう。
しかし、特定の開発チームだけの取り組みに留まらず、開発部門全体や会社全体の施策として普及・推進を求められる場合も。そこで今回と次回は、組織におけるテスト自動化の普及・推進について扱います。
前編となる本記事では「阻害要因と対策」として、テスト自動化や自動テストの活用を組織で広めていくうえでの阻害要因についていくつかのパターンを取り上げ、各要因に対してとるべき対策について解説します。
なお、本記事中の「テスト自動化」は前回までと同様、E2Eテストなどテスト対象のUI、とくに画面を操作しておこなうようなテストのことをターゲットとします。
テスト自動化に対して「組織」で取り組むのはなぜか
ここで、今回のテーマである「普及と推進」について考えてみましょう。
ある開発チームでテストを自動化する場合、自分たちのテストが効果的に行えればそれでいいのでは、と思われるかもしれません。
たしかに、開発チームの中でテスト自動化を行いうまく回せている状態になれば、それはすばらしいことです。しかし、わたしが見てきたテスト自動化の導入事例においては、大きく分けて以下の2つのパターンで組織的な取り組みとしてのテスト自動化を求められる場合がありました。
パターン1．特定チームでの成功事例を横展開
1つは、ある開発チームでのテスト自動化で一定の成果が出た場合に、それを他の開発チームへと展開するように求められるパターンです。
テストを効果的におこなうことへの課題を抱えた開発チームはまだまだ多くあります。そうした状況において、「個別の取り組みの成功事例を他チームへと展開してほしい」とマネージャーや経営層から求められるのは、自然なことかと思います。
また、マネジメント層からの要請というトップダウンの形だけではなく、他チームから直接声がかかるボトムアップの形でも横展開につながる可能性があります。こちらも理由はさまざま考えられます。単純に成功事例を聞きつけて「自分たちも」となることもあれば、年度目標に「開発効率化」を掲げるもなかなかうまくいかず、1月くらいになって他チームのテスト自動化事例を取り入れてなんとか年度内に着手したパフォーマンスを・・・ということもあるかもしれません。
こうした組織内での要請があった場合、テスト自動化に成功したチームにおいて主体的に動いていた方が自然と「テスト自動化の推進役」としての動きを期待されます。
パターン2．開発部門や会社としてテスト自動化を目指す
パターン1と異なり、部門や会社として「テスト自動化をやっていくぞ」という決定のもとでテスト自動化を推進するパターンもあります。パターン1のトップダウン型に近いですが、こちらは個別の部門やチームでの成功事例を元にするのではなく、最初から組織全体でテスト自動化が行われる状態をゴールとして開始します。
このパターンの場合、組織の中でテスト自動化の推進役を任命したり、特定の（もっとも反発がなく、うまくいきそうな）開発チームを選んで「やってみなさい」という指示が出たりします。
組織で取り組むことが、継続的な成功につながる
いずれのパターンにも共通するのは、テスト自動化をおこなっているチーム・部門とおこなっていないチーム・部門が共存するのではなく「できるだけ皆やったほうがいい」という意識はある、という点です。
とくに、ITエンジニア全般の中途採用がなかなか進まないと言われている昨今においては、開発におけるさまざまな部分を少しでも効率化したいというのは自然な考えです。
しかし、この「テストを自動化して効率化したい」という共通認識がある状態にもかかわらず、なかなかテスト自動化がうまくいかない、組織の中で広がっていかないという声もよく聞かれます。このギャップはどこから生まれるのでしょうか。
それは「大事である」「やりたい」という気持ちに反し、組織として適切なフォローがなされていないから、というのがわたしの考えです。テスト自動化を個別のチームで軌道に乗せるところまでは、優秀なエンジニアの存在や、開発チームの皆の努力によって達成できます。しかし、問題はその先です。せっかくテスト自動化がうまくいきそうなチームがあったとしても、組織としてのフォローがなければ継続的な成功には至れません。まして、他チーム・他部署への横展開は困難になります。
補足：書籍や公開資料における、自動化普及の位置づけ
書籍や資料によっては、「組織にどう展開するか」を初期段階から検討することが、当然のように書いてあるものもあります。たとえばJSTQBのテスト自動化エンジニアシラバスや、書籍『Experiences of Test Automation: Case Studies of Software Test Automation』などです。これらの中には「パイロットプロジェクト」という言葉が出てきます。これは、組織におけるテスト自動化普及のため、最初に特定のプロジェクトでテスト自動化の導入をトライアル（パイロット）し、そこから他のプロジェクトに展開していくというものです。
組織面の阻害要因と対策
ここからは、実際に組織においてテスト自動化を進めていく上でよくぶつかりがちな壁、つまりテスト自動化の阻害要因とその対策について説明します。
これからテスト自動化を始める場合は、ぜひこれらの壁にぶつかる前に手を打つようにしてください。
体制、工数、予算などのリソースをかけられない
1つ目の阻害要因は、体制や工数、予算など、テスト自動化を進めるうえでのリソースが得られないことです。
これまで手動でおこなっていたテストを自動化しよう、と考えたときに、どうもその労力を少なく思われてしまう傾向にあるようです。
現場レベルでは、たとえばテストエンジニアに対して「テストの合間にやってよ」であったり、開発者に「案件の手が空いたときにちょっとやっておいてよ」などと依頼されることもあります。これらの「合間」「手が空いたとき」は、基本的には永久に訪れないため、テスト自動化はいつまでたっても進みません
上記の問題は、組織全体の認識あるいはマネージャーの指示として「テスト自動化よりも、開発や（手動での）テストなど普段の業務が優先」という共通認識が生まれているために起こってしまいます。
わたしがテスト自動化のコンサルテーションをおこなう際には、「システムテストの自動化は、既存のテスト対象システムと同規模の対向システムを構築するのと同じくらいの心構えが必要ですよ」と説明しています。必ずしも同等の規模になるわけではありませんが、そのくらい考えること・やることが多いと思って始めたほうが確実です。
そのため、主担当となる個人もしくはチームを任命してテスト自動化を推進することをオススメしています。
可能な限り
- 専任の担当者をアサインし、他業務との掛け持ちではなくテスト自動化業務のみをおこなってもらう
- 有料のツールを契約するだけの予算を確保しておく
- 専任の担当者以外にも、開発者やテストエンジニア・QAなどのステークホルダーに対して、担当者からのQ&A対応やヒアリング対応をする工数を確保しておく
ことが大切です。
一方、専任をアサインすることの注意点もあります。それは、「＊＊さん（もしくは＊＊チーム）に任せればやってくれる」と思われてしまうことです。専任の担当者やチームはあくまでも推進役であり、最終的なテスト自動化の主体は各開発チームになる、ということを最初から周知したうえで進めていくのが安全です。
改善を良しとする文化がない、内部での抵抗がある
2つ目の阻害要因は、内部での反発に関するものです。
経営層やマネジメントレベルで「テストを自動化して効率化しよう」という点で合意ができても、メンバー層で同意が得られるとは限りません。これは、前述のパターン2、組織として「自動化をやる」という決定が先で現場に降りてきている場合に発生しがちです。
内部で抵抗・反発をされる理由も多々考えられますが、代表的なものは以下です。
- 大変である、かえって仕事が増える
- 仕事がなくなる
- これまでのやり方を変えたくない、新しいことを覚えたくはない
テスト自動化が大変だ、やることが増える、という面もたしかにあるため、これらはテスト自動化の推進役やマネジメント層からていねいに説明する必要があります。とくにテスト自動化の導入初期においては、手動実行よりも工数が増えるという考えも一般的です。しかし、これは一時的なものであり、テスト自動化を導入して自分たちの仕事のやり方を変えていくことで、ゆくゆくは楽になるということを理解してもらわなければなりません。
一方、仕事がなくなる、これまでとやり方を変えたくない、といった反発に対処するのは大変なことです。これらはテスト自動化というよりも仕事に対するマインドセットや組織カルチャーの問題です。
こうした反発が個人であれば外れてもらうという選択もできますが、チーム単位でこうしたマインドになっている場合はそうはいきません。
対症療法的なやり方にはなりますが、まずは組織の中でアーリーアダプターにあたるチームや、新しいやり方や改善に対して能動的に取り組んでくれるチームを選び、そこからテスト自動化の導入を進めていくのがセオリーです。そこで成功事例を作り、だんだんと組織に浸透させていくことで、当初反発していたチームが「やらない」理由を減らしていくという作戦です。
期待値や目標設定が適切でない
3つめの阻害要因は、期待値や目標設定が適切ではない、つまり「期待しすぎる」というものです。
たとえば、
- 自動化率100%
- 大幅なコスト削減
- テストを自動化すると新しいバグが見つかる
などです。これらはテスト自動化に対する過剰な期待であり、こだわりすぎるとかえって時間やコストがかかったり、テスト自動化が止まってしまうこともあります。
マネージャーなど、テスト自動化の推進を指示する立場にある方は、まずは世のテスト自動化を知るところから始めてみてください。最近は書籍や企業ブログでの事例公開なども増えており、テスト自動化でつまづきがちなポイントや「大変さ」などの情報が手に入りやすくなっています。
一方、テスト自動化を推進する立場のQAエンジニア・テスト自動化エンジニアの側も、マネージャー含め周囲の適切な理解を得るための活動をする必要があります。こちらも、世の中に公開されている参考情報をまとめて説明することもひとつの手です。あるいは、過剰な期待をされていると感じた場合には「なるほど！では、OSSを使って一部の自動化をやってみますね！」と言って小規模なトライアルを行い、テスト自動化を行った結果の試算を提示するというやり方もあります。
- テストを自動化する工数
- 既存のテストのうちどの程度を自動化できるのかの割合
- それによってテスト実行がどの程度効率化されるのか
- テスト自動化に伴う追加のタスク
などを試算して説明を行えば、期待値と実際とのギャップが伝わりやすくなるでしょう。
※既存のテストケースをそのまま自動化するのはアンチパターンですが、ここでは説明材料を得るための手段としてあえて用いています。
よく言われるように「銀の弾丸はない」ことをていねいに説明することが大切です。
現場サイドから、正しい理解を広めていきましょう
今回は、組織内でテスト自動化を普及・推進するうえでの阻害要因とその対策について説明しました。
テスト自動化を継続的におこなっていくためには、個人や個々のチームの取り組みで留めるのではなく、組織全体として取り組むこと・適切な支援が必要です。
現場で普及・推進を担う担当者・担当チームからは、マネージャーをはじめ組織の中で適切な期待値設定とフォローが受けられるよう働きかけていくことが大切です。
こうした「理解を得て、推進していくこと」はテスト自動化に限った話ではなく、開発におけるさまざまな取り組みに共通する課題でもあります。専任の主担当をおくこと、適切な期待値・目標を設定すること、などは他の技術要素やプラクティスを広める際の考え方と通じるものです。
本記事の最後に、テスト自動化の普及・推進の参考になる情報源を載せてあります。こちらを見ていただきつつ、組織全体でテスト自動化に取り組んでいけるよう、活動してみてください。
参考情報
本記事の内容、とくに組織におけるテスト自動化の阻害要因への対策に関しては、わたしの実体験に加えて以下の書籍やサイトも参考にしています。
組織でテスト自動化を進めていくことになった、あるいは今困っている、という方はぜひ参考にしてください。
- Test Automation Patterns
- テスト自動化におけるよいやり方や避けるべきことなどがまとまっているWikiです。本記事の内容は、とくにManagement IssuesやManagement Patternsに関連しています。
- Experiences of Test Automation: Case Studies of Software Test Automation
- 古い本ではありますが、テスト自動化に関する多数の事例が掲載されています。
- システムテスト自動化 標準ガイド (CodeZine BOOKS)
- テスト自動化についての考え方や期待値の設定については、こちらの書籍も参考になります。技術的な内容も含まれていて厚みがありますが、本記事にもっとも関係する「11章組織内へのツールの導入」だけでも読んでみてください。
- Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン
- こちらはテスト自動化に関する書籍ではありません。しかし、なんらかの技術や考え方・取り組みを社内で普及・推進していくうえで参考になります。
連載一覧
テスト自動化ツールの選定【前編】～ツールの比較表をどう活用するか
テスト自動化ツールの選定【後編】～AI自動テストツールを選ぶ時に気をつけるべきポイント
テスト自動化の普及と推進【前編】～阻害要因と対策
テスト自動化の普及と推進【後編】～個人レベルでテスト自動化を学ぶ
テスト自動化とテスト設計【前編】～作成済のテストケースの整理と加工
テスト自動化とテスト設計【後編】～テスト自動化のためのテスト設計
