Open38

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

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://zenn.dev/link/comments/eb90a8fc347c23

こちらを読み込んでから戻ってきた

Q. E2E自動化サービスにその移行をサポートする機能はありますか?

mablだとWebDriverで書かれたテストをマイグレーションしてくれる機能があります。SeleniumIDE形式にエクスポートもできます。

おー。最悪Exportできるならベンダーロックインは回避できそう。
ただSeleniumかー
Cypressが良かったな

Q. ウォーターフォール型開発でも利用可能ですか?

厳密にはWFでやっている感じではないけれどQA的にはWFに近いスタンスをもっている

ポイントは、WFなどのプロセスと言うより「さいごにまとめてテストする場合」だと、E2E自動化サービスなどの効果は低くなりがちな点です。

まじかー

でもマイクロサービスで、五月雨に機能追加しているからリグレッションが後回しになりがち
Issue毎に機能テストを手動でやっているけれど、リグレッションの観点は漏れがちだし
他PRがマージされた後に再テストしなくて大丈夫?コレ?という心理的不安がつきまとう
だからリグレッションが自動化できて、都度回せると

  • バグが早期検知できる
  • 機能テストが全て終わってから膨大なリグレッションテストを数日かけてやるリードタイムがなくなる

というメリットが出てくるなと

Q. E2E自動化サービスをパフォーマンス(性能)テストに利用していますか?

へーという感じ
パフォーマンスまで回ってないな。APMを入れるということもできてない
本番環境で定期的に回してレスポンス悪化とか見る感じか

監視ツールのDatadogもブラウザテスト

ページ監視だけだったと思う

Q. E2E自動化サービス以外にテストツールを併用しているか

単体テストはやっている前提

QAエンジニアが疎通確認でPostmanとかを使っているか

つよつよだw

Q. Autifyやmabl・・・いったいどれがおすすめ?

これが知りたくて、いまこのスクラップに書きなぐっていますw

自分の課題解決に見合った、気に入った道具を使えばいいと思います。

探す旅に出かけますw

他の記事もすごく丁寧にかかれているので後でスクラップする

E2EフレームワークCypressが定番になったようです

良さそうな印象は持っている
ただ、QA側でコード書いてというのは難しいのでSaaSでいい感じにできないか?というモチベーションで調べています。
SaaSで内部実装がCypressでExportできれば、最悪エンジニアがコードメンテナンスを引き継げるといいなぁという印象

Visual regression testing tools

あとで調べる

ちょっと違うけれどもマニュアル作成もあるので、キャプチャも取れるといいかなという気持ちがある
そういえば動画も撮っていたな。。

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

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

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

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

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

これは凄い腹落ちした。

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

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

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

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

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

Rule 1: 優先順位付けする

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

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

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

Rule 2: 削減!リサイクル!再利用!

ユーザシナリオをシンプルに、ひとつの目的だけ持つように、最小の単位でブレークダウンします。

さっそく否定されていたw

RSpecのShared Exampleみたいに、パーツ化するのが大事ということか。
Cypressでも拡張メソッドを用意するよね

Rule 3: テストはひとつの目的だけ持つ構成にする

テストケースをみてぱっと理解できるというのは重要だよね。
メンテナンスもしやすいし

理想をいうならば、テストしている機能や依存関係に問題があった場合に、失敗するテストを最低限におさえるべきでしょう。

E2Eでも依存性排除するほうがいいのか。。
依存してしまってなんぼな感じだと思っていた。
場合によっては依存させないようにモック処理を入れたほうが良いということかな?
でもデータ書き換えが発生してしまうし、なんならより実際に近い挙動にしたいのでAPI実行はさせたいんだけれども。。
CI流す際にseederもセットで動かして、テストケース毎にリセットさせることを想定していたけれどどうなんだろう? :thinking_face:
単体テストみたいにトランザクション張って、ロールバックできないから簡単ではないよね。
まだ答えはない。

並列化によって同時に並行実行できるため

あー。確かに。それはありがたい。
でもますます、他のテストの実行結果に影響しないように実装しないといけないので難しくないかな?
並列実行する際に、その分でコンテナ一式を立ち上げるように環境作らないといけないってこと?
できなくはないと思うけれど。
マイクロサービスだと環境の構築とデータの準備で頭が痛くなる。。

