4. Launching the next action

Possible outcomes from testing:

• If (a) it means the piece of code is deemed to be working correctly, and it can be 'pushed to production'. This means it will become part of the live, publicly used software and will be implemented on all instances. To tell the developers that accredited to merge that your tests are good and they can merge, just move the card to the "Ready to go" column or change the pipeline in the PR to "Ready to go".

• If (b) it means the developer needs to do some more work to fix the remaining issues. Then move the card back to the "In dev" column or change the pipeline in the PR to "In dev". When he/she will have re-worked on it, he will submit modifications that will need again to be reviewed by other developers before they can be "ready to test" again.

• If (c) you're not sure, ping the developer and ask them to take a look at the testing notes to determine whether it's ready to go or not. Labeling the respective pull-request with the "feedback-needed" label is a good idea as well.

Some additional considerations:

• When testers are noticing bugs that are already in production, they should always create a new issue, except if the PR they are testing is making things worse. For example, the tester verifies that what the PR introduces is working but while testing finds another bug:

  • If this bug is already in production, the tester shouldn't hold the PR responsible - he should open a new issue.

  • If the PR is introducing a new bug or making the current bug in production worse - then the PR should be moved back to "In dev" adding all the necessary notes, as described in section 3.

• If the PR being tested does not introduce a bug, and does not solve or only solves the issue partially but brings any other improvement - like a dependency upgrade, or other benefits - then it should be merged to production. In this case, the underlying issue remains open and may be closed later, by another PR.