ローコードなE2Eテストについて調べてみる

色々ある
https://www.qbook.jp/column/20201127_1068.html

説明するのにはいい記事
https://yoshikiito.net/blog/archives/ai-testautomation-tool-kanzen/
統計的なレポートを含んだ記事。
https://blog.autify.com/ja/state-of-devops-testing

https://nemorine.hateblo.jp/entry/2021/01/22/071200

Q. QAが自動化するのとエンジニアが自動化するのとどちらがいいでしょうか？
ユニットはエンジニア、E2EはQAがいいかも。
理想の形が組織ごとにある。
人数比も影響ありそう。

任せれるなら、そっちがいいかな
なので、ノーコードのSaaSは相性が良いと思う
ベンダーロックインは悩ましいな

Cypressのスクリプトをノーコードで作成＆オートヒーリングしてExportできると嬉しい
テスト作成環境（IDE）とCI環境を提供してくれるプランがあればありがたいが
各サービスのWebDriverの足回りの部分はSeleniumなんだろうか？ :thinking_face:
ノーコードだけれども、完全ノーコードだとアレかな
APIのルーティングやモックテストへの切替ができるとベターだと思う
SaaSだけれども社内テスト環境に対しても動かせるんだよね？
テスト作成（キャプチャ）はローカル実行なはずだから、流石に大丈夫だとは思うんだけれども

https://daipresents.com/2020/test-automation-question/

機能テストもやればできますが、このレベルをいきなり自動化するかどうかは企業によってまちまちです

導入する流れとしては

1. リグレッションテスト
2. 機能テスト

の順か

https://daipresents.com/2020/mabl-test-by-mabl/

そもそも、全部を自動でテストする気がない
そもそも、リグレッションを厚くするという気もない
そもそも、マニュアルテストを自動化するとうまくいかない

最初理解ができなかったけれど

https://daipresents.com/2020/mabl-test-by-mabl/

今あるも を自動化していくよりも、自動化ケースを先に作り上げ 、そこで保証できない部分を、手動ケース として追加していくほうが効率がよい。
つまり、 日々、更新されていくマニュアルケースを自動化で追いかけるよりも、自動化ファーストで作られたケースを元に、マニュアルケースを考えるという流れになるということ。

これは凄い腹落ちした。

マニュアルテスト＝手動テスト

自動化するコストとの見合いか
２回以上リグレッションを手動で行うなら自動化したほうが良いという判断になるかな

自動化しやすく、手動テストの数が多いものを自動化するのは投資効果が高い

AIができて全て人々のお仕事がなくなるということはなくて、人間様のお仕事は残るとｗ
ロボットをつくるロボットがでてきたら、状況は変わると思うけれども
まだまだ弱いAIだし（今回はセレクターをいい塩梅に空気を読んでくれるだけ）、適材適所！

https://daipresents.com/2020/10-rules-for-writing-automated-tests/

Rule 1: 優先順位付けする

もっとも大切なユーザフローを洗い出しましょう。

ふむ。
そういえば各画面の利用頻度を調べて欲しいというのを思い出したぞｗ

まあコケてしまった場合のビジネスインパクトが大きい一筆書きのリグレッションテストを書くと良いのだろうな。
一筆書きが良いかの議論はあるけれど。。
マイクロサービスなので、サービス間のデータ連携も見たいとは思うけれども実装の難易度はあがるかも

Rule 6: 大切な場所にバリデーションを追加する

アクションが失敗した場合に、チェックポイントとしてふさわしい場所にバリデーションを追加するのも大切です

ここらへんは、SPAだとAPI呼び出しのバリデーションを使うといい感じになる
Cypressでは、コンポーネント描画とAPI呼び出しのバリデーションをアクション毎に入れて、次のアクションを実行すると安定的にステップが進んでいった印象
ノーコードの場合は、コンポーネント描画のバリデーションはできそうだけれどもAPIはやれるのだろうか？
DOMの変化だけしか見えないとなると少し不安だなー
SPAだと非同期処理前提なので、ここは個人的には譲れないと思うがどうだろうか？
AIがAPIのリクエストも記憶してくれて、いい感じに次のステップに移ってくれるのだろうか？
またエンジニアの視点ではAPIのリクエスト内容はバリデーションしたいかなーという欲が出てくるというのもある

Rule 7: 安定性を改善するためにスリープを入れない

Rule6をしっかり行っていれば、基本スリープは必要ない

条件付きで待つステップを使えば解決できます。

