Please note that all items in checklist marked with [M] are mandatory.
...
Checklist | Feature/User Story | Sprint Demo/Review | Release | Notes |
[M] Unit tests (backend: jUnit, RestAssured, frontend: BigTest) are written and are passing. At least 80% code coverage is expected and 100% is preferred for critical code. | Y | Needed | ||
[M] Sample and reference data is updated to match the feature or schema change. Any configuration and/or build scripts are updated and tested. | Y | Needed | ||
| [M] Scripts to match possible schema changes are created and tested. | Y | Needed | ||
[M] Interface version (for backend modules) and module implementation version (for backend (pom.xml) and UI (package.json)) is updated according to the versioning procedure: https://dev.folio.org/guidelines/contributing/#version-numbers. The fixVersion field in JIRA (user story) is updated to match the version that ships the feature/bugfix. | Y | |||
| [M] All dependencies (both Okapi/FOLIO module dependencies and NPM deps) are updated to release dependencies (no pre-releases). | Y | Needed | ||
[M] UI Regression tests (https://github.com/folio-org/stripes-testing) are updated and pass on the local development machine. | Y | Needed | ||
[M] Peer code review is performed with at least one developer from Leipzig - Team; code can be merged to master only when build passes and after peer approval. TODO: Establish review criteria | Y | Needed | ||
| [M] Verify that PII stored is encrypted | Y | Do we need this? | ||
| [M] verify compliance with GDPR – future requirement | Y | Do we need this? | ||
| [M] Feature OK’ed by UX and complies with: - https://ux.folio.org/docs/guidelines/ - WCAG 2.0 Level AA accessibility compliance - Validate with Jeffrey Cherewaty, Filip Jackobsen and/or John Coburn before coming with new design patterns in UX that’s not consistent with Stripes | Y | Do we need this? | ||
[M] Build deployed successfully to folio-snapshot-stable environment (test, integration etc.). In case of unresolved but unrelated integration testing issues, feature will be accepted on folio-snapshot. When running, Leipzig's qa-environment shall be used. | Y | Needed? Or must the build be deployed and accepted on Leipzig's testing environment? | ||
[M] QA is performed and issues resolved: folio-snapshot-stable OR folio-snapshot (in case of unrelated integration test failures) - Feature is tested against acceptance criteria - Tests on supported browsers/devices/platforms pass (UI) Future requirement | Y | Who is doing QA tests? Do we have acceptance criteria? | ||
[M] Feature implemented meets acceptance criteria defined by PO/Lead Future requirement | Y | Do we have acceptance criteria? | ||
| [M] Feature is accepted by PO Future requirement | Y | Are we doing this? | ||
[M] Only backend modules: if feature blocks a UI module feature, new version of the module is released (see https://dev.folio.org/guidelines/release-procedures/) | Y | |||
[M] No open critical bugs on any user stories | Y | Needed | ||
[M] DoD of each user story, included in demo are met | Y | Needed | ||
[M] All demoable features are demoed from the same shared environment – folio-snapshot-stable OR folio-snapshot (in case of unrelated integration test failures) | Y | Needed | ||
[M] Installation and deployment scripts are updated | Y | Needed | ||
[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 | Do we need this? Are we doing this? | ||
[M] All bugs reported by QA, manual testing, UAT, PO etc and labeled for the release (e.g "q4-2018") are fixed | Y | Needed | ||
[M] Release notes are created | Y | Needed | ||
[M] User documentation updated (deployment documentation, scripts/packaging etc.) | Y | Needed | ||
| End-user documentation is updated | Y |