Reading Best practice of story test

最近、Story Testの形に関して考えています。
目的は、AgileやLEANにて検証の対象となるStory/User Storyに対する評価としてStory Testをベースにしていきたい、というためです。
なぜなら、検証したい対象の形式に沿って、自動化するなりするときに”検証すべき興味の対象”と表現をあわせて試験を実施するほうが、価値に対する妥当性の議論の火種になったりという副産物を得ることができる可能性があるためとなります。
いくつかざっと目を通したのですが、ひとまずの参考と考え方を整理するために以下を参考にしました。
以下のExampleは、いずれも参考先を引用させてもらってます。

Storyの書き方は大枠としては以下がおおい。
Style 1: Bullet Points
Style 2: “Test with…”
Style 3: “Test that…”
Style 4: Given/When/Then
Style 5: Specification By Example – Conceptual Form
The Best Style: Mix and Match!

Style 1: Bullet Point

– Storyカードや、Wikiに、箇条書きすることによりシナリオを列挙する。システムの振る舞いがおおい。
– これは、理解が容易なシナリオの時にうまくいく。
– 事前条件としてxxが必要、などの複雑さがあるような時は不適切。
Example Tests
– old password
– new password
– confirmation password (must match new pw)
– new password complies with password rules

Style 2: “Test with…”

– テストしなければならないすべてのシナリオやデータを記述する。
– これは、理解が容易なシナリオの時にうまくいく。
– 変数の場合分けが多く、シナリオがふくれすぎる場合は不適切。
Example Tests
1.Test current password with incorrect, correct, blank
  • with optional “verify” clause
    • Test current password with incorrect, correct, blank – verify error msgs
  • with optional beginning of “Test with”
    • Test with incorrect, correct, blank current password – verify error msgs
2.Test with special characters in current password
3.Test confirmation password with blank, matching, non-matching
4.Test with admin users, manager users, end users
5.Test with 0, 1, 3, and 5 companion products

Style 3: “Test that…”

– 「…をテストする」で終わるような文をまず書き、 その後にシステムの振舞を評価するために必要な文を書き足していく。
– 受け入れ試験の形式として記述していくのに良い。
– 習得しやすいのが良い。
– 前の2つの方法でうまく表現できないようなテストでもシンプルなものであればうまく表現できるかも。(複雑なものは苦手。)

Examples

  1. Test that, when a user enters an incorrect old password, they get an error message indicating incorrect credentials.
  2. Test that three incorrect submissions of the old password within 1 hour results in the user being logged out from the system.
  3. Test that when a user is logged out after 3 incorrect submissions that they also receive a message telling them to call customer service, along with the customer service phone number.
  4. Test that, when a user clicks on the “Continue Shopping” link, it takes them to the home page.
  5. Test that the order confirmation contains:
    • An order number
    • Estimated arrival date
    • Customer Service email address

Style 4: Given/When/Then

– 前提(ーの場合)、処理(ーしたら)、結果(ーになる)という3つの章だてで記述していく。それぞれは以下のようなもの。
  • Given
    • Preconditions, test setup, test inputs, system state
  • When
    • Trigger or State Transition event
  • Then
    • Describe system behavior, expected outputs, and/or next system state
– TurnipやCucumberの場合、このような形でシナリオを具体化しますね。それに似ている感じでしょうか。

Examples

1.
  • Given
    • A user who has submitted an incorrect old password 2 times in the last hour
  • When
    • The user submits an incorrect password (for the 3rd time)
  • Then
    • The system logs the user out
    • The system displays:
      • the customer service phone number.
      • a message telling them to call customer service.
2.
  • Given
    • A user that is logged in AND
    • the user is an admin user OR the user’s account has been flagged by Fraud
  • When
    • The user submits an incorrect password (for the 3rd time)
  • Then
    • The system logs the user out AND
    • The system generates an email to the production support team with the following info:
      • user id of the user AND
      • the user’s phone number on file

Style 5: Specification By Example – Conceptual Form

– テストの入力と期待する出力を、表形式で記述していく。表形式で簡単に表現できるテストは、この方法が機能する可能性がある。
– 単純なテストに関してはより簡潔に書ける方法で書く方が良い。

Examples

Expected System Behavior for sending emails through a third party service.
Service Ais Up? . Service Bis Up? . Is attachmentmore than 150Kb? . Expected PrimaryEmail Service Expected BackupEmail Service Expectedoutputif backup fails
Y Y Y B None – queue for later sending
Y Y N A B display error
Y N Y None – queue for later sending
Y N N A None – display error
N Y Y B None – queue for later sending
N Y N B None – display error
N N * None – display error

* = all possible values

– = Not Applicable
In order to understand what this table represents, here are the example business rules(You have to assume that there are good business reasons for these rules, otherwise, the complexity would probably not be justified):
  1. Don’t allow the system to ever try to send emails to a service that is down.
  2. If both services are down, always display an error.
  3. Never send emails with attachments more than 150Kb to Service A.
  4. It is ok to send emails with attachments more than 150Kb to Service B. If Service B is down or fails for an email larger than 150Kb, then queue the email for later sending.
  5. If Service A is up, it is the primary service.
  6. If sending the email through the primary service fails, use the backup service, if there is one, and if the backup service is up.
  7. If the Backup service is attempted and fails, display an error message.

The Best Style: Mix and Match!

上記のテストらを組み合わせて、必要な所に適した粒度でシナリオを書いていく。
——–
上記のなかで、逐一 “シンプル” という言葉が原文では出てきます。つまること、User StoryやStoryは簡潔に落とし込まれ、記述されるというところがポイントであり、それがテストを簡潔に回していく鍵である、というAgileやLEANでの定石を踏んでいますね。
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s