mablでのチーム作業

📘

フィードバックのお願い

多数のチームがそれぞれの方法で仕事を進めているため、その詳細を1つのドキュメントにまとめ、すべてを網羅することは困難です。しかし、困難を克服する方法はあります。ページの右上にある [編集を提案] ボタンを使って、あなたのベストプラクティスや提案を共有し、mablコミュニティの他のメンバーをサポートできます。

テスト

テストの詳細

命名規則: テストを見つけやすくし、その内容をわかりやすくするための命名規則を定義します。
* 例: アプリケーション名 - モジュール - テスト

ラベル: テストを整理するために使用します。
コンポーネント: 検索、ログイン、設定
ステータス: WIP、破損
チケット番号: JIRA-1234
テストスイート: スモーク、リグレッション

説明: 他のメンバーがテストの内容をすばやく理解できるようにテストケースを説明します。

テストの作成

テストステップ名を変更する: ステップのテキストをダブルクリックして、メンバー全員にわかりやすい語句に変更します。

既存のフローを使用する: 既存のフローを可能な限り使用して、テストの作成とメンテナンスにかかる時間を節約します。

必要に応じて新しいフローを作成する: テストで実行する特定のアクションを他のテストでも実行する必要がある場合は、そのアクションをフローにグループ化します。

データ駆動型変数: 任意の値をテストの外部から変更できます。テキストの入力とアサーションに効果を発揮します。 Variables {x} > Manage

テストの対象に重点を置く: アプリケーション内の特定のページのエレメントをテストする必要がある場合、一度ログインしたら、別の「Visit URL」ステップを使用してナビゲーションステップを省略し、テストの対象に直接移動します (ナビゲーションを省略するには、最低1回はテストしてください)。

テストをアサーションで終了する: テストの価値を決めるのは、検証の内容です。

記録されたアサーションは使用せずに、XPathまたはCSSセレクターで "Is present" または “Is not present” のアサーションのみを使用します

Echoステップをヘッダーとして使用する: Echoステップの先頭に “#”、“##”、または “###” を置くと、テスト内でヘッダーとして機能し、テストのさまざまな部分を視覚的に分割できます。

エレメントの発見: mablがエレメントを発見できるようにする場合は、常に以下の順序でステップを作成します。

  1. ステップの記録
    (発見できない場合は、次の方法を試す...)
  2. 記録したステップで [Configure find...] を設定
    (発見できない場合は、次の方法を試す...)
  3. XPathまたはCSSセレクターを使用してエレメントを発見 (不安定かつ失敗しやすいため、DevToolsからセレクターをコピーしないでください)
    (発見できない場合は、次の方法を試す...)
  4. JavaScript

フローの作成

命名規則:
例: アプリケーション名 - モジュール - アクション (パラメーター)
フローを1つのアクションに限定する:
良い: フォームへの入力
* 悪い: フォームへの入力と送信
アサーションで終了する: こうすることで、フローが期待どおりに実行されたことを検証できます。
パラメーター:

  • 変数値を使用するステップのフローパラメーターを作成する。
  • 複数の状況でフローが機能するようにする。
  • 技術に詳しいチームメンバーが、さまざまなシナリオで機能する強力なフローを作成できるようにする。
    • テストの記録または変数を作成するAPI呼び出し
    • より複雑なユースケースに対応するJavaScriptステップ (例: 一定の形式に従った日付の生成)
    • テストデータを使用したカスタムのCSS/XPathセレクターによるエレメントの発見

同じフローを作成しないようにする: 適切な命名規則に従うことで、作成済みのフローを把握し、すでに存在するフローを作成しないようにします。

プランの作成

命名規則
例: アプリケーション名 - モジュールまたは機能
ラベル: プランのラベルは、デプロイメントをトリガーする際に実行されるプランを管理できるようになるため、非常に重要です。
機能: 検索、ログイン、設定
* テストスイート: スモーク、リグレッション

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

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

テストの失敗を理解する

失敗したステップを起点にして、逆方向に検証する:

  1. スクリーンショットを確認し、目で見て原因がわかるかどうかを調べます。
  2. ネットワークログを確認し、ネットワークリクエストが失敗していないか調べます。
  3. mablのログを見て、mablが実行しようとしていたステップを把握します。
  4. (Chromeの場合) ステップトレースデータをダウンロードして [Chrome DevTools] > [Performance] から開き、詳細なスクリーンショットとページの動作を調べます。
  5. 問題を手動で再現します。
  6. アプリケーション内のチャットからmablサポートに連絡し、テストの出力からURLを提供します。
    チームメンバーのサポートを得るため、URLを共有する: すべてのテスト出力は静的URLに存在するため、チームメンバーと直接共有できます。mablユーザーの数に制限はないため、任意のユーザーがアカウントを作成して、結果を表示できます。

テスト結果のレビュー

失敗の分類: テストの失敗を調べたら、チームに以下の情報を提供するために失敗を分類します。

  • 問題の内容
  • 失敗をレビューしたユーザー

Results > By Deployment: プランがデプロイメントによってトリガーされる場合、[Results] ページの [By Deployment] の下で実行されたプランとテストを確認できます。


Did this page help you?