0

オンライン資料 ( FowlerやGerardなど) を読むと、Specification By Example の記事は機能の完全な仕様ではないように思われます。

質問 1 : SBE から始める人は、システムのすべての機能を説明するという点で、ストーリーがどの程度包括的である必要があるかをどのように判断しますか? つまり、十分にキャプチャしたので、いつストーリーを書くのをやめることができますか?

質問 2 : テスト チームが製品ドキュメントに照らして製品を検証する組織で、ストアが完全な仕様でない場合、「その他の」製品ドキュメントには SBE でカバーされていないすべてのケースを含める必要があると考えるのは正しいですか?

4

1 に答える 1

1

質問1について：

システム開発の最も重要な部分は、開発チームが製品所有者と会話することです。まず、ユーザーが必要とする機能の核心を見つけます。例を使ってこの質問に答えます。製品の所有者が、新しい Web サイトにログインするための機能を必要としているとします。この要件は次のように記述できます。

In order to gain access to the website's facilities
As a user
I want to be able to login to the website

(この回答のシナリオと機能を記述するために、 Gherkinドメイン固有言語を使用していることに注意してください)

プロダクト オーナーの主要な要件が指定されたら、ユーザーの観点からこの機能をどのように実装する必要があるかについて、プロダクト オーナーと話し合う必要があります (概要を維持し、専門用語を使用しないでください。ビジネスと話し合って、彼らが何を望んでいるかを見つけてください)。 ）。したがって、特定できる最初の「ハッピー パス」シナリオは次のようになります。

Given a user is on the login screen
When they submit valid login credentials
Then they gain access to the main website

製品の所有者とさらに話し合った結果、Web サイトには非常に機密性の高い情報が含まれているため、ログインに失敗した場合はシステム管理者に報告する必要があるとのことでした。これにより、別のシナリオが発生します。

Given a user is on the login screen
When they submit invalid login credentials
Then the system administrator is informed of the failed log-in attempt
And the user is informed that their login attempt failed

この時点で、製品の所有者は、システムへのログインに必要なシナリオはこれだけだと言うかもしれません。したがって、開発チームの観点からは、この機能に関してこれ以上調査を行う必要はありません (そのため、これ以上ユーザー ストーリーを書く必要はありません)。確かに、プロジェクト開発の後の時点で、製品所有者は、メインの Web サイトに到達する前に、ユーザーが最後にサイトにログインしたときに通知したいと言うかもしれませんが、これについてのみ心配する必要があります。彼らがそれを求めるとき。

質問2について：

組織は、上記のシナリオからテストを生成するCucumber (たとえば) を使用して、「生きている」ドキュメントに対して製品を検証する必要があります。

また、質問 1 への回答で述べたように、製品所有者を満足させるのに「十分な」シナリオ/ユース ケースを特定する必要があります。製品所有者が求めるのは、完全な仕様です。YAGNIの典型的なケースになる可能性があるため、製品所有者が何を望んでいるかを推測しようとしないでください。

于 2013-12-02T01:15:30.980 に答える