Please note that all items in checklist marked with [M] are mandatory.
Checklist | Feature/User Story | Sprint Demo/Review | Release | |
| [M] | Unit tests are written and are passing. At least 80% code coverage is expected and 100% is preferred for critical code. | Y | ||
| [M] | Pull requests for all Spitfire modules are created following existing template in folio.org and contain a .gif of feature implemented where it's appropriate | Y | ||
| [M] | Peer code review is performed and Spitfire team(front-end/back-end) is requested for code review; code can be merged to master only when build passes and after at least 2 peer approvals | 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. | 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 – 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 |