一般的な用語・機能なのか？わからない。
アクションの前のバリデーションを行うのと違いがあるのかな？
Cypressとかでもそういう概念があったりする？

AIがキャプチャした際のDOM変化やネットワークリクエストをいい感じにバリデーションするのではなく、エラーが発生した際に後ろ向きにスリープを入れる調整をする世界観だといやだな。

バリデーションを入れた時点で、DOMが期待値通りに変わらなければタイムアウトまで待ってエラーになる。逆に時間内に期待値通りになれば次のステップに進むという認識なので、あえて意識しなくても良さそう。
ツールによって違うのかな？

Rule 8: 抽象化は最低2段階ぐらいにする

言いたいことの理解が追いつかない

PageObjectデザインパターンとは？

https://note.com/shift_tech/n/n46530d28f935

PageObjectデザインパターンとは、アプリケーションの画面を１つのオブジェクトとしてとらえるデザインパターンの１種のことです

サンプルコードを見た感じ画面の振る舞いを定義して共通化させる手法っぽい？

PageObjectデザインパターンのメリット
この例のようにテストコードをページとシナリオの二層に分けることで、2つのメリットが得られます。

あってそう。

1つは、メソッドチェーンを使うことでシナリオの可読性が上がる点です。

メソッドチェーンで書けるようにオブジェクト化するというとか。
共通化する際のデザインパターンとして良さそう。

元の記事にもどって読み返してみる。

ビジネスロジックと操作の2段階に切り分けるのが推奨

fm-
やっぱり理解が難しい。
共通化処理の書き方の注意点だと思うけれども、抽象化しすぎると良くないぞということかな？
メソッドチェーンは操作をさせていて、シナリオはメソッドチェーンで書いて表現しているけれども。。
シナリオをまとめたシナリオを書くのは良くないぞということで一旦留めておこう。

ノーコードツールでPageObjectデザインパターンが使えるのかは？？

Rule 9: 条件分岐を減らす

テストコードで条件分岐をさせるというのが馴染みがないが、どういうことだろう？
データプロバイダーでインプットと期待値のセットで扱うと思うけれど、テストコードを分岐させる必要がる場合はテストをわけるかな
大体テストの粒度が大きすぎるのが問題だし、そうした場合にテスト観点もコードから読みづらくなるので、そもそもやらない

ポップアップする部分を止めてしまう

これ対策なのだろうか？
SPAだと全画面ポップアップな感じだけれども。
ダイアログ内で条件分岐があるケースということなのかな？

Rule 10: 独立した、分離されたテストを書く

特に異論はございません。という感じではある。
ただリグレッションでシナリオテストっぽいことを書きたい欲があるけれど、それは良くないってことかな？
単体テストは機能テストとの棲み分けでE2Eでのカバー範囲をどう捉えるか？
自動化させる・させないという判断がやっぱり難しい印象

まとめ

すばやく という言葉が4回も言われているので、コスト削減が主ではないというのが伝わりましたｗ
そこを見誤ると、導入に失敗しそう。

自分のプロダクトで今一番刺さるワードとしては以下の2点かなー

• 素早くバグ検知できる
• リグレッションの期間を短くできて素早くリリースできる

https://www.creativebloq.com/features/the-5-best-visual-regression-testing-tools

しらない知らないツールがいっぱいあるぞｗ
カオスマップ作れそうｗ

視覚的回帰テスト

という用語でいいのかな？

https://www.thoughtworks.com/radar/tools/cypress

"post-Selenium" web UI testing tools

大分日本語の情報も集まってきているし、ドキュメントもしっかりしているのでベースとしては良い
実際に触ってみた印象として

• 環境構築楽
• 書き味が良い

https://daipresents.com/2020/mabl-in-a-nutshell/

スクリーンキャプチャがいっぱいあって助かる
イメージが付きやすい

mablは実行回数ベースの料金システム

実行環境もセットでサービスしている感じ
社内サーバーはIP制限しているんだけれども、CI上（この場合はmablの実行環境といったほうがいいのかな？）にコンテナを立てれるのかな？
キャプチャのイメージをみると、テスト対象自体は別っぽい
テストの依存性をなくす意味ではCI上にあって独立していた方が望ましいと思うけれど、どうなんだろう？
逆に大変という面もあるけれど
テスト実行時だけコンテナ立ち上げてコスト下げたいという面もある
CI向けに環境一式を全部立ち上げておく必要があるかな？イベントフックして環境構築させれるような余地とかはあるのかな？
常時立ち上げていかないと駄目？
ジョブを複数起動した際にテスト失敗しそうな感じがするが。。

