ルールの例

ルールの作成の例を以下に示します。

不具合が再び開かれた回数を数える

品質プロセスを改善するために、Fixedに設定した後に再度オープンした回数を追跡できます。

  1. 不具合エンティティに整数型の「要再修正数」フィールドを作成します。詳細については、フィールドのカスタマイズを参照してください。
  2. 不具合エンティティの新しいルールを作成します。

  3. アクションの詳細。アクションタブで次の値を選択します。

    設定 値
    アクション 「フィールド値の設定」
    タイミング

    「エンティティの保存時」
    フィールド '要再修正個数' フィールドを選択します。
    値を次のようにインクリメントします 1

  4. 条件の詳細。条件タブで次の条件を定義します。

      フィールド 演算子 値
    #1 フェーズ Current = 修正中
    AND
    #2 フェーズ Orignal ≠ 新規

手動テストの最後の修飾子を記録する

手動テストに最後の変更を加えたのは誰かを知ることは有用です。この情報をユーザー定義フィールドに記録するルールを作成できます。手動テストに指定された変更が加えられると、フィールドにデータが入力されます。

  1. Manual TestエンティティにUserタイプの「Last Modifier」フィールドを作成します。詳細については、フィールドのカスタマイズを参照してください。
  2. 手動テストエンティティの新しいルールを作成します。

  3. アクションタブで次の値を選択します。以下のスクリーンショットを使用してください。

    設定 値
    アクション 「フィールド値の設定」
    タイミング

    「値の変更時」

    注: 値を変更すると、「最後の修飾子」フィールドへの変更が記録されるフィールドを選択します。
    フィールド 「最後の修飾子」ユーザー定義フィールドを選択します。
    値の設定: '[現在のユーザー]'

特定の条件下で使用するためのルックアップリストの組み合わせ

不具合のリリースが2.00の場合、不具合の重大度にルックアップリスト値を追加するルールを作成します。

たとえば、リリース1.16で使用可能な重大度の値は、1-低、2-中、3-高のようになります。リリース2では、重大度の値が追加されたため、完全なリストは1-低、2-中、3-高、4-非常に高い、5-緊急です。

前提条件

値4-非常に高いおよび5-緊急を含む新しい重大度リストを作成します。それを重大度2と呼びます。

追加のリスト値が必要な状況を定義するルールを作成します

アクション: 元のルックアップリストの値に加えて、不具合の可能性のある重大度の値に対して追加のルックアップリストを使用します。リストフィールドで重大度2を選択し、必要に応じて、個々のサブリスト値を選択します。

条件: 不具合の [リリース] が2である場合

結果:  

  • ALM Octane UIで、リリースが2の不具合を開くと、元の3つの重大度値からではなく、5つの重大度の値すべてから選択できます。 

  • 重大度でフィルタリングすると、5つの値すべてが使用可能になります。

トップに戻る

ルックアップリストのサブセットの設定

現在のチームによっては、不具合の起点となる項目を使用できないことがあります。たとえば、ALMとALM Octaneのみを操作しているあるチームの場合、チームの不具合の起点となる項目はService AnywhereやJIRAではありません。チームに基づいて、現在のルックアップリストのサブセットのみを利用可能にするルールを作成できます。

条件: [チーム] フィールドの値が特定の値である場合

アクション: チームに関連する [項目の作成元] の値を選択します。

トップに戻る

フィールドを必須にする

自動テストで値が空にならないように、テストツールタイプを必須に設定します。

条件: [テストツールタイプ] フィールドが [が空の場合] の場合

アクション: [テストツールタイプ] フィールドの値が要求されます。

トップに戻る

フィールドの標準設定値の設定 (フィールド値の設定)

各手動テストをアプリケーションモジュールに確実に割り当てるため、[アプリケーションモジュール] フィールドの値を、すべての空ステータスに適用される標準設定アプリケーションモジュールに設定します。

条件: テストの [編集モード] が [新規] の場合、テストは作成されたばかりであることを意味します。

アクション: [アプリケーションモジュール] フィールドを [一般] に設定します。

トップに戻る

関連項目変更時の値の設定 (フィールド値の設定)

すべての子タスクが完了したときに、ユーザーストーリーを自動的に完了に設定します (DoD)。

  • 条件: フェーズ新規または進行中の子タスクの数はゼロです。この条件を定式化するには、次の値を使用します。

    オペランド 「子タスク数」
    演算子 {filter = フェーズ: (新規、進行中) }
    次の値に等しい 0

  • アクション: ユーザーストーリーのフェーズフィールドを完了に設定します。

