Please note that all items in the checklist marked with [M] are mandatory.
...
Checklist | Feature/User Story | Sprint Demo/Review | Release | ||||||||
| [M] | Unit tests are written and are passingpassed. At least 80% code coverage is expected and 100% is preferred for critical code. | Y | |||||||||
| [M] | Pull requests for all Spitfire modules should follow the rules:
| Y | [M]
Assign @folio-org/spitfire-backend or @folio-org/spitfire-frontend as reviewers when the build passes successfully and PR is ready
| Y | |||||||
| [M] | Peer code review for non-Spitfire modules should include the Dev Lead of the team that owns this module according to Team vs module responsibility matrix. Dev Lead(or his substitute person in case of absence) approval is required(maybe some exception like for the data-import feature).Example: TBD Natalia Zaitseva | Y | |||||||||
| [M] | Fix reported code smells, security vulnerabilities, check style issues(by checkstyle maven plugin), lint errors that are reported by Sonarqube and other tools in CI pipeline before merging code to master | Y | |||||||||
| [M] | Existing Karate tests (backend modules) and Integration tests (UI modules) are maintained/implemented/improved and pass | Y | |||||||||
| [M] | Any configuration and/or build scripts are updated and tested | Y | |||||||||
| [M] | Build deployed successfully to the snapshot-stable environment(test, integration etc.) | Y | |||||||||
| [M] | QA is performed and issues resolved - Test-cases are created in "Testrail" against acceptance criteria. | Y | [M] | Feature implemented meets acceptance criteria defined by PO/TL | Y | ||||||
Regression tests pass – a future requirement | Y | ||||||||||
| [M] | Data migration scripts are implemented for schema changes | Y | |||||||||
| [M] | Verify that PII stored is encrypted | Y | |||||||||
| [M] | Verify compliance with GDPR – future requirement | Y | |||||||||
| [M] | Feature OK’ed by UX and complies with: - https://ux.folio.org/docs/guidelines/ - WCAG 2.0 Level AA accessibility compliance | Y | |||||||||
| [M] | Feature is accepted by PO-
| Y | |||||||||
| [M] | Localization is taken care of in application code | Y | |||||||||
| [M] | User documentation updated - README.md, response example files etc. | Y | |||||||||
| [M] | Any bug created, should have a "RCA group" value | Y | |||||||||
| [M] | No open critical bugs on any user stories | Y | |||||||||
| [M] | DoD of each user story, included in demo are met | Y | |||||||||
| [M] | All demoable features are demoed from the same shared environment – For most demos, this will be FOLIO integration environment | Y | |||||||||
| [M] | Releases are created following: https://dev.folio.org/guidelines/release-procedures/ | Y | |||||||||
| [M] | Installation and deployment scripts are updated | Y | |||||||||
| Actualise performance tests for backend modules and run them before schema upgrade testing during release | Y | ||||||||||
| [M] | Performance tests are created and pass – Example: All end-user interactions < 2 seconds for 95 percentile or no degradation in response time for existing functionality | Y | |||||||||
| [M] | All bugs reported by QA, manual testing, UAT, PO etc. are fixed | Y | |||||||||
| [M] | Release notes are created/updated | Y | |||||||||
| [M] | User documentation updated (deployment documentation, scripts/packaging etc.) | Y | |||||||||
| [M] | User documentation is localized | Y |
...