PR Test and QA review strategy

This documentation includes the testing strategy for each single feature ticket as well as the PROD release. 

Test process for single ticket: 

Ticket status: Work in Progress

When developers are working on a ticket, developers should take the responsibility of that ticket, which includes:

• Understand the requirement in the ticket, discuss with team members if there is any concern or question about the implementation, design, UI etc.
• If this is an api change, add or update the tests in code
• If this is a frontend change and the component is stable that we won't modify it in the near future, write a test. In the case there is no need to write a test at this moment, we still need to think and keep in mind what we need to test, and do it manually
• Run the application locally and test the changes (manually)
  • Do function test for the changes related to the ticket, both success and error cases
    • Make sure it meets the acceptance criteria
    • 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. Link the current and new tickets, also need to put a comment to explain the situation. We can do the adjustment based on the situation for the current ticket, but the changes need to be good enough to go to production, and won't confuse our users
  • Do regression test for the rest of the application, make sure the current change won't impact the existing functionality
• Create a pull request for review, and describe what has been done in the pull request description
• Check Sonar cloud analysis to see if there is any security warnings or code smells
• Check pipeline running for PR opening
• Verify the dev deployment works (same as above when test the application locally)

Ticket status: In Review

When the pull request for the ticket is ready for code review, assign the pull request to another developer to do code review, which includes:

• Code review
  • features and functionalities are implemented to meet acceptance criteria
  • new code keeps the consistency
  • new code is easy to read and understand for long term maintainability
  • documentation is added if need 
  • tests are added if need
• Test in the dev deployment
  • Do function test for the changes related to the ticket
  • Do regression test for the rest of the application

Ticket status: Done (pr merged)

Once PR is approved, the pr owner (developer who opens the pr) needs to merge the PR:

• Check the pipeline running for test deployment
• Verify the test deployment works
  • Do function test for the changes related to the ticket, both success and error cases
  • Do regression test for the rest of the application, make sure the current change won't impact the existing functionality
  • If the ticket is about adding/updating api endpoints, verify the Swagger, make sure the new endpoints are callable and return as expected

When the pull request for the ticket is merged to main branch and deployed to SPAR TEST environment, we will need a developer and a non technical team member to test the TEST environment.

• If the ticket is about frontend changes, or any changes in backend that impact the frontend behaviour, we need one developer (normally the PR reviewer) and one non-technical team member to test the SPAR TEST environment:
  • Make sure the SPAR TEST environment is accessible
  • Do function test for the changes related to the ticket, both success and error cases, and make sure it meets the acceptance criteria and meets the business requirement
  • Do regression test for the rest of the application
  • If find anything need to be fixed or improved, depends on the complexity and priority, either create a new ticket to address or reopen the current ticket for fixes
• If the ticket is about adding/updating api endpoints, one developer (PR reviewer) needs to verify the api in Swagger