前回まではシステムテストの自動化に用いるツールの選定方法について説明しました。

テスト自動化ツールを適切に選ぶことで、チームでの開発・テストが効果的に行えるようになるでしょう。
しかし、特定の開発チームだけの取り組みに留まらず、開発部門全体や会社全体の施策として普及・推進を求められる場合も。そこで今回と次回は、組織におけるテスト自動化の普及・推進について扱います。
前編となる本記事では「阻害要因と対策」として、テスト自動化や自動テストの活用を組織で広めていくうえでの阻害要因についていくつかのパターンを取り上げ、各要因に対してとるべき対策について解説します。

なお、本記事中の「テスト自動化」は前回までと同様、E2Eテストなどテスト対象のUI、とくに画面を操作しておこなうようなテストのことをターゲットとします。

テスト自動化に対して「組織」で取り組むのはなぜか

ここで、今回のテーマである「普及と推進」について考えてみましょう。

ある開発チームでテストを自動化する場合、自分たちのテストが効果的に行えればそれでいいのでは、と思われるかもしれません。

たしかに、開発チームの中でテスト自動化を行いうまく回せている状態になれば、それはすばらしいことです。しかし、わたしが見てきたテスト自動化の導入事例においては、大きく分けて以下の2つのパターンで組織的な取り組みとしてのテスト自動化を求められる場合がありました。

パターン1.特定チームでの成功事例を横展開

1つは、ある開発チームでのテスト自動化で一定の成果が出た場合に、それを他の開発チームへと展開するように求められるパターンです。

テストを効果的におこなうことへの課題を抱えた開発チームはまだまだ多くあります。そうした状況において、「個別の取り組みの成功事例を他チームへと展開してほしい」とマネージャーや経営層から求められるのは、自然なことかと思います。

また、マネジメント層からの要請というトップダウンの形だけではなく、他チームから直接声がかかるボトムアップの形でも横展開につながる可能性があります。こちらも理由はさまざま考えられます。単純に成功事例を聞きつけて「自分たちも」となることもあれば、年度目標に「開発効率化」を掲げるもなかなかうまくいかず、1月くらいになって他チームのテスト自動化事例を取り入れてなんとか年度内に着手したパフォーマンスを・・・ということもあるかもしれません。

こうした組織内での要請があった場合、テスト自動化に成功したチームにおいて主体的に動いていた方が自然と「テスト自動化の推進役」としての動きを期待されます。

パターン2.開発部門や会社としてテスト自動化を目指す

パターン1と異なり、部門や会社として「テスト自動化をやっていくぞ」という決定のもとでテスト自動化を推進するパターンもあります。パターン1のトップダウン型に近いですが、こちらは個別の部門やチームでの成功事例を元にするのではなく、最初から組織全体でテスト自動化が行われる状態をゴールとして開始します。

このパターンの場合、組織の中でテスト自動化の推進役を任命したり、特定の(もっとも反発がなく、うまくいきそうな)開発チームを選んで「やってみなさい」という指示が出たりします。

続きを読むにはログインが必要です。
ご利用は無料ですので、ぜひご登録ください。

SHARE

  • facebook
  • twitter

SQRIPTER

伊藤 由貴(いとう よしき)

記事一覧

テスト自動化エヴァンジェリストとして、エンジニア育成・テスト自動化コンサルテーション・部署の立ち上げ・マネジメントなどを経験。
現在は複数Webサービスを運営する会社の横断部門にて、QAエンジニアとして活動中。

Sqriptsはシステム開発における品質(Quality)を中心に、エンジニアが”理解しやすい”Scriptに変換して情報発信するメディアです

  • 新規登録/ログイン
  • 株式会社AGEST