テスト自動化プラットフォームAutifyはどのようにAutify自身を 自動テストしているか ソフトウェアテスト自動化カンファレンス2023

Kubo Haruhiko 久保 治彦. Senior QA Manager Microsoft OS開発統括部で SDETとしてのキャリアをスタート。 その後、VMware, UiPath, Cybereasonで日本向け製品のリリース、 QAを担当。 2022年よ りAutifyに1人目のシニア QAマネージャーとして参画し、 Autifyの2製品のQA、リリースを リードしている。 スピーカー Suemura Takuya 末村拓也. Senior Technical Support Engineer / Test Automation Specialist Autifyのテクニカルサポートエンジニアで、自動テストでありがちな「なぜかうごかない」系の問題 のトラブルシュートをする係。 Autify入社前はQAエンジニア、その前は PHPで開発やったり、もっ と前は倉庫でフォークリフト乗り回したりしてました。 JaSST Online実行委員。

アジェンダ

1. Autifyの紹介 2. AutifyのQA体制図 3. AutifyがどのようにAutifyを活用しているか 4. 開発フローへの組み込み 本日の発表の流れ

1. Autifyのご紹介

Webアプリケーションの自動テスト Autify for Web https://autify.com/ja/trial ネイティブアプリケーションの自動テスト Autify for Mobile https://autify.com/ja/mobile アジャイル開発のための、 ソフトウェアテスト自動化プラットフォーム「Autify」

Autify、3つの特長 ノーコードで 誰でも高速に自動テストを 構築・運用できる AIが変化を検知 メンテナンスコストを削減 カスタマーサクセス による伴走

Autifyで簡単にできること 10項目のテストシナリオ作成が わずか1分！ シナリオの編集、コピーも簡単 テストシナリオの作成 マルチOS/ブラウザテスト 画面上で、PC及びモバイルOSのバー ジョン、環境を選択するだけ テストシナリオ・結果の一元管理 テストシナリオもテスト結果もダッシュ ボードで一元管理 スプレッドシートはもう不要

2. Autifyの開発・QA体制について

Autifyの開発・QA体制について (1) Engineering team For Web For Mobile Test Execution SRE Platform Test Management QA ML

Autifyの開発・QA体制について (2) DeveloperがUnitTestもE2Eテストも責任を持って書く・作る 継続的に、そしてタイムリーに開発・テスト・リリースを行うには 開発チーム全員が品質について取り組む必要がある

Autifyの開発・QA体制について (3) ● 以前は・・・ ○ Unitテストは一定のカバレッジを保てていたが E2Eテストの数は頭打ち ○ サービスを止めてしまうようなインシデントの連続発生 ○ 以前修正したはずの問題の再発 ● 課題 ○ 各エンジニアによるE2Eテストの意識のばらつき ○ E2Eテスト作成に関するプロセスが存在しない ○ Bugチケットに対する再発防止策

3. AutifyがどのようにAutifyを活用しているか

Autifyで実施しているE2Eテスト Autifyを利用しているテスト(本番環境からステージング環境へテスト実行) ● 新機能に対するAcceptance Test (Autifyでの自動テスト作成時) ● 新機能リリース後のRegression Test (Acceptance testを利用) ● Bug Fixに対する Regression Test Autify本番環境上にあるE2Eテストシナリオ Autifyステージング環境

Autifyで実施していない自動化されたE2Eテスト Autifyを利用しないE2Eオートメーションテスト ● Autify Recorder (Chrome Extension) を絡めたE2Eテスト ● Autify APIを絡めたE2Eテスト ● Autify Connect (CLIクライアント) を絡めたE2Eテスト

自動テスト以外のテスト(Optional) ● 探索的テスト ○ 新機能開発時にDev/QAがdogfoodingもかねて行う ○ ユーザビリティなどマニュアルテストでしかできない観点も含んだテスト ● BugBash ○ エンジニアリングチーム以外のチームも必要に応じて参加 ○ ユーザビリティやユーザーエクスペリエンスに対してのフィードバックも同時に受け付け

4. 開発フローへの組み込み（具体事例）