作ったフローを他のテストで再利用していても、修正は簡単にできるはずです。

テストの再利用のイメージが掴みきれていないな
結構コピペな部分が出てきてしまうけれど

最適化を急ぐとろくな結果になりません

必要に感じたらリファクタリングすれば良いってことかな?
ノーコードツールの場合は、フローを共通化させる機能はあるのだろうか?

E2Eテストでコーディングするスタイルは少しは理解できるけれど、ノーコードとなるとリファクタリングできなくて詰む感じにならないか不安になってきた。
ここらへんは、QA任せにすると厳しいからガイドラインを作る等、エンジニアのバックアップは必要そうだな。

ただし、データセットが更新された場合、予想とは違ったシナリオになるはずです(別のユーザが違った方法でアプリを操作するのと同じように)

そうそうこれ。

ランダムなユーザ名を選択し、変数usernameに設定する

テストケースのパラメータとしてはそうなんだけれども
じゃあこのログインアカウントのセットアップをどう準備させるの?という所が謎。
QAじゃデータセットを作るの難しいよね?
マルチテナントなシステムを想定した場合に、テナント作ってテストケース分のデータセットを用意していい感じにテストデータを使ってくれというスタイルがいいのかな?

Rule 4: テストの初期状態には一貫性をもたせる

テスト実行時における共通かつ最大のメンテナンス問題は、初期状態の一貫性を保証することです。

わかりみ

テスト実行時に毎回ユーザを新規作成する

ですよねーw

誰かが利用するテスト環境とは別に、テスト自動化用に専用環境を用意する

CIでジョブ毎に環境一式立ち上げる所存
CIないと辛いのは目に見えている

並列テストする場合も、いい感じにわけないといけないな
GitHub Actionsだったら、Matrixにすればそれぞれ独立したコンテナになるからそれが良さそう
テストsuiteをmatrixにする感じ

テストスートの実行前にアプリとデータを初期化する。有名所でいうとfixturesのような方法がある

E2Eテストでのfixturesはどう管理すればいいん?
必要最小限なデータ。。アカウント作成だけしておいて後はE2Eテストのフローで必要なデータを作っていくってこと?
そのフロー自体はテストではなくて、セットアップという位置づけなの?
それ自体はほぼテストじゃん!ってなって、テストが他のテストに依存しちゃう感じだけど良いの?という疑問が残り続ける。
セットアップで失敗したらそのテスト自体も失敗するし。。

Rule 5: シンプルなステップを使って複雑なテストを書く

部品はすでにテストされて様々な場所で使われているため高品質のはずです。これらの部品を使って複雑なテストを作り失敗した場合は、部品の結合の問題だけにしぼりこめます

なるほど

まずはシンプルなテストから順番に実行されるようにしましょう。テストスイートを実行するときに、複雑なテストなどで何か問題があった場合、すぐに問題にきがつけるはずです。

テストというかステップの依存関係のないものから、順に実行させていく感じか。
やっぱり一筆書きのステップじゃんという思いが強くなるなw
テストが失敗した際にCI自体を止めるか?完走させるかは悩むな。
またこのルールを守ると並行実行させるのは良くないということになるが。

QAがここらへんのテストの実行順を意識して書けるのだろうか?
データフローを意識して書いてくれっていうオーダーで伝わるだろうか?
QAがテスト書いて、failになった場合にエンジニアがどこで失敗したか?原因を切り分けるスタイルが良いのかな?
E2Eテストは壊れがち問題(不定期に落ちる)があるので切り分け大変というイメージ
ロボットさまがどこまで、サポートしてくれるかで変わってくるんだろうけれど。。
AIが登録されているステップをみて実行順も決めてくれると素敵すぎるが、まあそこまでは流石にやってくれないだろうなー

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デザインパターンとは、アプリケーションの画面を1つのオブジェクトとしてとらえるデザインパターンの1種のことです

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

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

あってそう。

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

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

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

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

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

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

Rule 9: 条件分岐を減らす

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

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

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

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

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

まとめ

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

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

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

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のみならず文言などについてもプロダクトコードをロックしません。

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

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さんの信者になってきたw
良い記事

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

確かに初期構築には時間がかかりそうだ。
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://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%の価格帯

安い!

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

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

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

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

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

気になり

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

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

すげー

AIテストツールのレベル

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

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

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

ログインするとコメントできます