E2E自動テストプラットフォームの営業が伝える、自動テスト導入と運用のポイント
こんにちは。ぎょりです。
この記事は自動テスト Advent Calendar 2020の13日目のものです。
とあるソフトウェアテスト自動プラットフォームのスタートアップでセールス&マーケティングを担当しています。 世界中のE2Eテストをより良くしていくべく日々奮闘しています。
私たちは、テスト自動化プラットフォームをSaaS(Software as a Servise)として提供しています。このSaaSのようなSubscriptionモデルのビジネスを行うときには「長期的に利用していただけること」が非常に重要です。
「営業って力づくて売り込んでくる」というイメージをお持ちのエンジニアの方もいらっしゃるかもしれませんが、XaaS系のセールスはそうじゃないよって思ってもらえたらなあと常々考えていますw。
もちろん、業界や販売するものが違うと上記のような営業スタイルが重要な場合もあります。 例えば、自家用車といった商品は、契約後にすぐに返品するような商品ではないので、最初の「売ること」が重要になります。
注) 最近はこういった業界もSubscriptionモデルが盛んですが、ここではセールスの話をしたいわけではないので割愛します。
しかし、Subscriptionモデルの商品は、購入後、如何に長期的に使っていただけるかを考える必要があります。プロダクト側が長期的に使える機能を拡充するアプローチを取るならば、セールスやマーケティング側は、長期的に使えるユーザーさんの状態・環境を作っていくことを助けてあげるのが大切な活動の1つになります。
今日は、これまでにそういった背景も含めて葛藤してきた、そして、伝えたいセールス観点でのE2Eテスト自動化、自動テストの導入や運用を進めていくポイントを徒然なるままにお伝えできたらなと思います。ちなみにテスト自動化の8原則を常に脳内で再生しながらお読みください。
想定する読者層
- 第三者検証会社等に所属していて、自動テストを売る日々を送る悩める子羊たち(虎ではなく子羊)
- それを見守るエンジニアやPMの皆様
- これから自動テストをやっていこうと考えているエンジニアにも多少は参考になれば嬉しいです
E2Eソフトウェアテスト自動化プラットフォームを提供するセールス担当者として、導入前に確認していること
人間系と技術系とに分類すると、下記のような項目を確認しています。上述のとおり、これらは「中長期的に自動テストを活用してhogeやfugaなどの成果に繋がること」を確認するためのものです。
人間系観点
- ゴール・目的があるか、またそれがチームで共有されているか : なぜ自動化したいのか
- 明確なスケジュールがあるか、またその理由は
- 品質に関してどのような課題を抱えているか
- コスト(費用, 時間(人材を含む))をどのくらいかけることができるか
- 体制が定まっているか
- リーダーはだれか
- 開発者、運用者はだれか
技術系観点
- テスト項目は明らかになっているか
- テスト項目の中で、自動テスト化するものと手動のまま運用するものの分類が可能か
- テストを実行したい環境はどこか (本番環境か、ステージングかQAか、そしてそれぞれの差分はどこか)
- CICDに組み込めるか
- それはE2Eで担保すべきか
導入するまでにぶちあたるかもしれない壁への華麗な返し例
上記の基本のヒアリングから、営業活動をする中で、3度以上遭遇したことがあるケースを例に、もし「テスト自動化していくぞ！」と思ったときにぶち当たるかもしれない壁と、その対策をお伝えします。
ケース1) 突然現れる、謎の「上長」への対策
突然現れる謎の上長は、しばしば「自動化することの費用対効果を示せ」と言います。何に対しての費用対効果を指すのか、しばしば不明瞭です。
まず、大前提として、テスト自動化の費用対効果はその特性から非常に示しづらいものだと考えています。その理由はいくつかありますが、そもそもテスト自体に見えないコストが多いこと、テストの自動化は、必ずしも「これまでやっていたこと」の置き換え・移行ではないこと、が大きな理由です。
それでも、多少なりとも納得感は持ってもらう必要があります。そうでない場合はうまく運用ができた後に例えば「何も起こらなかったとき(自動化したことでバグが見つけられました!ということがなかった場合などを指しています。)」に、「テストの自動化は不要だった」と判断されかねないからです。
そのため下記のことを確認します。
- 何に対しての費用対効果が最も重要か。
- かかる時間か、それとも過去に発生した損失との比較か。もしくはこれまで導入したことのある全く関連しないサービスの導入にかかったコストと比較しているかもしれません。聞いてみましょう。上長も鬼じゃないし最近は鬼にもいろんな人生があるようなのできっと教えてくれるでしょう。
- これまでに、テストが不十分で課題が発生したことはないか。自動化することで防ぐことができるケースは何か。
現在手動テストを行なっていたケースでは、簡単なものですが下記のような資料を掲示したこともあります。こういった場合には、「そのまま置き換えるものではないよ」という気持ちはグッとこらえて対応する精神力が欠かせません。
数字などはすべて例えとして記載しています。
100件のケースを3日以内に実行している場合, 1日の稼働は8時間、時給を3,000円(人日24,000円)とする
※ 時給情報は公開されるテストエンジニアの求人情報から平均値を算出(当時時点)
8(hour) * 3,000(yen) = 240,000円/回のテスト にかかっている。 構築に500,000円, 運用時に月々100,000円の運用費がかかると仮定すると、3回以上のテストを実行すれば費用対効果が出るという説明ができます。
でも、私がこれまで相談をいただいたケースの多くは、上長の方に「やりたい」という気持ちを伝えると背中を押してくれるものでした。「やっていくよ！やりきっていくよ！」と伝えるのが一番重要かもしれません :)
また、ぜひ困ったときはこのような説明を得意とする私のような営業や、近くの頼れる同僚たちを呼んで上長と話をさせてもらうなど、どんどん巻き込んでいただきたいです！
ケース2) 「自動化」という言葉を神格化しちゃった勢への対策
「自動化するよ！」という言葉を聞いてドラ○もんかのように期待を寄せらてしまうこと、ありますよね。実装前から高いハードルが積まれていくことを自ら防いでおきましょう。これは俗に言う「期待値コントロール」ってやつだと思います。
自動化のサービスを提供していると、そのイメージを持って利用を検討している方も全体の20%ほどは存在し、下記のポイントをお伝えしています。
自動化が有効でないケースを説明する
自動化は "人間の仕事から機械の仕事への置き換え" です。つまり、これまで人手で、暗黙のうちにやってしまっていた "見えない" 作業を、自動化する際には全て明確にする必要があります。
例えば、 "画面が正しく表示されていること" というテストケースは、 "画面遷移後、aaとbbとccにxxxが表示されていることを確認する" のように、明示的なアサーションとして実装する必要があります。
これを言い換えると、このように明示的にできないものは自動化できません。また、前章に絡めていうと2,3回使うことを前提にしいていますので、例えば作った自動テストコードを1回しか実行しないようであれば、自動化は有効でないと言えます。
「有効にならないこと」の存在を知れば、神格化せずに、自動化と向き合うことができるようになります。
自動テストの運用コストについて説明する
自動テストを導入しても、運用コストは発生します。
手動テストとして実行する部分、自動テストのメンテナンス、自動テストの追加もあるでしょう。これらのコストを明確にしておくことが大切です。
私の実践例では、構築時と運用時のコストをわけて、想定のスケジュールも見せるようにしています。
自動化によるメリットを正しく説明する
最後に自動化によるメリットを正しく説明します。私がよく説明する内容は下記があります。
- テストの頻度を上げることができる
- 頻度を上げられるということは、課題が発生したとき(バグが見つかったときなど)の原因調査する範囲や対象を絞ることができる
- そのテストが稼働している間、他の業務に時間をあてることができる
- どのようなテストをしているか"見える化"できる
正確なテストができる。人間だとノイズが入るケースを防ぐことができる
ケース3) 「自分で全部作れば？」勢への対策
自動テストに向けて、SeleniumやAppiumなどを使って自前で構築する方法と、今世の中に存在するサービスを利用する方法とがあります。 サービスを利用するメリットは、時間とコストと技術追従のスピードにつきると私は考えています。 だって、そのサービスだって人間が作り出したものだからです。自動テストの環境の構築と運用等を行う専門の人材がもつスキルセットは、
- テスト対象アプリケーションのドメイン知識がある
- テスト設計ができる
- アプリケーションに合ったテスト技術を選定し、テストコードを書ける
- 関連する技術の情報を幅広くキャッチアップしそれをツールに落とし込める
- それらのコストを最小化することができる
サービスを使うということは、これらの複数または1つにかかるスキルや労力を少しずつアウトソースしているということです。つまり、こういった自前主義勢の方には明確に1~5いずれかまたは複数の内、何%をアウトソースしたいということを明確に伝えると良いんじゃないかと思います。(チャートレーダーとか使うと楽しいよ！) 「どこをアウトソースしたいのか」が見えてくれば、選択すべきサービスやツールなども見える化できて一石二鳥!!
ケース4) 問題先送り勢への対策
担当者からすると今すぐにやりたいのに、「なんで今なの？」と聞かれることもあります。
理由は簡単で、後になればなるほどテストケースは増えますし、観点も増加する一方だからです。それに早ければ早いほど、それらを前提とした開発・リリースの体制、プロセスを作り上げやすいです。テストを実行する対象のサービスもアップデートしていくわけですし、これらのプロセスもまずはやってみて、やりながら改善していくのが品質とサービスとが切り離されないコツの1つでもあるなと感じています。
一方で、UIが全く定まっていない状態、ユーザーが0人でプロダクトとしてどう提供していくかがまだ定まっていないフェーズの場合はまだ早すぎるな、と感じたことはありますしその場合はその時点でお伝えするようにしています。
こんな感じでセールスの視点から考えるE2E自動テストの導入や運用への向き合い方についてお伝えしました。一般論的なところに落ち着いてしまった感もあって悔しさもありますがw、これからやっていこう、今やり始めたけどちょっと壁がでてきた、そんな方々の参考と背中を押すことができてたらなと思います。
こちらのブログを公開するにあたり、テスト自動化スペシャリストの @tsueeemura さんにアドバイスをいただきました。ありがとうございます!!