テストシナリオの準備 テストシナリオ作成の前に行っていること ● エンドユーザー視点からの新機能に対する要件分析 ○ PM/Dev/QAのトリオで実施 ○ ビジネスルールやロジックをトリオで確認・洗い出し ○ Autify以外のE2Eテストにも使用

例: 抽出されたビジネス要件と対応する振る舞い 「ユーザーの権限を管理したい」という新機能に対する要件の洗い出し

テストシナリオの作成とその役割分担 ● Developer ○ Autifyでテストシナリオの作成(要件洗い出しで抽出されたステップのレコーディング) ○ 作成したテストの結果確認 (Acceptance test) ● Developer / QA ○ 他のテストと並列実行したときに問題がないか？(テストの独立性の確認) ○ 複数回連続実行しても問題ないか？ (テストに動的な要素検証等が含まれていないか等) ● QA ○ 共有リソース (ステップグループやJSスニペット)などの作成 ○ シナリオのレビュー (リクエストベース) ○ テストプラン・パイプラインへの追加・パイプライン更新

テストシナリオの作成におけるプロセス管理 ● 各ユーザーストーリーの開発チケットに は自動的にE2Eテスト開発のサブタス ク(チケット)が作成される ● E2Eテスト作成完了までは原則開発チ ケットを完了できない仕組み

Autifyで作成されたテストシナリオの実行 ● Acceptance Test ○ ステージング環境で作成・実行 ● Regression Test ○ 日々のリリースパイプラインの中で実行 ○ 複数のテストPlanに分けて実行 ○ 夜間に翌日のリリースブランチが作成され、自動でステージング環境へ Deploy・テスト実行 ○ Deploy担当のEngineer(持ち回り)が翌朝テスト結果を確認、本番へリリース・ Deploy

Autifyで作成されたテストシナリオの実行 ● PRマージ前にE2Eテスト(任意)

テストシナリオのメンテナンス・管理 ● ラベルと説明によるテストシナリオの管理 ○ ラベル ■ 担当チーム名 ■ 機能名・機能カテゴリ名 ■ テスト実行時の依存関係・条件等 (もしあれば) ○ 説明 ■ E2Eテスト作成チケットのリンク (リンクからUserStoryのチケットへ辿り着ける ) ● テスト失敗時はEngineeringチームの通知専用slack チャンネルに通知される ○ Slack通知には担当チームのラベルが表示されるので、原則担当チームが確認・調査を行う ○ 必要に応じてQAも担当チームと一緒に確認を行う

Bugに対するアクション ● Bugチケットに対してもE2Eテスト開発のサブタスク(チケット)が作成される ○ Regression issueを防ぐため ○ 必ずしもE2Eテストである必要はないが、今後のリファクタリング等を見据えて ○ E2Eテストできないものもかなり存在する

QAチームがモニターしている指標 ● デプロイの頻度と障害発生率をトラック(DORAメトリクス) ● Autifyで発見できたBug数・比率 ● Flakyなテスト ○ テストシナリオに変更を加えていないが、再度実行するとパスしたテストシナリオの洗い出し ● 自動化されたE2Eテストのカバレッジ ○ ユーザーストーリーに対してE2Eテストでカバーできているか？

● プロセス導入以降、AutifyでのE2Eテストシナリオが増加 ● 自社製品を使うことにより、製品改善のリクエストも開発チームから発信 Autifyで管理しているE2Eテストシナリオ数の推移 2022 Jan 2023 Jan Now For Web 83 243 489 For Mobile 63 130 Product C 0 16

今後の予定および目標 ● PRマージ前のE2Eテスト実行 ○ PRマージ毎にリリース可能になる ○ 現時点ではステージング環境の制約により難易度高 ● 変更点に応じたE2Eテスト実行 ○ 機能は増え続けるのでテストの総量も増えていくが、実行時間は最小限ですむ ● どの環境に対しても実行できるテストシナリオの作成 ○ 開発者のローカル環境でも、ステージング環境でも、どこでも一貫したテスト実行が可 能となる

まとめ ● リリースの頻度を変えずにE2Eテストを効果的に追加できた ● 開発チームが顧客目線で製品を使うことで、開発チームからのフィー ドバックが増えた ● テスト自動化フレームワークを開発プロセスに組み込んだが、典型的 な落とし穴にハマってしまった

ご清聴いただきありがとうございました！