Writing Test Cases From User Stories And Acceptance Criteria: Overview user Stories Overview Requirement Overview Acceptance Criteria Overview Test Cases

1. WRITING TEST CASES
FROM USER STORIES
AND
ACCEPTANCE
CRITERIA

2. 2
Agenda:
2
3

3. What Is A User Story?
￮ User stories are short, simple descriptions of a feature told from
the perspective of the person who desires the new capability,
usually a user or customer of the system .
￮ They usually follow a template like this:
As a <type of user>, I want <some desired outcome>
so that <some reason>.
￮ Example: “As a customer, I want to be able to view the
items in my cart so that I know for sure what I’m purchasing.”
 Promote more discussion and collaboration with the whole
team .  Used in agile model .
3

4. Agile Features
1. ITERATIVE
4
2. INCREMENTAL &
EVOLUTIONARY
6. VALUE-BASED
DEVELOPMENT
5. FACE - TO - FACE
COMMUNICATION
3. ADAPTIVE
4. EMPIRICAL PROCESS
CONTROL

5. 8 Benefits of Agile Software Development
1. STAKEHOLDER
ENGAGEMENT
5
2. TRANSPARENCY 6. ALLOWS FOR
CHANGE
5. EARLY AND
PREDICTABLE DELIVERY
3. EARLY AND
PREDICTABLE DELIVERY 7. FOCUSES ON
BUSINESS VALUE
4. FOCUSES ON
USERS 8. IMPROVES QUALITY

6. The 3 C’s of User Stories
￮ Card: stories are traditionally written on notecards,and
these cards can be annotated with extra details
￮ Conversation: details behind the story come out through
conversations with the Product Owner.
￮ Confirmation : Acceptance test confirm the story is
finished and working as intended.
4

7. A good user story matches the following
model called “INVEST” created by Bill Wake:
1. INDEPENDENT
Reduced dependencies
= easier to plan;
7
2. NEGOTIABLE
Details added via
collaboration (with all
parties mentioned
above);
5. SMALL
Can be done in less than
a week by the team;
4. ESTIMABLE
Too big or too vague =
not estimable;
3. VALUABLE
Provides value to the
customer;
6. TESTABLE
Good acceptance
criteria

8. What is requirements?
￮ A statement of what should be tested in the AUT.
￮ Functional Requirement: the requirement for the functions that
the application should do.
￮ Non-functional requirement: the requirement for the
properties that the functions should have or should look like:
- Look n Feel
- Boundary
- Negative
￮ Examples:
“User can login successfully with valid email and password.”
 Lessmore discussion with the whole team.  Used in waterfall
model .
8

9. What is acceptance criteria?
￮ Acceptance criteria are the “conditions that
a software product must satisfy to be accepted by a
user, customer or other stakeholders.” (Microsoft Press)
o Acceptance criteria state the intent of the client and
not the solution.
7

10. The goals of Acceptance Criteria ?
1. TO CLARIFY what the
team should build
before they start work
10
2. TO ENSURE
everyone has a
common
understanding of the
problem
3. TO HELP VERIFY
the Story via
automated tests.
4. TO HELP the
team members
know when the
Story is complete

11. Who Writes Acceptance Criteria
and When?
￮ Either a client or a development team writes
acceptance criteria.
￮ Acceptance criteria should be specified upfront and
never after the development stage has started.
9

12. Creating Acceptance Criteria ?
￮ There are several types of acceptance criteria: rules-
oriented and scenario-oriented.
￮ Scenario-oriented criteria tend to follow the
“Given…When…Then…” template. This was derived
from behavior-driven-development (BDD).
￮ Scenario: Sending message through valid email
address:
- Given The email address is valid
- When The email address is authenticated
- Then The message is sent to the email
address
9

13. 13
What is BDD?
 BDD (Behaviour Driven Development) is a methodology for
developing software through continuous example-based
communication between developers, QAs and BAs.

14. Why choose The Given / When / Then
format?
￮ This format is convenient for humans (since it’s written
in a familiar cause-and-effect manner) as well as for
automated testing tools like Cucumber and RSpec.
￮ The Given/When/Then template helps you reduce the
time spent on writing test cases since you describe the
system’s behaviour upfront.
9

