Fujihara)毎日200シナリオ以上、月に1万シナリオ以上、月に1万ステップ以上を実行して安定化ができてきた経験をどこでも実現できるように、これまでの知見・経験をまとめてみようとおもいます。mablのようなサービスを使って、安定したE2Eを作るときの参考になれば。QA自動化サービスとは何か?ここではmablをベースにまとめますが、ノーコードでありキャプチャ&リプレイ形式でテスト実行できるツールであれば、似たような作りになっているはずなので参考になるかなーと思います。mablの基本的な使い方については以下を参考にどうぞ。観点はひとつひとつのテストの中に、観点(確認したいこと)が複数あった場合、1つ目の観点でテストが失敗した場合に、2つ目の観点はテストされません。よって、観点はひとつにするべきです。観点の依存は良くないけれど、以下の例のようにデータの登録と削除は、1ケースに詰め込んでもいいでしょう。APIでデータ作成ができるなら、登録と削除も分割できます。小さく作るmablは並列で繰り返しやるのが得意なので、テストは小さく作りましょう。具体的には、目標実行時間を決めて、時間内に終わるように作ります。僕の場合は5分以内を目標にしています。逆に、まず作ってみて、長いテストから可能な限り分割する方法もあります。ユーザ作成のステップを毎回30秒で実行しているとします。ユーザ作成するケース数」で合計コストがでます。これが大きいと感じるなら、30秒を短縮する方法を考えましょう。APIを使ったテストデータ作成ができれば、よりテストを小さく作れるはずです。表示が変わるごとにアサートする自動テストは目が見えません。今どのページにいるかを自動テストは理解できません。画面遷移した場合は、遷移が正常に行われ期待するページが表示されることを毎回確認しなければなりません。確認方法はそのページ特有の見出しであったり、「登録しました」といったのメッセージを利用できます。モーダルウィンドウ(HTMLによって表現したメッセージボックス)が表示されるときも、表示されている文言を確認して、モーダルの表示確認を行います。いうステップが利用でき、3〜5秒の設定が安定します。「特定の見出しが表示されるまで待つ」がベストでしょう。Self:繰り返しを避ける)を適用すべきです。2回同じことをするならそれは部品(mablだとFlow)にして再利用しましょう。画面左にメニューがあるアプリの場合、それぞれのメニューに合わせて遷移用部品を作ります。最終的に、自動テストのほとんどが部品で構成されるようになり、ひとつひとつの部品の品質を高めることで、よりテスト全体が安定していきます。テストごとにユニークな文字列を活用するデータを登録したり修正したり。テストで何かを入力したいときは、テストごとにユニークな文字列を入力しましょう。これによって、問題発生時にどのテストなのか特定しやすくなるはずです。いった書き方でアルファベットと数字の混合文字列10桁を簡単に作成できます。いったテストのIDとなる文字列をテストのはじめに部品として読み込むのも手です。大切なものだけAssertion自動テストは目が見えません。テストの目となるものがAssertion(確認項目)です。一つの画面でいろいろな確認をしたくなると思いますが、すべてを確認するのは大変です。よって、このテストで本当に確認したいことを確認しましょう。観点があるのであればその観点に紐づくAssertionを入れましょう。「せっかくだからついでに・・・」とAssertionを増やすと、観点が変わってしまいます。いう場合は、新しく増やしたい観点でケースを作ります。スリープは最大限に短くWebアプリではタイミングでテスト失敗する場合が多いので、自動テストにスリープを入れるケースもあります。入れる場合は「〜が表示されるまで5秒だけ待つ(前述のWaitUntilなど)」という方法を選択しましょう。mablでは、AssertionやXpathによる検索時の待ち時間を設定できます。デフォルトが長く感じる場合は、短く設定するのも手です。実行時間はスリープの長さや回数に依存します。Webアプリではデータのローディング時間等の影響を受けてしまうため、秒数は限りなくする必要があります。最近のテスト自動化サービスは、プログラミング言語と同じく条件分岐、ループが利用できます。便利ですが使いすぎは危険です。条件分岐は、データ編集系のテストで有効活用できます。「もしもデータがAAAAならBBBBを入れる」または「BBBBならAAAAを入れる」といった分岐があれば、テスト失敗しても、いちいちデータをAAAAやBBBBといった直前の状態ににもどさなくてよくなり、再実行可能なテストになります。ループは基本的にあまり使いません。連続登録や連続削除など、観点をしぼってじっこうすると良いと思います。変数名はキャメルケースデータを使いまわしたい場合は変数を活用できます。変数名も色々試行錯誤したのですが、mablの場合はキャメルケース(userNameとか)がしっくりする気がしています。healと呼ばれる)。内部的には、現在や過去のDOM構造や、テキスト情報から要素を推測しているのですが、JSによるデータ作成ステップや、Xpathを使った要素特定をすると、この恩恵を受けられなくなります。細かいところに手が届くのはいいけど、活用しすぎるとテストの柔軟性を失うので注意しましょう。Xpathを使わざるを得ない場合は、できるだけ柔軟なXpath(containsを使うなど)を検討します。読むことをおすすめします。Healが有効的に動く可能性も高まります。コメントやアノテーションを入れるテスト名、テストの説明だけで、そのテストの意味を語り尽くすのは難しいはずです。相手に伝わるテストを作るために、テストの間にコメントやアノテーションを入れましょう。Xpathやスリープはそれだけでは意図が伝わりません。コメントは、H1、H2・・・といった表記が可能です。全体の流れはH1などルールを決めるといいです。僕の場合は、全体の流れをH1、H1より小さい処理はH2、Flowの中はH2を使う・・・といったルールにしています。名前やラベルで整理するぱっと見ただけでどういうテストかわかるように、プラン名・テスト名を工夫したり、ラベルを活用しましょう。mablではカテゴリがなく、ラベルで管理する必要があります。プラン名はテストケースををまとめるテストスイートにふさわしい名前にするべきでしょう。実行時間を書いて実行順に並べ替えるのも便利です。ユーザ登録(有料ユーザ・無料ユーザ・ゲストユーザ)ラベルはプランをさらに絞り込むためのものです。Slack通知単位や実行時のテスト指定で使います。テストの種類や重要度もラベルとして使えます。EC、CRUD、重要度A、リグレッション)上記のようにしておくと、「重要度Aを実行したい」「ECサービスに関わるテストを実行したい」「リグレッションを実行したい」というユースケースに活用できます。作りかけのものは「WIP」をつけてもいいかもしれません。テストを使い回す何回もテスト実行することで、自動テストの恩恵を受けられます。特定の期間や特定のタイミングで実行するだけではなく、たとえば、DEV・STG・本番環境ごとにテストを再利用する方法もあります。アプリケーションやシステムの環境によると思いますが、環境が変わっても動作するテストを作れると強みになります。最近のトレンドはリリース後のテスト自動化です。本番テストまで使い回すことで、自動テストの恩恵を最大限に受けられます。実行タイミングを設計する自動テストは実行すればするほどその恩恵が大きくなります。テストの実行回数が増えるに比例して、テストの確認コストが増えます。テストが安定していない場合は、より増えます。mablのような月額実行回数で金額が決まるサービスの場合、実行回数が増えると運用コスト(サービス利用コスト)も増えます。実行回数が少なすぎると、テスト結果というフィードバックを受けるタイミングも遅くなるため、どうバランスを取るかの設計が必要です。実行タイミングは大きく、以下の種類にわけられます。定期チェックによるアプリのヘルスチェックとしてこれらを考慮して適切な実行タイミングを設計しましょう。リグレッションテストの整備からはじめるのがおすすめです。mablをデリバリパイプラインに統合あなたがQAエンジニアとして品質保証やテスト全般を担当していたとしても、早い段階でエンジニアを巻き込みましょう。デプロイパイプラインに自動テストを組み込み、その結果を直接エンジニアにフィードバックするのが一番の方法になるはずです。結果を一緒に確認し、テスト修正などの運用も一緒に解決していく文化を作りましょう。自動テストの存在しない開発では、真の意味の「アジャイルな開発」にはなりえないはずです。ソフトウェア開発の実現に向けて奮闘中。週末に娘と息子とお昼寝しながら世界のビーチや離島を旅する夢を見る。ソフトウェア開発の実現に向けて奮闘中。週末に娘と息子とお昼寝しながら世界のビーチや離島を旅する夢を見る。購読管理このバーを折りたたむコメントを読み込み中...コメントをどうぞメール名前サイト%d人のブロガーが「いいね」をつけました。