AI自動テストツール Magic Podで、未経験者が自動テストの民主化に挑戦してみた。

ご挨拶

はじめまして。
福岡の会社でE2E自動テストに特化したテストを担当してます、hiroseです。

私は、マニュアルテスト、ブラックボックステストの経験はあるものの、開発の経験や知識知見はなく”自動テスト”に取り組むのは全く初めてでした。

2020/12現在でE2E自動テストに取り組んでおおよそ半年ほど経ったのですが、半年を振り返って見て、発生した問題と取り組んだ対策をまとめました。

本記事はノンコーディングのAIテスト自動化ツールを、自動テストど素人が活用した事例です。
これから自動テストに取り組んでみようという方の参考になれば幸いです。

なお、下手もいっぱい打ちましてそれらも包み隠さずお話します。
より模範的な事例については、自動テスト Advent Calendar 2020の他の方の記事なども是非ご参考にされてください。

E2E自動テストプラットフォームの営業が伝える、自動テスト導入と運用のポイント
【翻訳】あなたのE2Eテストの威力を最大化させる6つの戦略

利用ツール/環境

Magic Podを利用してます。
株式会社TRIDENTが開発したAI自動テストツールで、ノンコーディングで簡単に自動テストを作ることが出来ます。
モバイルもブラウザにも対応してます。
その他、2020/12時点では色々な人の助けをいただいてJenkinsとreg-cli（画像差分比較ツール）を使ってます。

▼2020/5頃

▼2020/12頃　（＝いろんな人の助けをいただいたあと）

何故コーディングできない私が自動テストに取り組むのか

担当サービスは7年間以上にわたり運用されており、度重なるアップデートに伴って膨れ続ける Regression Test にテスト工数が圧迫されていました。加えて、新しい企画の幾つもの複雑なテストが並行して実施されます。

複雑なテストに人間の能力を注力させるために、Regression Test等に自動テストを導入する必要がありました。

ただし、通常のマニュアルテスト担当者というだけでも一般的にも採用に苦労するのに、これに加えコーディングなどの知識も備えた自動テストの経験者もとなると、すぐにはまず見つからないものという前提で考える必要もありました。

更に、せっかく自動テストを導入しても、仮に「その人でしか作成やメンテナンスができない」自動テストだと、展開はもちろん維持も困難です。

昨今、”技術の民主化”という言葉に代表されるように、誰もが「作り手」になり得る便利なツールが登場しています。自動テストのツールも例外でなく、様々なツールがあります。

もし簡単に運用できる自動テストのツールがあれば、私のような未経験者でも挑戦できるのではと考えました。

自動テストを始める前の印象

コーディングが主たる業務になるというイメージでした。
マニュアルテスト担当からするとハードルが高く、自動テストを私たちがするという当事者意識が全くありませんでした。

前提

社内には私たちとは別に、経験を積んだSET等のチームがあり、スタート時にはアドバイス、問題発生時には都度相談をさせていただいてます。身近に相談先がありました。また、当たり前のことかもしれませんが、上長には十二分にサポートをいただいてます。

未経験者が半年自動テストに取り組んでみての振り返り

半年を振り返ると山あり谷ありでした。
問題が発生しては谷が現れ、アドバイスやサポートを仰ぎ対策を取った上で山に向かいます。

1.最初の深い谷

• まず何したらいいか、わからなかった
  コーディング不要といっても”Locator”などの自動テストで必要な用語の学習から必要。
  そもそもサポートは十分にもらっていたが戸惑っていた。

  • 対策 → Scrumを導入した
    一生懸命やってるが成果が出ず、「何がわからないかすらわからない」状態が続いていた。迷走してる最中に「課題を洗い出すフレームワーク」という社内研修でScrumに出会い、課題すら見えてないことに気がつき、それならばとScrumを導入。Scrum自体に最初は戸惑いを感じるが、徐々に慣れ何をすべきかが明確化。

• マニュアルテストの量と内容が壁となった
  サービス開始から7年以上経過してるサービスのため、Regression Testそのものが膨大な量。
  さらに、期待結果が「正常であることを確認する」と記載されてるものが大半。
  正常とはなにか。なにが表示、動作すれば正常かの確認から必要。

  • 対策 → 自動テスト用にテストケースのリライトをした
    自動テスト側でリライトし、その後自動テストを組むという流れで1つずつ導入

• どのテストが自動テストに向いてるかわからなかった
  言葉のまま。Regression Testの中でもどのテストが適してるのか、自動テストを作ったこともないので全くわからない。

  • 対策 → 優先度判断のための「自動化提案シート」を作成した
    ポイント付けにより自動テストの優先度をつけた。以下について3点満点でポイント付け、更に自動化の難易度・容易性を加点し、総合点で優先度を判断する。
    
    1.実行頻度…マニュアルテストをしてる回数
    2.変更可能性…アップデート、デザイン変更の可能性
    3.ヒューマンエラー…「うっかり」や「単調で退屈」など人為的ミスの要因の存在
    4.テスト実施の難易度…マニュアルテスト自体の難易度（初心者でもできる、専門知識がないとできない等）

