Document how developers test their own pr and how team do QA test before go production

[MCatherine1994]

Describe the task Have a team agreement on how developers should test their own prs, and support each other for pr review, and check pipeline status, test in dev. And have a team agreement on how our team do QA test before go production.

Acceptance Criteria

• [x] Document developers' test process for their prs
• [x] Document team QA process
• [ ] Include in developer guide

Additional context

• Add any other context about the task here.
• Or here

[MCatherine1994]

Developers should take the responsibility of their ticket (In Progress):

• Understand the requirement
• Discuss with team members if there is any concern or question about the implementation, design, UI etc.
• If this is an api change, add/update unit tests in code
• If this is a frontend change and the component is stable that we won't modify it in near future, write an integration test
• In the case there is no need to write a test case at this moment, we still need to think and keep in mind what we need to test, and do it manually
• Test the changes locally
  • Test the changes related to the ticket, both success and error cases
  • Make sure it aligns with the design
  • If in any case we feel the scope of the ticket increases, could always create a follow up ticket to address. But for the current ticket, we can do adjustment based on the situation, but the changes still need to be good enough to go to production, and won't confuse our users.
  • Test the rest of the application, make sure the current change won't impact the existing functionality
• Create the pr for review
• Check Sonar cloud analysis
• Check pipeline running for pr opening (Continuous Integration Infrastructure, Auth function artifact, SonarCloud analysis, Lint PR)
• Once pr is approved, merge the pr, check the pipeline running for dev deployment (DEPLOY Development Environment, Continuous Integration Infrastructure, Auth function artifact, release-please, SonarCloud analysis)
• Test in dev environment
  • Test the changes related to the ticket, both success and error cases
  • Test the rest of the application, make sure the current change won't impact the existing functionality

Developer pr review process (Code Review):

• Code review
• Test locally if need

Team review process for single ticket (Review/QA):

• one developer (normally pr reviewer) needs to check the dev environment
• one non-technical team member needs to check the dev environment if the ticket is about frontend changes, or any changes in backend that impact frontend behaviour

Team review process for prod release:

• If team decided to publish a release in prod environment, deploy the latest code to TEST environment. Try to break the application
  • at least one developer needs to check the TEST environment
  • PO (I feel PO should check it before go to prod? but maybe we could have another person) needs to check the TEST environment
• Once we done the prod release
  • at least one developer needs to check the PROD environment (normally who did the release will check)
  • PO needs to check the PROD environment

[MCatherine1994]

geo restriction for doing test in DEV env

[MCatherine1994]

Todo:

• [x] rename the title so it aligns the Zenhub board
• [x] add documentation for which pipeline needs to check at each step (pr open, pr merge, release)
• [x] what we do for unit, integrate test in code

[MCatherine1994]

Updated documentation is added at: https://apps.nrs.gov.bc.ca/int/confluence/display/FSAST1/PR+Test+and+QA+review+strategy

[gormless87]

@MCatherine1994 - the writeup looks good.

The third AC is to 'Include in developer guide'; do we want to move the page there? Also, do we want to include the 'Secure design & Coding Practices' page under the developer guide?