15. What is Test case?
- A test case is a set of conditions or
variables under which a tester will determine
whether a system under test satisfies
requirements or works correctly .
15
- A test that (ideally) executes a single well
defined test object(i.e, a specific behavior of a
feature under a specific condition).
(Testing Computer Software-Kaner ,Faulk
,Nguyen)

16. Why write test case ?
1. Accountability
16
2. Reproducibility 6. To verify that tests
are being executed
correctly
7. To measure test
coverage
3. Tracking
4. Automation
5. To find bugs

17. 17
Test case template
TC ID The ID of the test case.
TC Description The description/ objective of the test case.
Pre-Condition Any prerequisites or preconditions that must be fulfilled prior to executing the test.
Steps Step-by-step procedure to execute the test.
Input data The test data, or links to the test data, that are to be used while conducting the test.
Expected Result The expected result of the test.
Actual result The actual result of the test; to be filled after executing the test.
Status Pass ,Fail , Blocked or Skipped
Build
Sprint Testcase of any sprint?
Test Environment The environment (Hardware/Software/Network) in which the test was executed
Bug_ID Fail or Blocked will have BugID
Note Your comment

18. Design Techniques :
￮ Equivalent Partitioning
￮ Boundary Analysis
￮ State Transition
￮ Constraint Analysis
￮ Condition Combination
9

19. 19
Equivalent Partitioning & Boundary
Analysis
 The program’s specification:
- This program is designed to add two number, which you will enter.
- Each number should be one or two digits.

20. 20
State Transition

21. 21
State Transition
TC No. 1 2 3 4 5 6 7
Login 1st 1st 2nd 2nd 3rd 3rd login 3 times
are wrong,
after 24
hours
Account valid invalid valid invalid valid invalid
Status Login
successfully
Blocked Login
successfully
Blocked Login
successfully
Blocked Login again

22. 22
Constraint Analysis
The value of End Date is constrained Start Date , because
End date can’t be earlier than Start date.

23. 23
Condition Combination

24. 24
Condition Combination
Case Size Color
1 1 Green
2 1 Blue
3 1 Black
4 1 White
5 2 Green
6 2 Blue
7 2 Black
8 2 White
Case Size Color
9 3 Green
10 3 Blue
11 3 Black
12 3 White
13 4 Green
14 4 Blue
15 4 Black
16 4 White

25. Writing Test Cases from
Acceptance Criteria
15
1

26. Visualize the Workflow
15
Example:
What do you see when the user clicks
“Order history” ? What happens when they
click “Add to cart”? If the user clicks the
“Back” button, what is displayed?

27. Create the Happy Path
￮ “Happy path” can cover a large portion of the workflow
and if it doesn’t work smoothly, the rest of your testing
may be blocked. Boundary Analysis
￮ Example :
1. Purchase items from general search
2. Click order history from accounts page
3. Verify previously ordered items are displayed
4. Add items to cart from the previously ordered list
5. Complete purchase of previously ordered items
When the code is delivered for testing, this would be
would execute.
9

28. Negative testing
28
- What are all possible error cases that can
happen?
System issue occurs. What errors are displayed
throughout the website when a system issue
occurs ?
 Create a test case to verify every error is
displayed when it should be.

29. Boundary testing
- How many items from order history should
be displayed?
If it’s not in the acceptance criteria, this
needs to be addressed with the BA or product
owner. The developer may code this to display
all items from a customer’s history but what
happens when a user has an order history of
5,000 items?
 the product owner may decide they need
to create more user stories to add sorting,
filtering and pagination.
29

30. Reference
￮ http://b4usolution.com/news/detail/writing-test-cases-from-user-
story-and-acceptance-criteria/30/
￮ https://blog.testlodge.com/writing-test-cases-from-user-stories-
acceptance-criteria/
￮ https://www.slideshare.net/hoale/writing-test-cases-from-user-
stories-and-acceptance-criteria
￮ https://rubygarage.org/blog/clear-acceptance-criteria-and-why-
its-important
￮ https://itviec.com/blog/agile-la-gi-scrum-la-gi/
￮ https://www.testingexcellence.com/bdd-guidelines-best-practices/
￮ https://www.seguetech.com/8-benefits-of-agile-software-
development/
￮
30

31. THANKS!
31