本記事は、『テスト自動化失敗談を共有しよう！ by T-DASH Advent Calendar 2022』に参加しています。
よろしくお願いいたします！！
2022/12/21を担当しております。
『テスト自動化ツールT-DASHの良い点・悪い点をレビューしてみた！ by T-DASH Advent Calendar 2022』にも参加しております。
『テスト自動化ツールT-DASHの活用方法や事例を記事にしよう！ by T-DASH Advent Calendar 2022』にも参加しております。
みなさん自動化してますかー♪
「いま頑張って取り組み中だよ～」、「来年から始めようと思っています！」という方、
ちょ～～～っと待ったぁ！！！ その自動化、本当に上手くいきますか？
「そう言われると実は心配なんです…」と思っちゃったそこのあなたっ！
そんなあなたにピッタリの記事をご紹介しましょう。
この記事ですww
本記事は、筆者のE2Eテスト自動化失敗談と、自動化に再挑戦して成功した話について記載 しています。
これからE2Eテスト自動化にはじめて（もしくは一度挫折してもう一度）取り組む方の参考になれば幸いです。
この記事を読んで、E2Eテスト自動化のヒント
を発見
できるかも しれません。
この記事では自動化の設計や実装コードについては書いていません。
自動化への取り組む姿勢、自動を成功させるための考え方 について、筆者の経験を交えて記載しています。
途中途中で愚痴が入っていますが、「それ、わかるぅ～」と軽いノリで読んでいただければ幸いです。
はじめに
私が所属している企業ではBtoB、BtoCのサービスを開発しています。
専任のテストエンジニアがテストを担当しています。
主な業務内容
主な業務内容はこちらです。
- 新規/既存開発プロジェクトのテスト
- システムテスト
- 回帰テスト
- テスト工程の管理
- テスト分析、テスト計画
- テスト設計（テストケースの作成）
- テストデータの作成、テスト実行環境の管理
- インシデント管理
- テストチームメンバーのスケジュール管理、教育
- その他
テスト工程前後や、テスト工程中に発生するテスト関連の業務全般を担当している感じです。
開発プロジェクトに対して、テストの切り口で、PM、開発リーダー、その他関係各所と協力して進めています。
テスト対象の規模にもよりますが、比較的規模の小さいテストプロジェクトの場合は、 一人でテストすることがけっこう多いです。
いわゆる1人情シスみたいな感じ。
E2Eテスト
最近では、Webアプリのシステムテストの業務が増えています。
Webアプリの場合、自社開発した部分以外での 外部要因によりリグレッションテストが多発 しています。
リグレッションテストが発生するタイミングは次の通りです。
- 動作対応ブラウザー（Chorme、Firefox、Edge、Safari、ほか）がバージョンアップした
- 動作対応OS（Windows、Mac、Linux）がバージョンアップした
- Webアプリ内で利用しているサードパーティ製のソフトウェアがバージョンアップした
- Webアプリ内で利用しているOSSのソフトウェアがバージョンアップした
- Webアプリ内で利用しているその他ライブラリ（JSなど）がバージョンアップした
- 動作対応スマートフォン（iOS、Android）がバージョンアップした
これらの外部要因と、Webアプリ自体のバージョンアップも合わせると1年に十数回もリグレッションテストを回しています。
1回のリグレッションテストに丸2日要するため、 年に20～40日もリリースを喰われている状況 です。
これを 毎回手動テストで実施 していました。
というこで テスト自動化で省力化出来ないか、一人で取り組み を進めました。
自動化してみたが失敗した！
当時はテスト自動化への挑戦は初めてで何もわからない状態でした。
とりあえず自動化ツールを調べて、 無料でかつ高機能そうな「CodeceptJS」で実装を進めてみる ことにしました。
手が空いている時間にコツコツコードを実装し、手動テストの7割くらいまで自動化できました。
あとはこれを運用で利用していければ良いのですが、ここで問題が発生しました。
自動化していたWebアプリのUIを全面的に改修するバージョンアップが企画され、実装したコードのほとんどが動かない 状態に陥りました。
「すでにユーザーに提供している画面なのだから、大幅なUI変更はユーザーを混乱されせるため、発生しないだろう」 と考えていたのですが、私の思惑は外れてしまいました。
この時、次の理由からこの自動化作業を中断することに気まました。
- もう一度コードを書き直すモチベーションを維持できない
- 自分の業務が忙しくて、そもそも自動化に割く時間を生み出せない
- コードを引き継げるメンバーがいない
こうして自動化の夢は消えていきました。
引き継ぎの問題が発生
家庭の事情で退職予定のメンバーが出てきました。
このメンバーが担当している業務を所属部署の誰かに引き継がなければいけないことになりましたが、他のメンバーも各自担当を持っておりリソースが足りません。
引き継ぎ業務の内容をヒアリングしてみると、その大部分が リグレッションテストの作業 であることがわかりました。
チームメンバーと相談し、このリグレッションテストをターゲットにして、もう一度自動化に挑戦してみよう！ということで旗が立ちました。
自動化失敗から学んだ、自動化を成功される道筋を立てる！
さて改めてテスト自動化に挑戦する機会が巡ってきたわけですが、次はもっと上手く立ち回りたいと当然考えますよね。
前回のテスト自動化失敗から学んだ教訓は次の通り です。
- UIは変更される
- コードを書くモチベーションを維持する
- 自分の業務が忙しくて手が回らない場合を考慮し、他の手が空いているメンバーでも対応できる必要がある
- コードを引き継げる（再利用性を高める）必要がある
上記の各課題について解決策を検討しました。
UIは変更される
UIは変更されるため、メンテナンスは常に発生する前提として自動化プロジェクトを運用する必要があります。
それでもあまりに頻繁メンテナンスが必要だと作業負荷に耐えられないため、枯れた（変更される可能性が低い）UI部分の自動化から実装を進める。
ここで重要なことは 「自動化しやすい部分を自動化する」 のではなく、 「自動化によるメリットの恩恵が十分受けられる部分を自動化する」 ことを強く意識することです。
このポイントをしっかり抑えておかないと 「自動化したけどあんまりメリットないよね」 と第三者目線からは見えてしまうことがあり、自動化の評価を下げてしまう危険があります。
-
その自動化は、自動化する意味を自信を持って説明できるか
- 業務で行っているわけですから当然ですが会社からは「結果」を求められます。このとき、「便利そうだから」、「工数を減らせると思ったから」などという曖昧な報告では一蹴されます。 上層部の方は数字でモノを語るの好きですから、「手動」でやった場合と、「自動」でやった場合に、どれだけコストを下げられる見込みであるのか、定量的に示せる準備をしておくと説得しやすいです。
コードを書くモチベーションを維持する
自分の業務が忙しくて手が回らない場合を考慮し、他の手が空いているメンバーでも対応できる必要がある
コードを引き継げる（再利用性を高める）必要がある
上記3つの課題はまとめて解決する案を計画しました。
私の所属部署は基本的にコードを書けるメンバーがいません（開発経験がないし、トレーニングも受けていない）。
そのため、たまたまちょっとコードが書ける私が1人で自動化を進めていました。
しかし私一人のリソースでは、どうやっても上記課題を解決することが出来ません。
そこで 自動化テストプロジェクトを短期ではなく中長期的な期間で取り組む計画 としました。
メンバーにコードの書き方、自動化の基礎トレーニングを行い、まずは自動テスト開発に必要なスキルを身に着けてもらいます。
その上で、テストプロジェクトの開発計画を立てました。
全メンバーが他の業務も兼任している状況にあるため、 設計、実装の時期だけざっくり決めておき、担当は仮決め としました。
臨機応変に担当者を変更することを約束しておくことで、メンバーの精神的負担を減らす ことに成功できたと思います。
（結果的には各メンバーが自分の担当を期日を守って取り組んでくれました）
自動化の計画
さて課題解決の道筋が見えてきましたので、次に計画書の作成に取り掛かりました。
「計画書なんて誰が見るの？」、「面倒くさい」、「時間の無駄でしょ！？」と頭を過った方は注意が必要ですよ。
だってこれから新しい仕事を始めるんですよね。
それって将来のことを考えてやるんですよね？
「こうなりたい」、「ああしたい」という理想や目標がその根底にあるはずです。
会社の事業計画と考え方は同じです。
なりたいビジョンに向けて、今、私たちは何をすべきなのか、それを言語化したものが計画書なのです。
私は、計画書には次の内容を盛り込みました。
-
自動化の注意点（心構え）
- 自動化は リグレッションテストへの適用のみを目的 とする。
- リグレッションテストでのバグ発見を目的としたものであるため、 自動化によって製品の品質が目に見えてよくなることを狙いとはしていない 。
- 自動化しやすい部分ではなく（ 自動化ツールで自動化しやすい部分を自動化する考えはしてないけない ）、メリットが高い部分をテストを自動化する
- 何でもかんでも自動化に頼らない。「あれもやりたい、これもやりたい。…」は沼にハマります。 テストする価値がある部分を見極める。
-
テストプロジェクトの工程作業
- 計画（目的は何か。ゴールは何か。いつまでに、何をやるのか。）
- 設計（どの手動テストを自動化するか）
- 実装（設計からコーディング）
- テスト（自動テストコードのテスト）
- 運用（リグレッションテストのタイミングが来たら、自動テストを試す）
テストプロジェクトを計画する上で必要な作業 については、こちらの図をご参照ください。
ここに記載した内容を概ね抑えておけば、失敗するリスクを大幅に減らすことが出来る ではないでしょうか。
自動化計画で特に大切なポイント
今回はチームとして自動化作業に取り組むため、きちんと進捗をコントロールする必要があります。
ここで大事なポイントは、「①いつでも、誰でも目標に立ち返れること」 、 「②メンバー全員で同意形成すること」 です。
①については以外と盲点ですが、長いスパンで作業をしていると 「いま自分がやっている作業は何のためにやっているのか？」 見失うことがあります。
特に途中でメンバーの入れ替わりがあると、それが顕著に現れます。
テスト計画書という誰でもいつでも目にすることが出来る目標があれば、冷静に立ち止まって、今一度目的を再確認することにとても役立ちます。
こういった開発作業は設計や実装に目が行きがちですが、それよりもその大元である計画書の方がずっと重要です！！
②はきちんんと目的とメリットを説明、共有し、同じゴールに向かって結束することを約束します。
どんな仕事でもそうですが、 理由を説明せずに「これやっておいて！」では、前後の文脈を読めないメンバーは十分な力を発揮できません。
チーム開発において最大限の内省力を引き出すにはチームメンバーのマネジメントをしっかりしましょう。
開発環境、自動化ツールの選定
テスト計画をしっかり立てることが出来たら、 次に重要なポイントになってくるのが開発環境、自動化ツールの選定です。
E2Eで利用されているツールとしてよく目にするのは、Python、Selenium、Cypress、Puppteer、Playwright、CodeceptJS、Autify、MagicPod、Ranorex、T-DASHあたりでしょうか。
この中で私が触ったことがあるものは、Python、Selenium、Cypress、Playwright、CodeceptJS、T-DASHです。
ツールの選定において重要なポイントを整理しておきましょう。
- 無償か安いか？
- 初期コスト、ランニングコスト
- ライセンス規約
- 利用者が多いか？
- 初心者向けの記事が多いか？
- 導入敷居が低いか（比較的簡単であるか、学習コストが低いか）？
- 再利用性（メンテナンス性）が高いか？
今回の自動化プロジェクトではメンバーのスキル事情、予算取りもしていない事情があるため、上記ポイントをすべてクリアしていることが要件となります。
まず無償で出来た方がよいので、Python、Selenium、Cypress、Puppteer、Playwright、CodeceptJSが候補として残りました。
次に利用者の多さ、初心者向けの記事が多さで、 Python + Selenium の組み合わせを採用することに決定しました。
CypressやCodeceptJSは非常に魅力的なテストツールですが、Seleniumに比べて圧倒的に情報量が少ないため、実装中や運用で問題が発生した場合に解決できないリスクが高いと判断し取りやめました。
自動化トレーニング
毎週、私が講師役となりPython、Sleniumについてトレーニングを行いました。
元々学習意欲は高いメンバーなので、この点については幸運でした。
事前に自動化によりメリット、自信のスキルアップに繋がる点など、コンセンサスは取っておきました ので、トレーニングはスムーズに進みました。
またコードが書けることで自信が付き、開発エンジニアとの距離を近くなることで、コミュニケーションがしやすくなるという副次的効果もありました。
実装
トレーニングで基礎を身に着けたら、設計書をもとに各自実装へと入りました。
Slackに専用のチャットルームを開設し、実装の相談やエラーメッセージのトラブルシューティング、ナレッジの蓄積に大いに役立ちました。
自動化プロジェクトの結果
このテスト自動化プロジェクトは、その後無事にリリースされました。
当初計画したスケジュール通り、運用が開始されPDCAサイクルも回せています。
放置プレイさせるとモチベーションがだた下がりしますので、適度なタイミングで進捗報告会を開きましょう。
お互いの進捗を確認することで、次のような効果を狙っています。
- 「ぼっち感」をなくす
- つまらない所で手詰まりを起こしているメンバーをメンリングする
- 遅れているメンバーには緊張感を与える（お互いを牽制し合うことで、他のメンバーがやってるんだから、自分も頑張ろうとやる気にさせる）
- この自動化プロジェクトは個人作業ではなくチーム目標課題であることを意識させる（課題をクリアできないと、自分たちの部署の評判が落ちる⇒最悪、来年この部署が解体されるゾ！それで本当にみんないいのか！？ 環境の変化を嫌う心理を逆に上手に活用してあげる）
まとめ
とにかくテスト自動化においては、 属人化を防ぐことが成功への道筋になる と考えています。
一人で自動化について画策し、作業していてもメンテナンス出来ず、水泡に帰す 可能性が高いです。
商用サービスの開発は一人は難しいように、テスト自動（コードを書くのでこれも立派な開発作業）化も一人では難しいのは、当たり前ですよね。
テスト自動化を推進する場合は、提案者であるあなた自身が実装の中心プレーヤーになるのは避けましょう。
あなたがマネージャーとして立ち回ることが出来たなら、きっと成功に大きく近づけることでしょう！
『失敗は成功の母』ですから、今回のQiitaアドカレ記事で 多くの皆さんが共有してくださった『貴重な失敗談』 を読み漁り、もう一度自動化にチャレンジしてみてはいかがでしょうか。
