#Outline
テスト自動化・自動テストの取り組みについて、D-Cubeから講演のお誘いがありました。
そこで、業務上の概ね闇ばかりをお話ししました。
https://d-cube.connpass.com/event/149831/
#Contents
1. 自動化を立ち上げる時の闇（苦労）
状況
- テスト自動化をまだ導入していないフェーズ
- マニュアルテストでなんとか品質は担保できている
- テスト自動化はコストがかかるし、コストだけではなく初めて見ることに高い壁を感じていた
このような状況のため、テスト自動化をやってみようという雰囲気ではなかった。
机上でROIの議論はでたものの、実際に自動化がどんなもので、どんな効果があるのか見えにくかった。
自分は、エンジニア経験があったため、作業効率化含めて自分でやってみればいいんじゃないかと思っていた。
そこで、周囲の人にテスト自動化を正しく理解させることから始める必要があった。
QA立ち上げ時でもあり、アプリエンジニア経験あるのは自分だけなので、一人で隙間時間でPOCを行った。
- 自動化で、テストや、それ以外の作業効率化を実数値で見える化
- 当然、コストメリット（時間コスト含む）も試算
このような経緯でもって、テスト自動化の予算承認が下りて導入に漕ぎつけたが、次の課題が出てくる
状況
- テスト自動化エンジニアが少ない
- 現在のQAプロセスで自動化をどのように使うのかがわからない
いまのQAメンバでできるテスト自動化のプラットフォームを構築。
Open Sourceでコードバリバリ書くスタイルはやめました。
今のチームでできるメンバーがほどんどいなく、かつメンテナンスコストもかかるからです。
そこで有償ライセンスのテスト自動化をベースに、環境を構築した。
そのうえで、QAプロセスでテスト自動化の活動をどのようにいれるかも、試行錯誤した。
2. 自動化が立ち上がった時の闇（苦労）
チーム内の状況
- 処理を自動化しているが、validationしてなく、テストになっていないものが多い
- 自動化の作成数がメインとなり、マニュアルテストでもあまり価値のないテストの自動化までも行われる
当初、”この機能を自動化しよう”という風に、自動化の詳細な内容に関しては明確にしてこなかった。
そのため起きた事象。
マニュアルテスト経験の人もいたが、アプリエンジニア経験が強い人が多かったこともあり、このようなことが起きてしまった。
そのため、自動化の定義を明確にして進めないといけないと感じた。
まずは、テストを自動化することが目的なので、マニュアルと同様に、なにをvalidateするのかを明確にし、それに基づいて実装するようにした。
次に、自動化のする・しないの判断軸を明確にする。例としてアジャイルテストの4象限があります。
自分のチームに適した、自動化のする・しないの基準を設け、それをもとに自動化を取り組んだ。
また、せっかくの自動化なので、テスト以外で自動化により作業改善できる事、例えばテストデータ作成等、そういった多方面の使い方も検討に入れた
チーム外からの状況
- テスト自動化の過剰な期待が高まる
- すべてが自動化に置き換わるのでは？説
テスト自動化をよく理解していないステークホルダからは、銀の弾丸のように見えてくることがある。
テスト自動化が全てやってくれるのでは？ と。
自動化の予算をとったこともあるため、自動化に関して消極的なことは言えない。
とはいえ、マニュアルテストと自動化をバランスよく進めないと、前に進めないことを説明する必要がある。
これは地道に、テスト自動化に関して、例えばテスト自動化の8原則のようなことを説明するしかなかった。
テストエンジニアでも自動化の理解が乏しい人がいたので、モブプロちっくに実際に自動化作成をやらせてみせて、体験してもらうこともした
3. 自動化が安定してきたときの闇（苦労）
テスト環境の状況
- テスト環境のインフラ（ネットワーク、サーバー等）が全社共通で利用しているため、不安定
- アプリケーションが頻繁に更新して、不安定
- テストデータが、複数人利用して不安定
それにより、自動化がよく落ちる。
よく落ちるため、その原因調査、復旧に時間が取られてしまう。
これを回避するために、まず最初にしたことが、失敗の可視化。
JENKINSを複数起動してテスト自動化しているが、これを毎日定期的に全てチェックするのは大変。
teamsで失敗した時、通知する方法もとっているが、現時点どれだけfailしているかがわからない。
そして、よく失敗するテストがなにかがわからない。
それらを可視化する仕組みをつくった。
可視化ができれば、よく落ちる原因をもとにエンジニアと環境整備等をはたらきかけ、
自動化のスクリプトもその不安定さに耐えうる実装できないかの検討もしぼりこみができ、着手しやすくなった
プロダクトの状況
とはいえ、自動化が落ちるのはそれだけではない。
プロダクトに変更が入れば、自動化はfailする。
- 2週間サイクルでちいさな改修が発生する
- 重要な機能にも改修が入る
- 自動化の考え方として、頻繁に変更の入るところの自動化は不向きというが、そのスタンスは取っていない
このため、自動化のスクリプトを定期的にプロダクトに追従する必要性がある。
これを実現するために、以下のようなフローにした
- プロダクトの更新と既存の自動化スクリプトの影響範囲の確認をするフロー
- 自動化のスクリプティングに優先度を決め、先にfailするであろう、既存scriptの改修から作業する。最悪新規機能の自動化はリリース後に対応
4. 現在の闇（苦労）
いまのQA組織立ち上げから約3年間自動化をやっていますが、テスト自動化のエンジニアが少ない。
協力会社にも協力を仰いでいるが、それでも少ない状況。
それをなんとかしたい！