Skip to end of banner
Go to start of banner

Spitfire - Definition of Done v2.0

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

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.
- Feature is tested by QA against acceptance criteria on supported browsers/devices/platforms pass"

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 changesY

[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
- 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



[M]

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

Y



[M]

Localization is taken care of in application code

Y



[M]User documentation updated - README.md, response example files etc.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

  • No labels