https://blog.autify.com/ja/why-id-should-not-be-used

文言を用いたロケーティング

id, classやtagなどのCSS由来の属性や、変わるかもしれない要素内のテキスト(textContent)をロケータとして使わず、 data-* 属性を定義するべきと書かれています。

そうした方が良いのは理解しているが、実際にあとから付けるとなると大変だな
フレームワーク的につけれないやつも出てくる

ここらへんを改善する為の手段としてAIはいいと思うけれど、AIは data-* を優先的に使ってくれるのだろうか？

おまけ2: Autifyにおけるロケータの概念

Autifyでは、テストシナリオのレコーディングの際に、要素が持つ様々な属性を収集します。その中には、id, class, name, タグなどのメタ情報の他に、文言や座標などユーザーから見えている情報も含んでいます。 そして、テストコードを実行する際に、画面上の要素それぞれについてこれらの属性との一致度を測定し、もっとも強く一致する要素を採用します。

ほえー。
肝心な data-* 属性は書いてない

本記事で紹介したような、文言やdata-* 属性でのロケーティングから更に一歩進んで、idやclassのみならず文言などについてもプロダクトコードをロックしません。

まあその通りなんだけれども、既にプロダクトに埋め込まれていたら、そっちを使うとかを期待していたｗ

ミートアップでの内容
https://note.com/suwash/n/nc4747fdc513b

各サービスの推しがわかるかも
でも大体方向性は同じ

https://daipresents.com/2019/testim/

APIのバリデーションもできるので、APIテストとしても使えそう。

Validate APIがある！

保存されるたびに変更履歴をつけられる点です。右上に「Fork」みたいなボタンもあるので、ケースをGitのようにバージョン管理できるようです。

よき！
他のサービスもそうなんだけれども、ケース管理ってどうなっているんだろう？

作成したテストをローカルのブラウザでも実行できるところ。

これもいいな
mablもCLI実行できるとのこと

https://daipresents.com/2021/mabl-cli-clicircleci/

mablはローカル実行の場合、実行回数無制限なので、基本料金さえ払えば、どれだけ実行しても追加料金はかかりません。たとえば、ローカルにJenkinsを立てて、ぐりぐりmabl CLI実行しまくっても、料金は変わりません。

すげー
これは大きなメリットだな
CI側でテスト環境の構築もセットで行える（はず）

https://daipresents.com/2021/test-automation-cost/

daipresentsさんの信者になってきたｗ
良い記事

イニシャル： 初期自動テストの作成コスト

確かに初期構築には時間がかかりそうだ。
CLI Runner使った場合だとどこまでの範囲が楽にできるのだろう？
レポートもどこかにアップしたいし、色々考える所はあるよね

初期構築とテストケースの作成の時間が圧縮できるのであれば、時間をお金で買う感じで投資するのはありだな
メンテコストもわかる。

https://daipresents.com/2021/test-automation-end/

各スライドがすごく為になるのでメモ

あなたが欲しいものはなんですか？

が凄い刺さった

自己解決できるチームづくりか。。
そこまで一気にいけなさそうだから、もう少し考える

スケール可能になるには？を考える

他にも書きたいことあるけれど、元々の趣旨から外れてポエムになるので一旦割愛

https://daipresents.com/2020/mabl-api-requests-response-validation/

mablでAPIを呼び出せます。つまり、ユーザといったテストデータをAPIで作成するだけでなく、とあるデータのステータスをAPI経由で変更させたり、テストのためのデータ操作まで可能になります。

うぉおお。そういう方法があったか。
セットアップ時にAPI実行してテストデータを作る。テストが終わった後に戻すというのもできそう
他のE2Eテストのフレームワークでも活用できそうなテクニック

APIのレスポンスも取り出して変数に設定できます

これも重要だな
テストデータをDB管理させることも出来るし
時間によって動作が変わるテストもAPIレスポンスを見ることで制御できる

Cypressとかでも出来るのかな？テスト以外でAPIリクエストすることって。
まあnodeだからaxios使って出来るか

ここらへんの変数埋め込み部分は使い勝手的にどうなんだろう？
うまく共通化してノーコードで作成するテストケースからサクッと呼び出せるとありがたいけれど。

https://daipresents.com/2020/mabl-branches-and-version-control/

