Leipzig - Definition of Done

Please note that all items in checklist marked with [M] are mandatory.


Checklist

Feature/User Story

Sprint Demo/Review

Release

[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



[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



[M] Scripts to match possible schema changes are created and tested.Y

[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

[M] UI Regression tests (https://github.com/folio-org/stripes-testing) are updated and pass on the local development machine.

Y



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

[M] Verify that PII stored is encryptedY

[M] verify compliance with GDPR – future requirementY

[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

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



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



Feature implemented meets acceptance criteria defined by PO/Lead

Future requirement

Y



Feature is accepted by PO
- Move the story to “in Review” and assign it to PO who will review and move it to Done if acceptable

Future requirement

Y



[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


[M] DoD of each user story, included in demo are met


Y


[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


[M] Installation and deployment scripts are updated



Y

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 and labeled for the release (e.g "q4-2018") are fixed



Y

[M] Release notes are created



Y

[M] User documentation updated (deployment documentation, scripts/packaging etc.)



Y

End-user documentation is updated

Y