3

使用可能なワークフロー (インスタンスではなく、ワークフロー定義を意味します) のリストを表示するワークフロー エンジンがあり、ユーザーはワークフローの横にある [実行] リンクをクリックして、そのワークフローの新しいインスタンスを実行できます。この「ワークフローを実行する」というストーリー（機能？）をBDDのやり方でやりたいと思っています。

    Story: execute a workflow
    Scenario: execute a workflow by clicking on execute link in workflow list and nothing goes wrong
    Given I am a user with sufficient rights
    And I have added a workflow called "wf"
    When I click on the execute link next to "wf" in the workflows list
    When I view the list of workflow executions
    Then the output is:
"""
    1 | wf1 | not started
"""

(1 列目: 項目番号、2 列目: ワークフロー名、3 列目: 状態)

私は、これは DBB シナリオをうまくカットしたというよりも、ごちゃごちゃしているように感じます。私は特に受け入れ基準に関心があります。「ワークフローの実行」のような大まかなユーザー結合にどのようにアプローチする必要があるかについて、私の心は明確ではありません。つまり、あなたが行っているのが API である場合、すべてが明確ですが、(人間の) ユーザー インタラクションによって開始され、その結果が複雑な出力 (リストなど) を持つ別のユースケースを開始することから明らかな何らかの動作を説明している場合はどうでしょうか。アイテムの）。ワークフローが実際に実行されたことを知る基準は、ワークフロー実行のリストに新しい項目が表示されることですが、これは別の話です。私はここでちょっと混乱しています。

データベース レイヤーと対話して、新しく作成されたワークフロー インスタンスを格納する行を確認する必要がありますか?それとも、ワークフロー実行のリストに新しいインスタンスを指すアイテムが存在するかどうかを確認する必要がありますか? 2番目の場合、正確にはどうですか？1 つのシナリオで正しい値を持つすべての列を確認する必要がありますか、それとも独自のシナリオで各列を確認する必要がありますか?

4

1 に答える 1

5

Acceptance Criteria vs. Scenarios に関するごく最近の投稿を参照してもよろしいですか? 一般的なワークフロー エンジンではなく、ワークフロー エンジンの特定の用途に似たものを使用すると、例がよりわかりやすくなると思います。たとえば、これは私が自動化ツールを試すために使用している偽のペット ショップです。次に、一般的な自動化の問題を特定しようとするのではなく、ペット ショップに関するシナリオを書きました。

たとえば、顧客が時々ヘルスケアに携わっている場合は、エンジンを使用する偽の診断ツールを作成し、それに関するシナリオを作成します。最初は少し手間がかかるように思えるかもしれませんが、すぐに元が取れることがわかりました。

Story: A doctor diagnoses black death

Scenario: The doctor starts the diagnosis

Given I am doctor with rights to use the system
And I've added a workflow called "diagnosis"
When I choose the "diagnosis" workflow
Then it should tell me that it's not started.

これがあなたが求めている利点です。データベースに何かが保存されるのではなく、ユーザーが何らかの情報を取得するということです。可能な限り、シナリオは最終的な価値を追求する必要があります! だから多分それは次のようなことさえ言うべきです:

Story: A doctor diagnoses Black Death

Scenario: The doctor starts the diagnosis

Given I am doctor with rights to use the system
And I want to diagnose a patient
When I choose "Diagnosis"
Then the system should prompt me to start diagnosing.
Given that all the symptoms match Black Death
When I perform the diagnosis
Then I should be able to diagnose the patient with Black Death.

これを簡単かつ美的にするために必要な小さなステップは、実際には使いやすさの問題です。ユーザビリティの問題を説明するために BDD フレームワークを使用しないでください (ただし、BDD フレームワークはそれらをステップ実行できるため、回帰テストを行うことができます)。代わりに、手動で試してください。BDD は手動テストに代わるものではなく、少し役立つだけです。

ワークフロー エンジンの漠然とした現実的な使用方法を作成できれば、見落とす可能性のあるシナリオを考えるのに役立ちます。たとえば、このワークフローを特定の患者に関連付ける方法が今のところわかりません。具体的で想像力に富んだ例は、あいまいで一般的で包括的なものよりも、人々が他のシナリオを視覚化するのに役立つ傾向があると思います.

また、ビジネスで使用するのと同じ言葉で表現してみてください。あなたが本当に望んでいるビジネスの成果について考えてみてください。シナリオを実装する方法を考えずに、ただ書きましょう。これは、実際にビジネス担当者や顧客と話し合って、彼らが思いつくシナリオについて話すと、はるかに簡単になります!

シナリオを実行するために必要な複雑さはコードに入り、保守とリファクタリングが容易になります。

追加の利点として、特定のニーズを持つ特定の顧客を特定することで、顧客が「誰かがそれを必要とする場合に備えて」可能なすべての機能をワークフロー エンジンに入れるという罠を回避するのに役立ちます。実際のシナリオについて実際の人々と話し合うことで、誰がどの機能を最も必要としているかを特定し、範囲を縮小して、可能な限り多くの価値を提供できるようにします。

于 2011-10-13T14:45:40.517 に答える