ブランチ管理自体はmabl側で行われているのだろうか？
テストケースがファイルで見れてgitでバージョン管理できるわけではないよね？
テストコードレビューができるといいのだろうけれど。。
ここらへんは、、複数人が使う様になるとブランチワークとか気にしないといけない所かな
まあどんなツールでも必要だけれども。。
ブランチ実行できるのと、revertできるだけでも安心感はある

https://daipresents.com/2020/mabl-visual-testing/

Visual changeの検知

mablは約10回ぐらいのテスト実行によって、ビジュアルベースラインモデルを構築していきます。

キャプチャでハイライトされているのが、自動で検知している差分ってこと？
すごい便利。未来を感じた。
OSSだとキャプチャとっても、エラーになった際のキャプチャしか見ないよ！という感じになる絵図が用意に想像できるけれども
流石SaaSの本領発揮という所だなー

共通コンポーネント変えてデザイン崩れが発生しないか？というのが結構心理的不安があって億劫になっているのでこれは大変ありがたい

https://daipresents.com/2020/mabl-best-practice/

11. テスト環境をセキュアにしましょう

Basic認証サポート＆botのIPアドレス公開されているのでなんとかなりそう

https://daipresents.com/2020/mabl-download-assertions/

PDFであればmablが自動でビューアを開いて中身のチェックが可能

PDFもビジュアルテストしてくれる？
画像変換してできそうではあるけれど

https://daipresents.com/2019/mabl/

ファーストインプレな記事
用語集あり、実行イメージはなんとなくわくと思う

https://speakerdeck.com/daipresents/qazi-dong-hua-huratutohuomukashi-xian-surudevtestops-what-is-the-devtestops-and-qa-automation-platform

プラットフォーム活用

妄想も入っているけれど、こんな流れか？

1. アプリ自動ビルド
   テスト対象作成
   →　アプリじゃなくてもPR merge時に環境一式を作成するようにCI実行
   　イメージ作成してコンテナ起動
2. テスト作成基盤
   テストデータ作成
   →　テスト用APIを用意して、実行環境のデータベースにデータ登録（seeed）をする
   　　テストプラットフォーム側にもAPIがあれば併せてシードのデータを含めたテストパターンデータも渡す
3. テスト実行基盤
   テスト実行
   →　プラットフォームをそのまま使うも良し、CLIがあればCI上でビルドフローにそのまま組み込んで実行
   　プラットフォームを使う場合はAPI呼び出しになる
4. テスト結果基盤
   実行動画＆テスト結果保存
   →　ここはテスト実行のツールが良しなにやってくれる想定

サービス比較

Autify。日本で勢いがあるらしい
ケース管理、ツール連携気になる

概ねここに記載している3つがメジャー処か

アクションプラン

現状は自社QA.（+自社エンジニア）か
プラットフォーム利用だと自社エンジニアになっているけれど、自社QAでも問題ないよね？
QAを撲滅したいわけではない

責任の分断

組織論的になっちゃうよね

UTからE2Eレベルの確認すべき

はい。耳が痛いです
責任の分断をさせない為にエンジニアがE2Eテストを書くべきなのか？

QAの役割って？？
エンジニアが書くならノーコードでなくてもいい？

https://montecampo.co.jp/5329.html

価格面での比較

他店のサービスの20%〜30%の価格帯

安い！

ローカル実行については無制限

バグでは？ｗ
結果レポートのホスティングはあると思うけれど。
CLI実行した場合とで機能差がどっかにありそう（ないと嬉しいなぁ

https://blog.asial.co.jp/1639

AIを使ったE2Eテストの隆起を感じさせる記事
2019年ぐらいからトレンドが始まってきているんだな

Mablをより“賢く”したのがFunctionizeです

気になり

2021年だともっと雨後の筍のように一杯サービス増えているんだろうなｗ

Functionizeのテストケースは自然言語、すなわち単なる文章です

すげー

AIテストツールのレベル

自動運転のAIと同じくレベル設定がされるのかー
今はレベル2だと思う
レベル3ができて来たらブレーク・スルーな気がする
Functionizeが片足突っ込んでいるみたいだけれども、どこまでなのか

強いAIができつつあるというワクワクするお話
QAを撲滅できる夢を見れそうｗ

その前にエンジニアがオワコンになりそうだけれども

https://trends.google.co.jp/trends/explore?q=Mabl,Autify,Testism,Functionize

トレンドを見てみる

日本では検索ボリュームが小さすぎて比較しづらかったのでワールドワイドで比較

DMMさんでQA主体で利用している自動E2Eテストツール
https://docs.eggplantsoftware.com/ja/eggplant-documentation-home.htm