Jul 4, 2021
Evaluation From Requirement to User Story / [Software Development Engineer in Test Article Series Part 3]
Warning: Articles may include grammatical mistakes because of my poor English. (This is the last warning. I will not write that warning in the preceding articles. A lot of friends told me that your English is not so bad to write a warning :)
Good news: Anyway, you will understand almost everything about our topic.
This is the third article of my “How to Become a Software Development Engineer in Test” article series. All of these articles have been written in ‘question-answer’ format. As I learned from some of my Filipino friends, this method was developed by Socrates to explain things better. So I hope the techy and non-techy guys will benefit from these articles.
You can find the first article here and the second article here. It is highly recommended to read the previous articles before this one.
Since I have been a software developer for more than 11 years I will provide some sample codes of real and working examples. These code samples originated from mobile applications, desktop applications, web applications, web services and various database procedures as well.
To explain things much better, Lady Q and SorBi are intensively used in my articles as samples.
Lady Q: A businesswoman and client for the SorBi app. She pays money to a software development company to have the SorBi app developed.
SorBi: An android application for creating and sharing polls. SorBi is used as an example in this article series. This app is available on Google Play and it supports English and Turkish languages.
Let’s enjoy learning the exciting stuff of embodying the requirements!
Question: You mentioned a lot of stuff but all of them were kind of abstract. Isn’t it time for starting something tangible?
Answer: Yes, actually it is. At first, we will define the features of Lady Q’s application SORBI. After that, we will define the application requirements. This process is held by Product Owner, Business Analyst (as we indicated in our previous article). Than, we will define user stories for all of the requirements. This process is held by Product Owner. Than we will define Acceptance Criteria related to these requirements.
Q: SORBI is a survey app, right?
A: At first, Lady Q demanded a private android survey application for his company. But after a while she decided to make this app public. At a very basic level she wants a survey application at which users can create surveys and vote surveys mainly based on their interests. Since she changed her mind to have a public application she decided to have the ability to create either private and public surveys. If the user creates a private survey this survey will be available only who has a specific shared link. If the user creates public survey this survey can be viewed and voted by all of the application users.
Q: Cool. It is time to unveil the mystery!
A: Ok. We are so lucky that Lady Q knows exactly what she wants. She wants these features in her poll application SorBi;
- 1. Signing Up
- 2. Logging In
- 3. Logging Out
- 4. Viewing Account Info
- 5. Editing Account
- 6. Adjusting Security Settings
- 7. Account Recovery
- 8. Poll Creation
- 9. Poll Editing
- 10. Viewing Polls
- 11. Voting Poll
- 12. Creating SorBi Profile
- 13. Viewing Own Polls
- 14. Viewing Own Votes
- 15. Selecting Interested Topics From A Category List
- 16. Receiving Instant Notifications
- 17. Adjusting App Settings
Q: Aren’t they too many to handle?
A: They are. Since the Vendor implements Agile Methodology’s most popular framework Scrum, the Scrum Team will handle all these features one by one. As we mentioned earlier Scrum Team will release a very basic product as soon as possible in order to meet the customer needs and get feedback. That’s why Product Owner prioritized all these features and listed them.
As you see the menu there are modules for each feature Lady Q demanded. We can prioritize the features by their dependencies over other features and the urgent needs of Lady Q. We can understand that without providing the Sign Up functionality we can not proceed to the “Log in”, “Log out”, “Account Info”, etc. Because they are all dependent on user information and we can get that info only by the Sign Up functionality.
Q: Someone has to make some definitions for the development team. How can they know what they will do?
A: Think about Sign Up module.
As you said someone must explain this Sign Up feature; Product Owner. PO creates requirements based on the customer needs. These are the Requirements of The Feature Sign Up (ft. 1):
- Rq. 1/ft. 1: Users should sign up and create user account.
- Rq. 2/ft. 1: Users should provide a unique username and password to sign up.
- Rq. 3/ft. 1: Users should be directed to ‘Sign Up’ module by tapping the member-only menus.
- Rq. 4/ft. 1: Users should view a text that explains the benefits of being a member.
Q: That is so simple. Isn’t it?
A: Yes, but not clear and specific enough. These requirements must be specified by user stories to explain the details. PO writes user stories and prioritizes them. Than, mostly in Grooming Meeting, the Scrum Team evaluates the user stories and give them points by their complexity and regarding the developer team’s capacity and velocity.
This is the user story of Requirement 1 (Users should sign up and create user account):
As a user, I want to be able to create an account by signing up with only an username and password, so that I will be a member and I can access member related contents.
Q: Yea buddy. It is much more detailed now. The developers must be satisfied with that detailed explanation.
A: Actually, they wouldn’t. They need something more to understand that they are on the right way. They want to understand wheter the story is completed and works as expected.
Q: Than we need some criteria to meet and evaluate the user story is done or not. What is that?
A: That is Acceptance Criteria (AC). As you indicated we need them to evaluate the user story if it is done or not. They are unique for each user story.
AC are the conditions that SorBi must meet to be accepted by the PO. AC define the feature behavior from the end-user’s perspective.
These are the acceptance criteria of the user story above:
- On the main menu there must be a Sign Up button for users.
- By tapping that button Sign Up screen must be opened.
- On the Sign Up Screen there must be a username and password areas.
- On the Sign Up Screen there must be a cancel button.
Q: That’s it. That’s why I love Scrum. As a developer you know what to do and how to do. As a tester you know what to test and how to test. As a Scrum Team you know the priorities and how to satisfy the customer. Aren’t there more user stories? They are so crazy!
A: Even if the screen looks very simple, there are always a lot of things to do. These are the other user stories and related acceptance criteria of the Sign Up feature:
Requirement 2/ft 1: Users should provide a unique username and password to sign up.
User Stories:
As a user I want to be able to have a unique username, so that I will be differentiated from other users.
As a user I want to be able to define a secure password, so that my account remains safe.
Acceptance Criteria:
- On the Sign Up Screen, provided username must be checked if it exist in database.
- Password must be at least 4 characters and white space must not be allowed.
- User must be informed about the security measures related to username and password policy
- User should be able to access the “Membership Agreement”, “Privacy and Cookie Policy”, “Enlightenment And Consent Text”.
- User must not become a member without accepting these three documents.
- Password must be saved to database in an encrypted format, it must not be saved as clear text. The encryption must be done at client side.
- Password and username must be sent to server over htpps protocol.
- A unique user id must be generated randomly at the database server.
Requirement 3/ft 1: Users should be directed to ‘Sign Up’ module by tapping the member-only menus.
User Stories:
As a user I want to know which content is member-only, so that I will be informed about the app system.
As a user I want to be directed to Sign Up screen upon tapping the member-only menus, so that I can easily access the Sign Up module.
Acceptance Criteria:
- On the main menu, if a visitor taps member-only menu item, he/she must be warned about the content is only for members.
- With that warning the visitor must have the opportunity to be directed to Sign Up module.
Requirement 4/ft 1: Users should view a text that explains the benefits of being a member.
User Stories:
As a user I want to know why I have to be a member, so that it will be more encouraging me to be a member.
As a user I want to be informed about the ‘benefits of being a member’, so that I will be encouraged to create an account.
Acceptance Criteria:
- On the Sign Up screen there will be information button about ‘benefits of being a member’.
- By tapping that button user must be informed about that by a popup text .
- Visitors must be reminded about ‘benefits of being a user’ for every vote they perform.
Q: There are a lot of things to do. I guess there must be something great at the underlying system. Can you explain?
A: I can, but it is too much to explain now. In the future session, I will show all the related codes about Sign Up feature. Be patient!
PS: Further reading about AC.
Real life example:
User Story: (My son says) As a son I want you to buy me and my friend ice-cream, so that we feel ready to go to bazaar with you. (Kinda bribery☺)
AC: Dad must buy ice-cream to us.
You can read the next article Data Flow From Frontend To Backend here.
