Elaboration
TBD
Triage, and definition of the ticket
On a sprint Board, all tickets that are not in the current sprint are in this stage
To Do
Task is well defined, and ready for Development, should be enough to form an idea as to what and how the story shall be developed
Stories broken down to single piece of functionality, minimum dependencies, isolated part of the application
Stories should have Acceptance Criteria,
Defect reproduction steps
Stories need to be testable and reviewed by our Test team
On Hold
An issue has come up and work on the issue can not proceed.
Comment needs to be added why ticket is on hold, ticket assigned to person who can take it off hold.
In Progress
Confirm with a BA (or Tester if no BA available) understanding of the task, and the confirmations / tests required to verify completeness.
Create a branch for the work using the Branching strategy (add link)
Write code to implement feature or fix bug, as per relevant coding standard (add link) and non-functional project requirement
Write unit tests to ensure code is working as expected
Update the JIRA ticket with comments, and ensure tickets are in correct state and assigned
Write/Update any documentation relevant to the task
Update the CI process if required: eg: Set configuration values for specific environments
Commit Messages
As good practice, all commit messages should contain at a minimum the JIRA ticket number and a short description of the changes made. (https://chris.beams.io/posts/git-commit/)
**Example: **
|
EP-1 Add tests for add patient consumer.
|
Bad Examples:
|
fix bug
|
|
.
|
Shoulder Check
Phase 1 - Peer Demo
- A review of the JIRA ticket(s) to be commited
- A quick demo/review of what has been completed as part of the in progress step. (No need to demo all edge cases)
- Ask peer (Developer or BA) to check all acceptance criteria has been met.
- If front end work ask designer for feedback about look and feel and if the implementation is as per design.
Phase 2 - Pull Request
At least 1 developer not involved in Development of the work in PR, or Peer Demo should review each PR.
- Open ticket in JIRA and review the objective of the commit.
- Check code changes made achieve the objective of the JIRA ticket.
- Developer to review all code, scripts, and files that are part of the commit.
Things to lookout for:
- DbUp scripts are set to embedded resources
- Changes made XVT.Core projects; particularly changes to interfaces
- Projects that create Nuget packages have the package version bumped up
- No configuration changes are made that will negatively affect other team members, eg: changing connection strings, username, passwords. (developer environments should be consistent)
- Code and Scripts are in line with XVT standards (03 - Coding Standards)
- Raise possible defects with the developer, add comments and discussion
- The developer should reply to all comments, something simple is fine eg: fixed, done;
- If a comment is added to the PR, the reviewer should also mark the PR as approved or declined.
- Ideally, all reviewers should approve before PR is commited
- Check tests have been written, and describe the purpose of the code written
- we don't need 100% coverage, but the more coverage the better.
- Tests should not be dependent on being run in a particular environment, or on any configuration that is not set as part of the test itself
- If it appears that Continuous Integration changes is required, check with developer they have made the change in the build/deployment pipeline
- Review documentation created/updated for the task
Check build was successful in Bamboo
Phase 3
- Merge pull request created in the Shoulder Check Phase, and Delete source branch
- Will be great if we can test feature branches then merge to develop after testing has passed
- Test on Integration environment after deployment
- Make sure that the commit has been deployed and not just built. This may take some time if there is a lot of activity in the integration environment
Ready for Testing
Development work is completed, and team members have agreed the work meets all the requirements. (tested in integration)
Write test case if required.
Write automated test cases where appropriate.
Deploy to QA environment
Testing
Create and record Test sessions for all Test Cases, if required.
Verify all requirements are met and no exceptions happen on edge cases.
If testing fails, notify developer and move ticket back to in progress; assign back to developer.
Review (Client Approval)
TBD
Done
All items above have been completed, and the story/bug has been merged into a branch ready for deployment.
Ticket is defect-free (or as close as we can humanly manage)