TestRail - プロジェクトの個別設定

導入

私が携わった多くのプロジェクトでは、人々は TestRail を自分用にカスタマイズせず、標準設定で対応していました。 そこで今回は、作業の効率化に役立つ個別の設定例を解説していきます。 たとえば、モバイル アプリケーション開発プロジェクトを考えてみましょう。

ちょっとした免責事項。 この記事には、TestRail の基本機能の説明 (これに関するガイドは多数あります) や、テストを含むリポジトリを作成するためにこの特定のベンダーを選択する必要がある理由をカラフルに説明するセールス表現は含まれていません。

正当化計画（何が実施されるか）

1. 一般的な要件

   1. 絶対に誰でもこの事件を通過できるはずです。

   2. ケースはできるだけ長く関連性を維持する必要があります

   3. ケースでは、最初の XNUMX つの点と矛盾しない範囲で、モバイル アプリケーションの機能を可能な限り徹底的にカバーする必要があります。

2. TestCase と TestScenario に分割

3. さまざまなタイプの TestRun を迅速に生成

   1. スモーク

   2. 回帰

   3. 衝撃試験など

4. ケースサポートの最適化

   1. 「死んだ」ハードコードされたスクリーンショットを放棄し、「可動データ」に切り替える

要件

フィールドを編集するには管理者アクセスが必要です

プロジェクトの種類の選択

次の XNUMX つのプロジェクト タイプから選択できます。

デフォルトのタイプを選択します。 すべてのケースが同時に利用可能になります。 スマート フィルタリングを使用し、すべてのケースを一度に動的に管理します。

テストケースのリストを表示するためのフィールドの追加

優先度の高いテスト ケースを表示するフィールドを追加しましょう。

他のフィールドを追加することもできます。

テストケースのフィールドとタグの設定

設定メニューを開きます。

次のフィールドが必要になります。

「概要」フィールド（テストケースヘッダー）

この分野はすでに存在しており、私たちはその利用法を体系化しているところです。 ケースを TestCase と TestScenario に分けて説明します。 膨大な症例のリストを読みやすくするために、要約を作成するためのルールについて事前に合意することをお勧めします。

テストシナリオ:

例: TestScenario - モバイル アプリケーションを使用するための基本シナリオ

テストケース：

例: メイン画面 - 認証セクション - ログインを入力

全体として、事件の概要には、「何を、どこで、いつ」という古典的な理解が見られます。 また、自動化に最適な形式で高レベルのテスト スクリプトと低レベルのテスト ケースを視覚的に分離します。

「StartScreen」タグ (TestScenario が開始される画面。また、多くのテスト ケースは隣接する画面に触れることができます)

必要な場合: ユーザーを現在のテスト ケースの画面に導く典型的な手順のテキストをテキストから削除します。 (特定のテスト状況を作成するための一般的な手順) すべてのテスト ケースのすべての一般的な手順は XNUMX つのファイルに記述されます。 詳しくはまた別途書きます。

新しいフィールドを作成します。

新しいフィールドのコンポーネントを入力します。

この場合、値のリストから選択フィールドを作成します。 このフィールドの値を入力します。

id 値は XNUMX から始まり連続ではないことに注意してください。 なぜこれが行われるのでしょうか? 重要なのは、入力された ID が記録されたテスト ケースがある場合、

その後、既存の XNUMX つの画面の間に XNUMX 番目の画面を作成する必要があります。

その場合は ID を書き換える必要がありますが、既存のテキスト ケースのタグはすでに付加されているため、単純に削除されます。 それはとても不快なことでしょう。

タグ「画面」（TestCaseに影響を与える画面の名前）

必要なもの: 衝撃試験用のアンカーの XNUMX つ。 たとえば、開発者は新しい素晴らしい機能を作成しました。 これをテストする必要がありますが、そのためには、この機能が正確にどのような影響を与える可能性があるかを理解する必要があります。 デフォルトでは、アプリケーションの異なる画面 (アクティビティ) には異なるクラスがあり、したがってアプリケーションの異なるコンポーネントを構成するというパラダイムから始めることができます。 もちろん、この場合には個別のアプローチが必要です。

例: home_screen、MapScreen、PayScreen など。

「MovableData」フィールド（変更可能なテストデータを含むプロキシデータベースへのリンク）

次に、テスト ケース内のデータの関連性を維持するという問題の解決を試みます。

1. 現在のレイアウトへのリンク (これは、無効なスクリーンショットを撮るよりもはるかに優れています)

2. テスト状況の画面に到達するための一般的な手順

3. SQLクエリ