次のことを考慮してください。 

  • 現在のフェーズから完了への移行は、ワークフローに基づいて可能です。たとえば、ユーザーストーリーのフェーズが新規の場合、完了に昇格することはできません。

  • [フィールド値の設定] ルールは、必須フィールドに値があることを確認するために検証されません。たとえば、完了にプロモートするときに重大度が必須フィールドである場合、重大度は空白であっても、プロモーションルールはフェーズを完了に更新します。

  • ルールは手動の変更を上書きします。したがって、このルールを定義すると、例外はありません。たとえば、関連するすべてのタスクが完了した場合、ユーザーストーリーのフェーズを手動で変更することはできません。次回ルールが実行されると、フェーズは完了にリセットされます。

  • ルールが実行されると、そのアクションは内部システムユーザーによって実行されます。

トップに戻る

Webhookのトリガー (URLの呼び出し)

エンティティの作成、削除、または更新時に別のアプリケーションとのWebHook統合を行う場合は、Webhookのトリガールールを使用してエンドポイントURLに要求をPOSTできます。このURLにあるサービスは呼び出しを受け取って要求を処理します。

条件: <なし>

実行条件: 新規、更新、削除

アクション: ALM Octaneのエンティティ情報を次のエンドポイントURLにPOSTする: http://myServer:8081/myAPI

イベントの結果としてエンドポイントURLに情報をPOSTするWebhookのトリガールールのセットアップの詳細については、他のアプリケーションのためのWebhookのトリガーを参照してください。

トップに戻る

フォームの切り替え

テスト担当者が不具合を作成してバグ報告をする場合、組織レベルのポリシーによって、テスト担当者に次のフィールドの表示と編集を許可します。[説明] と [重大度]。

同様に、開発者が不具合の修正を開始する際には、開発者に次のフィールドの表示と編集を許可する必要があります。[修正日時]、[修正ビルド]、[所有者]。

次の2つのルールを定義します。

  • ルール1: 開発者用のフォームを設定します。

    条件: チームが開発者チームの場合

    アクション: 開発者用のフォームを使用します。

  • ルール2: テスト担当者用のフォームを設定します。

    条件: チームがテスト担当者チームの場合

    アクション: テスト担当者用のフォームを使用します。

トップに戻る

項目の属性が更新されたときに電子メールを送信する

ユーザーストーリー、不具合、またはその他の項目でステータスが変更された場合、該当する項目が更新されたことを通知できます。

これを行うには、次のいずれかの方法で定義します。

  • 項目のフェーズなど、特定のフィールドの変更を通知する場合は、[が変更済みの場合] をフィールドの演算子として選択します。

  • 不具合の修正中から修正済みへの移行など、指定したフィールドの特定の値への変更を通知する場合は、[元の値 =] フィールドを前の値に設定し、新しい値に対して標準演算子を=に設定します。

トップに戻る

開発者による不具合のクローズを不可能にする (他のすべてのユーザーは不具合をクローズできる)。

開発者は不具合をクローズする必要がないため、この遷移をブロックするワークフロールールを作成できます。

このルールは、エンティティの [ワークフロー] タブで作成することをお勧めします。こうすることで、遷移の [遷移元] フェーズと [遷移先] フェーズがあらかじめ入力された状態になります。[クローズ候補] と [クローズ済み] の間の遷移を選択し、[ルール] パネルを使用してルールを追加します。

条件: [現在のユーザーロール] に [チームメンバー] が含まれている場合...

アクション: [クローズ候補] から [クローズ済み] への遷移をブロックします。

トップに戻る

テスターが一部のリリースで不具合を開くことを許可しますが、他のリリースでは許可しません

テスターはさまざまなリリースで動作します。

まず、スペース管理者に、テスターに不具合の作成/編集権限があることを確認するように依頼します。詳細については、ロールと権限の割り当てを参照してください。

次に、テスターが不具合を更新できないリリースをリストする条件を使用してアラートユーザールールを追加します。

ルールの条件がtrueと評価された場合、ルールは、更新が指定された条件に違反していることをユーザーに警告し、不具合に対するすべての更新を防止します。

アクション: 状態が問題を示している場合 (つまり、状態がtrueと評価される場合)、不具合を作成、変更、または削除するときにユーザーに警告します。

条件: 現在のユーザーロールにテスト担当者が含まれ、リリースが禁止されたリリースと等しい場合、条件はtrueと評価されます。ユーザーに警告が表示され、更新が防止されます。

トップに戻る

参照情報: