A list of items that the team is already following
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. This requirement applies to new code only. Existing code coverage is gradually updated through catch up tasks. Pull Requests that do not match this criteria will be rejected.
Sample and reference data is updated to match the feature or schema change.
|Any configuration and/or build scripts are updated and tested (Note: this refers to e.g Ansible roles and similar, usually requires a FOLIO task. Should be seldom once in-module data loading is implemented for all modules)||Y|
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 is updated to match the version that ships the feature/bugfix.
(Note: the guidelines are being extended and updated: FOLIO-1718)
[NEEDS DISCUSSION] UI Regression tests (https://github.com/folio-org/stripes-testing) are updated and pass on the local development machine.
Note: we know the tests may be brittle but we decided to give this requirement a go.
Peer code review is performed with at least one developer from the team that "owns" the module; code can be merged to master only when build passes and after peer approval.
TODO: Marc Johnson is putting together a code review checklist and will review it with the team.
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.
NEEDS DISCUSSION 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
Note: it's not clear who is this checklist item meant for (developer? PO?) and how is it different from the "Feature is accepted by PO" one. Is this item meant for a seperate QA team? It's also unclear what is the list of browsers/devices/platforms required. Consider dropping or moving to aspirational.
Feature implemented meets acceptance criteria defined by PO/Lead
Note: consider merging with the following one
|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
Migration script added in case of schema update. (see https://github.com/folio-org/raml-module-builder/blob/master/DB-schema-migration.md)
A list of items that the team is would like to start following but is not ready.
[NEEDS DISCUSSION] No open critical bugs on any user stories
Note: it is outside of the team's control since anyone can file bugs on any issues. Consider removing or adding to aspirational.
DoD of each user story, included in demo are met
All demoable features are demoed from the same shared environment – folio-snapshot-stable OR folio-snapshot (in case of unrelated integration test failures)
Module releases are performed in case there are accepted user stories (see https://dev.folio.org/guidelines/release-procedures/).
|- Tests on supported browsers/devices/platforms pass (UI)|
|User Story||Sprint Review||FOLIO Release|
|Items below are not a team level but cross-team and require input from Core: Platform|
Installation and deployment scripts are updated
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
All bugs reported by QA, manual testing, UAT, PO etc and labeled for the release (e.g "q4-2018") are fixed
Release notes are created
User documentation updated (deployment documentation, scripts/packaging etc.)
User documentation is localized