毎日200シナリオ以上、月に1万シナリオ以上、月に1万ステップ以上を実行して安定化ができてきた経験をどこでも実現できるように、これまでの知見・経験をまとめてみようとおもいます。mablのようなサービスを使って、安定したE2Eを作るときの参考になれば。
QA自動化サービスとは何か？
ここではmablをベースにまとめますが、ノーコードでありキャプチャ＆リプレイ形式でテスト実行できるツールであれば、似たような作りになっているはずなので参考になるかなーと思います。mablの基本的な使い方については以下を参考にどうぞ。
https://daipresents.wordpress.com/2019/mabl/
掟1. 観点はひとつ
ひとつのテストの中に、観点（確認したいこと）が複数あった場合、1つ目の観点でテストが失敗した場合に、2つ目の観点はテストされません。よって、観点はひとつにするべきです。
観点の依存は良くないけれど、以下の例のようにデータの登録と削除は、1ケースに詰め込んでもいいでしょう。APIでデータ作成ができるなら、登録と削除も分割できます。
例： - 登録処理と削除処理は一つのケースにする （データを作らないと削除できない場合） - 編集処理は既存データを修正し続ける方法を取る
掟2. 小さく作る
mablは並列で繰り返しやるのが得意なので、テストは小さく作りましょう。
具体的には、目標実行時間を決めて、時間内に終わるように作ります。たとえば、僕の場合は5分以内を目標にしています。逆に、まず作ってみて、長いテストから可能な限り分割する方法もあります。
たとえば、ユーザ作成のステップを毎回30秒で実行しているとします。これは「30秒 x ユーザ作成するケース数」で合計コストがでます。
これが大きいと感じるなら、30秒を短縮する方法を考えましょう。たとえば、APIを使ったテストデータ作成ができれば、よりテストを小さく作れるはずです。
例： - ユーザ作成をAPIでやってからテスト実行する - すでに確認している項目をスキップして時間を短縮する
掟3. 表示が変わるごとにアサートする
自動テストは目が見えません。たとえば、今どのページにいるかを自動テストは理解できません。
画面遷移した場合は、遷移が正常に行われ期待するページが表示されることを毎回確認しなければなりません。確認方法はそのページ特有の見出しであったり、「登録しました」といったのメッセージを利用できます。
モーダルウィンドウ（HTMLによって表現したメッセージボックス）が表示されるときも、表示されている文言を確認して、モーダルの表示確認を行います。
mablであれば WaitUntil というステップが利用でき、3〜5秒の設定が安定します。「特定の見出しが表示されるまで待つ」がベストでしょう。
参考： Adding wait and wait until steps
掟4. 同じ操作を2回するなら部品を作る
自動テストにもDRY原則(Don’t Repeat Your Self：繰り返しを避ける）を適用すべきです。2回同じことをするならそれは部品（mablだとFlow）にして再利用しましょう。
たとえば、画面左にメニューがあるアプリの場合、それぞれのメニューに合わせて遷移用部品を作ります。
最終的に、自動テストのほとんどが部品で構成されるようになり、ひとつひとつの部品の品質を高めることで、よりテスト全体が安定していきます。
参考： Using reusable flows in the Trainer
掟5. テストごとにユニークな文字列を活用する
データを登録したり修正したり。テストで何かを入力したいときは、テストごとにユニークな文字列を入力しましょう。これによって、問題発生時にどのテストなのか特定しやすくなるはずです。
例： 名前： 藤原大_sFw5sxg
mablの場合、{{alnum:10}} といった書き方でアルファベットと数字の混合文字列10桁を簡単に作成できます。こういったテストのIDとなる文字列をテストのはじめに部品として読み込むのも手です。
参考： Using variables
掟6. 大切なものだけAssertion
自動テストは目が見えません。テストの目となるものがAssertion（確認項目）です。
一つの画面でいろいろな確認をしたくなると思いますが、すべてを確認するのは大変です。よって、このテストで本当に確認したいことを確認しましょう。
観点があるのであればその観点に紐づくAssertionを入れましょう。
「せっかくだからついでに・・・」とAssertionを増やすと、観点が変わってしまいます。そういう場合は、新しく増やしたい観点でケースを作ります。
掟7. スリープは最大限に短く
Webアプリではタイミングでテスト失敗する場合が多いので、自動テストにスリープを入れるケースもあります。ただし、入れる場合は「〜が表示されるまで5秒だけ待つ（前述のWaitUntilなど）」という方法を選択しましょう。
また、mablでは、AssertionやXpathによる検索時の待ち時間を設定できます。デフォルトが長く感じる場合は、短く設定するのも手です。
実行時間はスリープの長さや回数に依存します。しかしながら、Webアプリではデータのローディング時間等の影響を受けてしまうため、秒数は限りなくする必要があります。
掟8. 条件分岐やループは最低限
最近のテスト自動化サービスは、プログラミング言語と同じく条件分岐、ループが利用できます。便利ですが使いすぎは危険です。
条件分岐は、データ編集系のテストで有効活用できます。たとえば、「もしもデータがAAAAならBBBBを入れる」または「BBBBならAAAAを入れる」といった分岐があれば、テスト失敗しても、いちいちデータをAAAAやBBBBといった直前の状態ににもどさなくてよくなり、再実行可能なテストになります。
ループは基本的にあまり使いません。連続登録や連続削除など、観点をしぼってじっこうすると良いと思います。
参考： Using conditionals steps in the mabl trainer
掟9. 変数名はキャメルケース
データを使いまわしたい場合は変数を活用できます。
変数名も色々試行錯誤したのですが、mablの場合はキャメルケース（userNameとか)がしっくりする気がしています。
掟10. JSやXpathは最終手段
mablのようなサービスのいいところは自動でエラーを回避しようとする機能です（mablではAuto healと呼ばれる）。
内部的には、現在や過去のDOM構造や、テキスト情報から要素を推測しているのですが、JSによるデータ作成ステップや、Xpathを使った要素特定をすると、この恩恵を受けられなくなります。
細かいところに手が届くのはいいけど、活用しすぎるとテストの柔軟性を失うので注意しましょう。
たとえば、Xpathを使わざるを得ない場合は、できるだけ柔軟なXpath（containsを使うなど）を検討します。
例： NG: //form/button[text(), '登録'] Good: //*[contains(text(), "登録")]
また、テストの安定化を考えるために、なぜE2Eテストでidを使うべきではないのか を読むことをおすすめします。E2Eにおける要素特定のトレンドを学べるはずですし、Auto Healが有効的に動く可能性も高まります。
掟11. コメントやアノテーションを入れる
テスト名、テストの説明だけで、そのテストの意味を語り尽くすのは難しいはずです。
相手に伝わるテストを作るために、テストの間にコメントやアノテーションを入れましょう。特にXpathやスリープはそれだけでは意図が伝わりません。
コメントは、H1、H2・・・といった表記が可能です。たとえば、全体の流れはH1などルールを決めるといいです。
僕の場合は、全体の流れをH1、H1より小さい処理はH2、Flowの中はH2を使う・・・といったルールにしています。
掟12 名前やラベルで整理する
ぱっと見ただけでどういうテストかわかるように、プラン名・テスト名を工夫したり、ラベルを活用しましょう。mablではカテゴリがなく、ラベルで管理する必要があります。
たとえば、プラン名はテストケースををまとめるテストスイートにふさわしい名前にするべきでしょう。また、実行時間を書いて実行順に並べ替えるのも便利です。
例： プラン名： 商品の購入のパターン網羅 プラン名： [01:00-02:30] ユーザ登録（有料ユーザ・無料ユーザ・ゲストユーザ）
ラベルはプランをさらに絞り込むためのものです。Slack通知単位や実行時のテスト指定で使います。また、テストの種類や重要度もラベルとして使えます。
例： テスト名： ECサービス > ユーザ登録と削除処理（ラベル： EC、CRUD） テスト名： ユーザ登録と削除処理（ラベル： EC、CRUD、重要度A、リグレッション）
上記のようにしておくと、「重要度Aを実行したい」「ECサービスに関わるテストを実行したい」「リグレッションを実行したい」というユースケースに活用できます。
作りかけのものは「WIP」をつけてもいいかもしれません。
参考： Add and Filter by Custom Labels on Plans and Journeys
掟13. テストを使い回す
何回もテスト実行することで、自動テストの恩恵を受けられます。特定の期間や特定のタイミングで実行するだけではなく、たとえば、DEV・STG・本番環境ごとにテストを再利用する方法もあります。
アプリケーションやシステムの環境によると思いますが、環境が変わっても動作するテストを作れると強みになります。
また、最近のトレンドはリリース後のテスト自動化です。つまり本番テストまで使い回すことで、自動テストの恩恵を最大限に受けられます。
掟16. 実行タイミングを設計する
自動テストは実行すればするほどその恩恵が大きくなります。
しかし、テストの実行回数が増えるに比例して、テストの確認コストが増えます。テストが安定していない場合は、より増えます。
mablのような月額実行回数で金額が決まるサービスの場合、実行回数が増えると運用コスト（サービス利用コスト）も増えます。
でも、実行回数が少なすぎると、テスト結果というフィードバックを受けるタイミングも遅くなるため、どうバランスを取るかの設計が必要です。
実行タイミングは大きく、以下の種類にわけられます。
- コミットごと => 特定機能やその周辺機能の確認用
- デプロイごと => QAフェーズ前のリグレッションテストとしてなど
- リリース前 => リリース前の最終確認として
- 定期実行 => 定期チェックによるアプリのヘルスチェックとして
これらを考慮して適切な実行タイミングを設計しましょう。リグレッションテストの整備からはじめるのがおすすめです。
掟15. mablをデリバリパイプラインに統合
あなたがQAエンジニアとして品質保証やテスト全般を担当していたとしても、早い段階でエンジニアを巻き込みましょう。
デプロイパイプラインに自動テストを組み込み、その結果を直接エンジニアにフィードバックするのが一番の方法になるはずです。
結果を一緒に確認し、テスト修正などの運用も一緒に解決していく文化を作りましょう。
自動テストの存在しない開発では、真の意味の「アジャイルな開発」にはなりえないはずです。
＊
旅と子育てとアジャイルコーチのブログ「世界」 