-
Notifications
You must be signed in to change notification settings - Fork 0
Testing Plan and Continuous Integration
Discuss how you will test your system.
Discuss continuous integration strategy.
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.
- 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.
- Follow the steps to reproduce the bug. These steps are provided in the bug report issue.
-
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.
- If not the case, add a comment to the PR and discuss the differences.
- If changes were made, repeat steps 1 to 3 to ensure the code follows the expected behavior.
- Approve the pull request by leaving a comment. The comment should include the match in behavior between the tested one and the expected one.
- 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.
-
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.
-
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.
- Tests should cover 80% of the new code.
- Verify that they cover the main edge cases.
- 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.
Simulation Meeting Minutes
Frontend Meeting Minutes
Backend Meeting Minutes
Risks
User Consent and End-User License Agreement
Legal and Ethical Issues
Economic
Budget
Personas
Diversity Statement
Overall Architecture and Class Diagrams
Infrastructure and Tools
Name Conventions
Testing Plan and Continuous Integration
Security
Performance
Deployment Plan and Infrastructure
Missing Knowledge and Independent Learning
Glossary
Mockups
UI Evolution
Logging
Metrics
VeloSim Observability & Performance Insights
User Manual
Usability Tests