Skip to content

Testing Plan and Continuous Integration

Sumer edited this page Sep 22, 2025 · 8 revisions

System Testing Method

Discuss how you will test your system.

Continuous Integration Strategy

Discuss continuous integration strategy.

Code Review Process

Each pull request will require at least two code reviews and approvals to be considered completed before merging. Thanks to the codeowners file, as explained previously, at least one of the final approvals must be a member of the same sub-team as the branch subsystem (e.g. a PR under a branch from the sim subsystem would require at least one review/approval from a member in the sim team).

Pull requests have been separated into two categories: bug fix and regular PR. The code review process both types must be followed by the team before the pull request can be approved.

Bug Fix PRs

  1. Access the bug issue referenced on the PR. Each bug fix PR should have a reference to a bug report issue in the Related Issues section. It is important to understand what problem is being fixed.
  2. Follow the steps to reproduce the bug. These steps are provided in the bug report issue.
  3. Ensure the steps result to the bug issue's expected behavior. The fix should have resolved the bug and resulted in the expected behavior as described.
    1. If not the case, add a comment to the PR and discuss the differences.
    2. If changes were made, repeat steps 1 to 3 to ensure the code follows the expected behavior.
  4. Approve the pull request by leaving a comment. The comment should include the match in behavior between the tested one and the expected one.

General PRs

  1. Access the referenced task issue and its user story issue on the PR. Each PR should have a reference to a task issue in the Related Issues section.
  2. Cross-check the behavior/UI of the code against its AC/mockups. Ensure the pushed feature looks and behaves as intended through the task issue.
    • If not the case, add a comment to the PR and discuss the differences.
  3. Verify the unit tests written. The written test cases should be effective in testing the new feature and cover it properly to ensure the quality of the code.
    1. Tests should cover 80% of the new code.
    2. Verify that they cover the main edge cases.
  4. Approve the pull request by leaving a comment. The comment should include the validation of the code's behavior and UI, as well as an approval of the written tests.

Clone this wiki locally