4. 外部データおよびその他のデータへのリンク

各テスト ケース内にテスト データを書き込む代わりに、XNUMX つの外部ファイルを作成し、すべてのテスト ケースにそのファイルをリンクします。 このデータを更新する場合、すべてのテスト ケースを調べて変更する必要はありませんが、このデータを XNUMX か所だけ変更することができます。 準備ができていない人がテスト ケースを開いた場合、テスト ケースの本文にファイルへのリンクと、テスト データを取得するためにそのファイルにアクセスする必要があるというヒントが表示されます。

このすべてのデータを XNUMX つの外部ファイルにパックし、プロジェクトの全員が利用できるようにします。 たとえば、Google Sheet または Excel を使用して、ファイル内での検索を設定できます。 なぜこれらの特定のベンダーを使用するのでしょうか? 実際のところ、私たちは、チーム内の誰もが最初にツールをインストールすることなくテスト ケースを開いて合格できるべきであるというパラダイムから出発しています。

のために Googleシート SQL クエリを使用できます。 例：

=query(DATA!A1:M1146;"
SELECT C,D
WHERE
C contains '"&SEARCH!A2&"'")

のために Excel 便利なインスタント検索マクロを設定できます。 (フィルタリング) 例 リンク.

実は、このアイデアは新しいものではなく、最初のテスターの本「テスティング ドットコム」に記載されています。 (著者 Savin Roman) 私たちは、Roman Savin によって提案されたメソッドを TestRail に統合しているところです。 これを行うには、作成したファイルへのリンクを含むフィールドを作成します。

リンクのデフォルト値を入力して、新しいテスト ケースごとにリンクがすでに存在するようにします。

外部ファイルの場所が変更された場合 (不可抗力に備えて)、すべてのテスト ケースで XNUMX つ以上のフィールドを一度に変更できるので便利です。

「説明」フィールド（テストケースの説明またはアイデア、標準的な指示）

必要なもの: このテキスト フィールドには、テスト ケースと標準手順の簡単な説明を入力します。

例： このテスト ケースのすべてのテスト データ (現在のレイアウト、ツールの使用、その他のデータ) はリンク {...} で示され、MovableData ファイル内にあります。 上部の対応するフィールドで MovableData にリンクします。

タグ「コンポーネント」（モバイルアプリケーションコンポーネント）

必要な用途: 衝撃試験。 モバイルアプリケーションを複数のコンポーネントに分割することができれば（相互に影響を最小限に抑えることができます）、XNUMXつのコンポーネントの変更は（ある程度のリスクはありますが）同じコンポーネント内でチェックするだけで十分となり、実行する理由が少なくなります。すべてのものの一般的な回帰。 あるコンポーネントが別のコンポーネントに影響を与える可能性があるという情報がある場合、影響テスト マトリックスが作成されます。

コンポーネントの例: GooglePay、Order、Users、Map、Authorization など。

タグ「TAG」（その他のフィルタリング用タグ）

任意のフィルタリング用のタグを使用してテスト ケースにタグ付けします。 

以下の場合に非常に役立ちます: 

1. スモーク、回帰などのさまざまな典型的なタスク用に TestRun をすばやくコンパイルします。

2. テストは自動化されるのでしょうか、それともすでに自動化されていますか?

3. 他のタグ

例: Smoke、Automated、WhiteLabel、ForDelete など。

テストケース内のフィールドの表示順序を設定する

たくさんの新しいフィールドを作成しました。今度はそれらを使いやすい順序に並べます。

テストランの作成

ここで、現在のケースを使用して新しいテスト実行を作成し、XNUMX 回のクリックでスモーク テストを実行します。

その他のヒント

1. TestRail に複数のプロジェクトがある場合は、自分のプロジェクトにのみ新しいフィールドを作成することを忘れないでください。そうしないと、隣のチームの同僚が新しい珍しいフィールドの出現に非常に驚くことになります。 局所的に失神する可能性があります。

2. 多数のフィールドを含むケースは、新しいグループを作成するよりも、同様のグループ タイプからコピーする方が簡単です。

3. アカウントを共有することができます。 例: XNUMX 人の管理者、複数のユーザー。

まとめ

上記の例はいくつかのプロジェクトに実装されており、その有効性が実証されています。 このツールについての理解を深め、効果的で便利な「テスト ストレージ」の作成に役立つことを願っています。 TestRail の使用経験や役立つヒントをコメントに記載していただければ幸いです。

リンク：

TestRail ベンダーの Web サイト

本： 「Testing .COM」（著者ロマン・サヴィン）

ご清聴ありがとうございました！

出所： habr.com