Acceptance Criteria - Sample
Acceptance Criteria - Sample
Acceptance Criteria - Sample
Precondition:
Guest taps the Sign up option on the Sign in screen
Guest is on the Sign up screen
Description:
Sign up screen has the following items:
Back option
Title “Sign up”
Email field (input, required)
Password field with show/hide option (input, required)
Confirm password field with show/hide option (input, required)
“Checkbox” with the description “By continuing, you agree to “Terms of
Use” (option) and “Privacy Policy” (option)” (required)
Sign up button
Text “Already have an account?” Sign in option
#1
Scenario: Appearing of show/hide option
When: Guest begins to fill in the password / confirm password fields
Then: Show/hide option appears
#2
Scenario: Navigate to Sign in screen
When: Guest taps on Sign in option
Then: Guest should navigate to the Sign in screen
#3
Scenario: Guest fills in valid credentials
When: Guest fills in email + password + confirm password fields and checkboxes
with valid data
And: taps on Sign up button
Then: The account is created in the system
And: Email with Verification link should be sent to the specified email address
And: Patient status “New” is set
And: Guest should navigate to the “Verify your email” screen
Scenario
When: Guest doesn't fill in required fields
And: taps on Sign in button
Then: “All fields are required” error message displays
#6
Scenario
When: Guest enters invalid password
And: taps on Sign in button
Then: “The password should be from 8 to 50 symbols. At least 1 letter, 1 digit, and
1 capital letter. No space allowed.” error message displays
#7
Scenario
When: Guest enters password + confirm password fields
And: taps on Sign in button
And: password don’t match
Then: “Password don’t match” error message displays
#8
Scenario: Account already exists
When: Guest enters an email that is currently in use
And: taps on Sign up button
Then: “User with this email already exists” alert displays
#9
Scenario: Close the alert
When: Patient taps on the Close button
Then: Alert is closed
Implementation notes:
Password field should contain a prompt with the text: “The password should
be from 8 to 50 symbols. At least 1 letter, 1 digit, and 1 capital letter. No
space allowed.”
In case Guest fills in email / password fields and taps on Sign in option -
Guest’s data is not saved.
SIGN IN
Precondition:
Patient is on the Sign in screen
Description:
Sign in screen has following items:
Title “Sign in”
Email field (input, required)
Password field with show/hide option (input, required)
Sign in button
Forgot password option
Text “Don’t have an account?” Sign up option
#1
Scenario: Appearing of show/hide option
When: Guest begins to fill in the password / confirm password fields
Then: Show/hide option appears
#2
Scenario: Navigate to Sign up screen
When: Patient taps on Sign up option
Then: Patient should navigate to the Sign up screen
#3
Scenario: Patient fills in correct credentials
When: Patient enters valid email + password
And: Taps Sign in button
Then: Patient is signed in
And: Home tab should be opened
#4
Scenario: Patient fills in incorrect credentials
When: Patient enters invalid email + password / invalid email only / invalid
password only
And: Taps on the Sign in button
Then: “Invalid credentials. Please try again” alert displays
#5
Scenario: Close the alert
When: Patient taps on the Close button
Then: Alert is closed
Booking
Preconditions:
Patient is on the Provider Details screen
Description:
#1
Scenario
Given: Patient is on the Provider Details screen
When: Patient taps the “Book an appointment” button
Then: Calendar of a specific Provider screen should be opened. It consists of:
A title “Provider Name”;
Back option;
“Select date” section with a Calendar. It consist of:
<Previous> <Next> month options;
Month Calendar grid;
“Select time” section with:
Available time slots for appointment booking;
“Confirm date” button.
#2
Scenario
When: Patient taps the Back option
Then: Patient should navigate back to the Provider Details screen
And: Changes is not saved
#3
Scenario
When: The day is Today
Then: It must be labeled on the Month Calendar
#4
Scenario
When: Patient taps the <Previous> option
Then: The previous month’s availability should be displayed
#5
Scenario
When: Patient taps the <Next> option
Then: The next month’s availability should be displayed
#6
Scenario
When: Patient taps the Busy slot
Then: The text “No appointments for this date” is shown
#7
Scenario
When: Patient taps the Free slot
Then: Available time slots should be displayed on the Select time section
#8
Scenario
When: Patient does not choose a day for booking
Then: The text “Select a day first” is shown
#9
Scenario
When: Patient choose the day
And: Select time slot
Then: “Confirm date” button becomes enable
#10
Scenario
When: Patient does not select available time slot for chosen day
Then: “Confirm date” button is disabled
Implementation notes:
The "Current" month on a Month Calendar is open by default;
Busy slots - the days which not available for booking;
Free slots - the days available for booking.
CHAT
Preconditions:
Patient Liaison (Admin) taps the “Chat” option in the navigation bar
Description:
“Chat” page opens. It consists of:
A title “Chat”
“Patients” tab open by default (with a counter of unread messages)
“Providers” tab (with a counter of unread messages)
#1
Scenario
When: There are more than 100 unread messages in the “Patients” tab
Then: Counter of unread messages should be shown as 100+
#2
Scenario
When: The chat is newly created
And: There are no messages yet
Then: The dialog card should contain Patient name and avatar only
And: The text “Start a chat”
Implementation notes:
“Patients” tab opens by default;
In case Patient Liaison doesn’t select any chat, then the text “Select a
participant to start a chat” shown
The dialogues in the list are sorted by the time of last update, newest at the
top;
Last active chats should be pushed to the top of the chats list;
LINK
Preconditions:
Email with Verification link was sent
Description:
#1
Scenario:
When: Guest opens a verification link
Then: Guest’s email address is verified
And: Guest should navigate to the app
And: “Your email address has been successfully verified!” pop up displays
#2
Scenario: Close the pop-up
When: Guest taps “Ok” option
Then: The pop-up should is closed
And: Guest should navigate to the Complete Profile screen
Implementation notes:
Verification link lifetime 24 hours.
GOOGLE SIGN UP
Precondition:
Guest is on Sign up page
Initial state:
Sign up page consists of:
- “Sign up to SuperFam” title
- Sign up with Google button
- Sign up with Facebook button
- Sign up with MetaMask button
- Email address input field (required)
- Create password input field (required) + show/hide password icon
- Confirm password field (required) + show/hide password icon
- I accept Terms of Use and Privacy Policy checkbox (required) + link to appropriate pages
- Sign up button
- “Already have an account?” line with the link to Sign in page
UI
Sign up
Scenarios:
#1
Scenario: Sign up with Google without existing account in the system
Given Guest is on Sign up page
When Guest clicks Sign up with Google button
And goes through Google native authorisation form
And Guest uses Google account with an user id that doesn't exist in the system's database
Then Guest is signed up
And redirected to My profile page
#2
Scenario: Successful Sign up with Google with existing account
Given Guest is on Sign up page
When Guest clicks Sign up with Google button
And goes through Google native authorisation form
And Guest uses Google account with an user id that exists in the system's database
Then Guest is signed in to account
And redirected to Feed page
#3
Scenario: Successful accounts merging
Given Guest is on Sign up page
When Guest clicks Sign up with Google button
And goes through Google native authorisation form
And Guest uses Google account with email that exists in the system's database for another
account
And existing account has verified email
Then accounts are merged
And Guest is signed in to account
And redirected to Feed page
#4
Scenario: Unsuccessful accounts merging
Given Guest is on Sign up page
When Guest clicks Sign up with Google button
And goes through Google native authorisation form
And Guest uses Google account with email that exists in the system's database for another
account
And existing account has unverified email
Then Guest is signed up
And redirected to My profile page
Implementation notes
Data to fetch from Google:
Avatar,
First name,
Last name,
Email
PAYMENT
Scenarios:
#1
Scenario: Redirect to Complete payment page, one-time payment and subscription
Given post of another creator is shown
And it is locked
And post is available by subscription and one-time payment
When Creator clicks Purchase post option
And One-time payment option is chosen by default
And he is redirected to Complete payment page in one-time payment and subscription state
Then Payment amount input field prefilled with post price
#2
Scenario: Redirect to Complete payment page, one-time payment only
Given post of another creator is shown
And it is locked
And post is available by one-time payment only
When Creator clicks Purchase post option
And he is redirected to Complete payment page in one-time payment state
Then Payment amount input field prefilled with post price
Scenarios 2-4 reuse US-16.1 As a Creator I want to donate to creator in USD so that I could
support him financially
Implementation notes
Post content should be unlocked on appropriate page after purchasing
3D secure implementation required for payments conducted with Stripe
For fiat payments Superfam takes 10% fee of subscription/post price or donation amount paid by
buyer
LIST
Scenarios:
#1
Scenario: View empty Posts & Donations tab
Given Creator is on any page
And he has not donated yet
When he clicks on his avatar in the header
And clicks My purchases option in the dropdown
And clicks on Posts & Donations tab
Then Posts & Donations tab is shown in empty state
#2
Scenario: View filled Posts & Donations tab
Given Creator is on any page
And he donated at least once
When he clicks on his avatar in the header
And clicks My purchases option in the dropdown
And clicks on Posts & Donations tab
Then donations are shown on Posts & Donations tab (filled state)
Implementation notes
Purchase date should be updated after each payment in case of recurrent subscriptions
12 items in the table per page
Default sorting by purchase date (new on the top)
Limit-Offset pagination should be used
Dates should correspond to user’s timezone offset
Transaction History
Scenarios:
#1
Scenario: View filled list of transactions
Given Superadmin is on any page
When Superadmin clicks on Transactions history option in the sidebar
And at least one blockchain transaction exists
And he is redirected to Transactions history page
Then Blockchain transactions tab is shown in filled state
#2
Scenario: View empty list of transactions
Given Superadmin is on any page
When Superadmin clicks on Transactions history option in the sidebar
And no blockchain transactions exist
And he is redirected to Transactions history page
Then Blockchain transactions tab is shown in empty state
Implementation notes
12 items in the table per page
Default sorting by date (new on the top)
Cursor pagination should be used
Notification
Scenario: Email is already verified using social network
Given Email verification link has been sent to Guest’s email
When Guest follows a verification link
And there is already registered account via Google or Facebook with connected email
Then Guest is redirected to Sign in page
And notification “Your email address has been already confirmed” is shown
Implementation notes
Verification link lifetime 24 hours
Once email is verified referral link for the account should be generated
Trigger:
Creator’s subscription has expired
Description:
Email should be sent:
Kind regards,
Superfam team.
Expected result:
Email is sent to Creator