-
Notifications
You must be signed in to change notification settings - Fork 100
Workflow
Yusuf Abdallah edited this page Oct 13, 2023
·
11 revisions
- The splitting phase for user stories should happen in the backlog @Marta @Pablo @Jaime @Jose, ideally all related user story should be under an “epic” and in this phase of splitting we can start thinking things about testing in a higher level (do we need access to a bigger db in specific server to test this?, stress tests?) and work on enabling these things. If during analysis someone detects that a user story might be too big and can be splitted so that multiple devs can work in parallel, let the team know this.
- Tickets should never have empty description or zero info about how to test them, think that another developer will test it, having notes, description, what have been “add/modify” in the code, adding info about corner cases etc.. will help a lot to identify bugs in earlier stages. This should be done in the analysis column.
- Analysis phase : Scheduled meeting with Quadram.
- When someone is testing a ticket if a bug is found, we should add a flag to the jira ticket and comments explaining to the developer what has been * found. With the jira flag, it’s very easy to identify visually which tickets contain bugs.
- Everytime a developer finishes a ticket that was in progress, instead of starting to develop another ticket. We should always look at the right side of the board, this means that the developer should help in the “In review” column. The tickets that are in “In review” are close to finishing the development cycle and therefore more likely to be included in the sprint/release, on top of this we’ll be avoiding bottleneck in the “In review” column.
- After the “code review” of a ticket has finished, the next state is “testing”. Here the developer will test the ticket and later assign it to nancy.
- The user in charge of the testing phase must merge the PR if everything is fine and there is no conflicts. Otherwise, the dev that opened the PR should be noticed.
Planned - Analysis - Ready to start - Needs check - In progress - In review - Testing
In this step, the owner has read and understand the issue checking that Description, Requirements and Acceptance criteria panels are clear enough. If not, try to complete it by gathering information asking to the reporter and researching in order to have a clear understanding of the scope and the expected result. Once the issue scope is clear, complete the rest of panels. The testing panel are the steps that the developers and testers needs to follow in order to validate that the issue meets all the requirements:
- Server url: Fill server, program and credentials information if the issue needs specific preconditions to be reproduced.
- Test cases: Add specific steps to test the feature, keep in account corner and non straight cases.
- Test cycles: This is an exercise to understand the implications of a development trying to add the testing cycles that the development might impact.
- Possible side effects to take into account:
Pull request
- Before opening a PR make sure that you:
- Cover all new and modified code with Unit tests even more if the code has any logic.
- Run ktlint autoformatting.
- Perform a self review of your code.
- Execute and test your own issue.
- Every developer that opens a PR has the ownership for merging it and also checking that git submodules are not being broken. In addition to this, he should take care of the comments written in his PR and not forget about it, so that the PR is not dead waiting.
- He should merge ONLY when all reviewers approved the PR, the PR has tests and CI gives green check (not your laptop/pc). A PR should never be merged with red CI.
- If a reviewer suggests comments, the PR should also be reviewed after the owner made the changes.
- If CI is broken when merging the PR, the dev who merge has to fix it (if he is the one who breaks it). It’s not an option to work with a red CI.
- For code reviews and responding comments please follow the guidelines
Code reviews
- Reviewer script will set external variables with the slack usernames of the reviewers. Then, the slack message will tag them.
- APK train leaves on Friday at 15:00, if an issue has not been merged by that time it will have to wait till next week.
- By default the work context won’t be broken unless self-decided or by team consensus
- On the days before the release the team can decide to be more or less strict with the above points