2.谷を抜けても谷

• 作った自動テストは前後の依存性が高く、壊れやすいものだった
  初めて作成した自動テストは、1テストケースあたり400ステップを超過。
  このほうが実行時間が短く効率が良いのでは、と勘違いした結果。
  最初のステップでFallになれば後続のテストは止まる状態。

  • 対策 → 依存性の低い自動テストにリファクタリングした
    400ステップ→50～70ステップに分解

3.ようやく少し安定し自動テストの数も増えたが課題も

• 自動テストの構築がどういうペースかつかめなかった
  どういう流れで作成できるかが固まっておらず、完成までの目処がぼんやりしており見積もりできない状態。

  • 対策 → 調査、実装、トライアルのサイクルで自動テスト実装というペース感に固定した
    ”調査”でマニュアルテストのテストケースの見直しとリライト、自動テストに向いてるかの再確認。
    ”実装”でMagic Podで自動テストを構築。
    ”トライアル”でマニュアルテストと平行稼働＆ひたすら重複実行。フレイキーな自動テストとならないようにリファクタリングを繰り返し、またマニュアルテスト側と検知の相違がないかを確かめる

• Locatorの存在、表示の有無の機械的な確認だけでは足りないところが出てきた
  Magic Podのテスト結果から画像を見ることはできるが、URLを開いて、見て、テストケースに基づいての判断だとマニュアルテストの手間、見逃しのリスクと変わらない。また、マニュアルテストの場合、期待結果のみを見てるわけでなく導線や画面上にある様々な”異常”を見つけることができるが、機械判定ではそれを求められなかった。

  • 対策 → Jenkins及び画像差分検知を導入
    CIツールとreg-cliというビジュアルリグレッションテストツールで、正解画像と一致するかチェックする仕組みに。
    人間で見逃してしまいそうな違いを炙り出せるように。
    参照…reg-cliとMagic PodでE2Eテスト画像差分チェック

4.上り調子になりきれず

• シェア率の変化に伴いAndroidとIOSのOS変更
  iOS14が登場するとあっという間に利用率が上昇。Androidも利用率の変化が早くこちらも変更の必要が発生。
  ※このころには自動テストの数もそれなりに増えており影響が大きかった

  • 対策 → リファクタリングで新OSに対応
    地道に壊れた箇所を確認しリファクタリング。全部壊れたわけでなかったがそれなりのボリューム。そのころMagic Podには自動修復機能がありましたので、こちらも活用しながらの進行。
    参照…自動修復機能

• 実行用の社内のPC、スマホが安定しない
  PC、スマホ双方のフリーズやランドスケープモードになってしまった、などなど様々な理由でテストが壊れた。
  ※自動テストの数が増えたのでこのころ遭遇率UP

  • 対策 → 社内のPC、スマホ実機に直に確認しにいくしかありませんでした。

5.プラスマイナスゼロで平行線

• 自動テストは順調に増えたが、テスト結果の分析やメンテナンスの時間も増えた
  増加に伴い、結果確認やメンテの時間が増加。ほとんどがLocatorの変更。差を明けての次点でネットワークエラーが多い。以前からあり当時はボリュームも少ないため負担感がなかったが、ボリューム増でこのころには負担が重くなるように。

  • 対策 → 現在も模索中

• デザイン変更
  サービスのデザイン変更で大規模なリファクタリングの必要が発生。

  • 対策 → 自動修復を頼りつつリファクタリングするしかありませんでした。

• マニュアルテスト担当者との微細な認識の違いにリスクを感じはじめた
  自動テストの数の増加に伴い、最初は事細かに連携できていた「自動テストでどこまでみてるか」の認識が微妙にではあるが違うことを感じはじめ、このままだとマニュアルテストと自動テストで重複や抜け漏れが発生するリスクが生まれていた。

  • 対策 → マニュアルテスト担当者に自動テストを実演する
    作成した自動テストを実際にみてもらい、どの場所でどういう確認（Locatorの有無なのか画像差分なのかの細部含め）実演する方式に。何を自動テストで担保するかを明確化。

自動テストを始めた後の印象の変化について

自動テストということを考えたテスト設計やテストケースを考えたり、信頼性を上げるための手直しだったり、あちらこちらとのコミュニケーションが肝要だったり、想像してたよりもずっとコーディング以外の業務が多かったです。

思い返せば、相談先のSETの方も「手を動かすより口を動かすことが増えてくる」と仰ってました。
まさにそのとおりになりつつあります。

しかし、これらの業務はマニュアルテストの経験を活かすことができるところでもあります。
コーディングができないと全くできないもの、という先入観は今はありません。

最後に

自動テスト導入については、自動テスト以外の恩恵も大きかったと感じています。

• 粒度の粗いテストケースを整備できた
• 改めてそのテストが必要なのか設計を考え直した
• マニュアルテストの抜け漏れをみつけた

これらについては、マニュアルテスト担当の方も得意なのではないでしょうか。

私たちも作り手となり、自動テストに取り組む価値は十分にあると思います。
技術の民主化で、あなたも挑戦してみませんか？