This documentation is to give in detail the standards and work flow of Wicresoft NA. These standards and work flow are to help QA and Developers in maintaining a efficient and clean backlog. In following this documentation will help the product team with weekly soft delivery, monthly product version release and product road map.
Backlog Work Flow
"Bug" and "User" Story Request
| States | Status |
|---|---|
| New | New |
| Active | Approved |
| Resolved | Fixed |
| Ready For QA | Deployed to QA Environment |
| Ready For Regression | In Regression Cycle |
| Closed | QA Approved |
Below is a info graph of the product team's backlog work flow for Bug request.
- The User will enter a bug request into the backlog.
- State = New
- Status = New
- Developer reviews the request and if it is not reproducible, he/she sets the request to "Not Reproducible" and sends it back to requester. If both party agrees, requester will note the request with comment and set backlog request to "Closed".
- Developer reviews the request and determines that it is a valid issue.
- Developer moves the state from "New" --> "Active" and the status from "New" --> "Approved".
- Once the developer completes the request and a fix is checked into code branch, he/she will change the state from "Active" --> "Resolved". The status moves from "Approved" --> "Fixed".
- Developer will perform a pull request to have his/her code to be peer reviewed.
- Once peer review completes, the developers code is integrated into the QA branch and the senior developer initiate build process to create a new build.
- Once build completes, system auto deploys code to QA environment.
- Developer proceed to change the status of bug from "Resolved" --> "Ready For QA" and status is moved from "Fixed" --> "Deployed to QA Environment".
- Developer notifies QA that deployment is successful.
- QA proceeds to test fix.
- If test fails, QA notifies developer and change status back from "Ready For QA" --> "Active".
- From here the cycle cycles back to Step 4.
- If test fails, QA notifies developer and change status back from "Ready For QA" --> "Active".
- If test passes, QA moves the state from "Ready For QA" --> "Closed".
Entering a "Bug" into VSTS backlog
When entering a "Bug" backlog request, the following fields are required:
Refer to screen shot above for reference.
- Enter Title: <Title of your Bug>
- Repro Steps: <Detail reproduction steps>
- System Info: <Information regarding environment>
- Priority: <Set Priority Level>
- Severity: <Set Severity Level>
- Customer: <Enter name of customer if customer related>
- Soft Release: <Enter Soft Release Date after code has been released to QA>
- Planned Release: <Enter Planned Release Date>
Guidelines To writing A Backlog Request
User Story Titles
A user story is a behavior or feature that a solution needs to implement in order to fulfil the needs of a user.
The proposed formats for user story titles are:
- As <a> <persona/type of user>, I want <something> so that <some reason> (e.g. As Sam Spendsalot, I want to one-click purchase so that I can get my goods as quickly as possible)
- As a <persona/type of user>, I want <something> (e.g. As a User, I want to create a task)
- <persona/type of user> <performs action on> <thing> (e.g. User visits home page OR User creates a task)
Bug Titles
A bug is a problem that impairs a product or service’s functionality.
The proposed formats for bug titles are:
- <person/type of user> can’t <perform action/get result they should be able to> (e.g. New User can’t view home screen)
- When <performing some action/event occurs>, the <system feature> doesn’t work
- When <persona/type of user> <performs some action>, the <system feature> doesn’t work
- <system feature> doesn’t work
- <system feature> should <expected behaviour> but doesn’t
- <system feature> <is not/does not> <expected behaviour>
- <persona/user type> <gets result> but should <get different result>
- <quick name>. <one of the formats above> (e.g. “Broken button. New User can’t click the Next button on Step 2 of the Wizard”).
The bug title formats are based on our analysis of close to 5,000 tasks across a few different organisations, projects and teams.
Task Titles
A task is an activity that needs to be performed that doesn’t fall into one of the other task types. This is often something the team has to do but doesn’t result in code.
The proposed formats for task titles are:
- <verb/action> <activity> (e.g. “Perform backup”)
- <verb/action> <thing> (e.g. “Research new javascript framework”)
These formats are also based on our analysis of raw data.
New Feature Titles
This type of task is mostly used with services or components that are somewhat removed from the end user, such as API endpoints.
The proposed title formats for new features are:
- Implement <endpoint> (e.g. Implement POST /api/v1/users)
- Create endpoint <endpoint> (e.g. Create endpoint POST /api/v1/users)