mablを使ってチーム作業するときのアイデア

チームで作業するときに活用できる命名規則などのご紹介。

📘

ぜひフィードバックをください

多くのチームがそれぞれ異なる働き方をしているため、そのすべてを1つの文書にまとめることは困難です。難しいけれど、不可能ではありません。このページの右上にある "SUGGEST EDITS "ボタンを使って、あなたのベストプラクティスや提案を共有し、mablコミュニティの他のメンバーを手助けしてください。

Tests

テストの詳細

命名規則: テストを見つけ、何をするのかを定義するのに適した命名規則を定義する。

例:アプリケーション名 - モジュール - テスト

ラベル: テストを整理するために使用

ンポーネント。検索、ログイン、設定

ステータス WIP, Broken
チケット番号 JIRA-1234
テストスイート。スモーク、リグレッション

説明: 何をテストしているのかを他の人がすぐに理解できるように、テストケースの説明をします。

テストの作成

  • テストステップの名前を変更する。ステップのテキストをダブルクリックして、あなたやあなたのチームにとってより理解しやすいように書き換えます。
  • 既存のフローを使用する。既存のフローをできるだけ利用することで、テスト作成と後のメンテナンスの時間を短縮することができます。
  • 新しいフローを作成する: テストが行う特定のアクションが他のテストでも行われる必要があることが分かっている場合、それをフローにまとめます。
  • Data-Driven 変数: テストの外側から変更する可能性のあるすべての値。テキストやアサーションの入力に威力を発揮する。変数 {x} > 管理
  • テストしたいものに集中する: アプリケーションの特定のページで何かをテストする必要がある場合、一度ログインしたら、別の訪問 URL ステップを使用して、ナビゲーションのステップをスキップし、テストしたいものに直接アクセスします。(ナビゲーションが少なくとも一つのテストでカバーされていることを確認し、他の場所でそれをスキップできるようにします)
  • アサーションでテストを終わらせる。テストは、それが検証するものと同じくらい良いものです。
  • XPath または CSS セレクタのアサーションでは、「存在する」または「存在しない」のみを使用し、記録されたアサーションは使用しないでください。
  • ヘッダーとしてのエコーステップ: エコーステップの先頭に "#", "##", "###" を置くと、テストのヘッダーになり、テストの異なる部分を視覚的に分割することができます。
  • 要素を見つける: mablに要素を見つけさせようとするとき、常にこの順序でステップを作成するようにし てください。
    1. ステップを記録する(それでもダメなら...)。
    2. 記録されたステップを見つける設定(それがうまくいかない場合は...)
    3. XPathまたはCSSセレクタを使用して、要素のステップを見つける(DevToolsからセレクタをコピーしないでください。これらはもろく、簡単に失敗します) (これがうまくいかないと...)
    4. JavaScriptで探す

FLOWの作成

命名規則

例:アプリケーション名 - モジュール - アクション(パラメータ)

フローを1つのアクションに限定する

Good: フォームに入力する
Bad: フォームに入力して送信

End with an assertion: これは、フローが期待されることを行ったかどうかを検証できるようにするためです。
パラメータ:

  • 可変値を使用するステップのフローパラメータを作成
  • 複数の状況に対応したフローを実現
  • より技術的なチームメイトが、さまざまなシナリオで機能する非常に強力なフローを作成できるようになります。
    • テストレコードや変数を作成するためのAPIコール
    • より複雑なユースケースのためのJavaScriptステップ(例:特定の方法でフォーマットされた日付の生成)
    • テストデータを使用して要素を見つけるカスタムCSS/XPathセレクタ

フローが既に存在しないことを確認する:良い命名規則があれば、以前に作られたフローかどうかを知ることができ、二度手間を省けます。

プランの作成

**命名規則

例:アプリケーション名 - モジュールまたは機能

Labels: プランラベルは、デプロイメントをトリガーしたときに実行されるプランをより詳細に制御できるようにするため、非常に重要です。

機能性 検索、ログイン、設定
テストスイート。スモーク、リグレッション

アプリケーション/環境管理

すべてのURLは、末尾にスラッシュをつけないこと。これにより、どの環境でも動作する動的なVisit URLステップをテスト内で作成することができます。例: {{@app.url}}/shop/item/{{@item_id}}

テストの失敗を理解する

失敗したステップから始めて、後ろ向きに作業してください。

  1. スクリーンショットを確認し、視覚的な説明があるかどうかを確認する。
  2. ネットワークログをチェックして、失敗したネットワーク要求がなかったかどうか確認する
    1. mablログを読んで、ステップを完了するためにmablが何をしていたかを理解する。
      (4. Chromeの場合) ステップトレースデータをダウンロードし、Chrome DevTools > Performanceで開くと、より詳細なスクリーンショットとページが何をしていたかを確認できます。
  3. 手動で問題を複製する
  4. アプリ内チャットで mabl サポートに連絡し、テスト出力の URL を伝える。

チームメイトにURLをシェアして手伝ってもらう。すべてのテスト出力は静的なURLで存在するため、チームメイトと直接共有することができます。mablのユーザー数には制限がないため、誰でもアカウントを持ち、結果を見れます。

テスト結果を確認する

失敗の分類。テストの失敗を見た後、その失敗を分類すれば、チームは以下を知れます。

  • その問題が何に関連しているのか
  • 誰かがその失敗をレビューしたこと

Results > By Deployment: 計画実行がデプロイメントによってトリガーされた場合、結果ページのデプロイメント別で、実行された計画とそのテストだけを見れます。


Did this page help you?