Page tree
Skip to end of metadata
Go to start of metadata

Current

A list of items that the team is already following


Checklist

User Story

Sprint Review

FOLIO Release

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.

Y



Sample and reference data is updated to match the feature or schema change.

Y



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)

Y



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

Y



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.

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.

Y



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.

Y



Feature implemented meets acceptance criteria defined by PO/Lead

Note: consider merging with the following one

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

Y



Migration script added in case of schema update. (see https://github.com/folio-org/raml-module-builder/blob/master/DB-schema-migration.md)

Y


Aspirational

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.


Y


DoD of each user story, included in demo are met


Y


All demoable features are demoed from the same shared environment – folio-snapshot-stable OR folio-snapshot (in case of unrelated integration test failures)


Y


Module releases are performed in case there are accepted user stories (see https://dev.folio.org/guidelines/release-procedures/).


Y
- Tests on supported browsers/devices/platforms pass (UI)



User StorySprint ReviewFOLIO Release
Items below are not a team level but cross-team and require input from Core: Platform


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

All bugs reported by QA, manual testing, UAT, PO etc and labeled for the release (e.g "q4-2018") are fixed



Y

Release notes are created



Y

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



Y

User documentation is localized



Y

  • No labels

4 Comments

  1. minor cosmetic comment: we moved away from features. USs only

  2. We should have an entry that deals with database updating when upgrading modules versions. We cannot assume the database is empty and we need to ensure the data can load after the module upgrade. There is an upgrade process in the DB schema files, but it is rarely used.

  3. Apologies, I’ve run out of time, so there may be mistakes, and have not commented on any of the end of sprint expectations yet, sorry (sad)

    I’ve tried to describe at least some of my thoughts for all of the story level criteria, at least briefly. I started with the already established criteria from the sprint review.

    If a criteria is not for adoption at this point, please disregard my questions.

    Please feel free to ask questions, disagree or disregard any aspect of my thoughts.

    Context

    I’m interpreting this definition as aspirational and that we are intending to adopt it incrementally, and will use an interim definition along the way.

    With that in mind, my framing questions for the conversation are

    • Which of these can we adopt today and what is the impact?
    • Which of these are we deferring or reducing for the moment?

    General Questions

    Is our general goal to be able to complete all of this criteria for a story within a single sprint (from start to accepted and formally released)?

    Does this criteria establish the minimum expectations that all stories for modules that the core functional team is responsible for?

    And hence, does that mean that any pull requests, for modules that the core functional team are responsible for, should be rejected if they do not meet all of the criteria, that can be applied during a pull request (80% coverage on new code etc)?

    Established Criteria

    Following yesterday’s sprint review, which clarified the general FOLIO module definition of done, I believe we are expected to apply the following from now:

    • Only stories that have passed manual QA are demoed (exceptions for proofs of concept etc should be explicitly called out)
    • Applicable UI integration tests are executed and pass locally
    • Unit and automated tests are created as part of development with a goal of 80% code coverage
    • All demos are conducted from an integration environment (environment may vary by team)

    Code Coverage

    Unit and automated tests are created as part of development with a goal of 80% code coverage

    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.

    Using the above definitions, I propose we have an interim definition something like:
    All new code is expected to have at least 80% coverage (from tests in the module repository)

    We are intending to reject any pull request (from any team / developer) that do not have 80% on new code?
    Do we need an exception process in place for when this cannot / will not be achieved?

    UI Integration Tests

    Applicable UI integration tests are executed and pass locally

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

    What should a developer do if the tests are not currently passing? Does that mean that all stories are blocked?

    What should developers who cannot run the tests locally do? Are they disallowed from submitting code?

    Tests on supported browsers_devices_platforms pass (UI)

    Does this refer to the UI Integration Tests? If so, what browsers and devices do we currently support and test on?

    Presence in an Integration Environment

    All demos are conducted from an integration environment (environment may vary by 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.

    > QA is performed and issues resolved: folio-snapshot-stable OR folio-snapshot (in case of unrelated integration test failures)

    Which environment is the current integration environment for the core functional team, folio-snapshot or folio-snapshot-stable?

    If environments are unavailable, does that mean a story cannot be completed?

    Configuration, Reference and Sample Records

    Sample and reference data is updated to match the feature or schema change. Any configuration and/or build scripts are updated and tested.

    Where is configuration and sample records intended to be tested? On the folio-snapshot environment?

    For example, if a story involved e-mail, it could not be completed until it was possible to send an e-mail from folio-snapshot (or some other integrated environment). Is that the case?

    Code Reviews

    > Peer code review is performed and at least one developer from Core: platform; code can be merged to master only when build passes and after peer approval.

    This suggests that we are expecting the core platform team to review all core functional team code changes. Is that the case, or is this a typo?

    What is our interim criteria for a review?

    Does this apply to all changes to modules that the core team is responsible for?

    Formal Releases

    All dependencies (both Okapi/FOLIO module dependencies and NPM deps) are updated to release dependencies (no pre-releases).

    Only backend modules: if feature blocks a UI module feature, new version of the module is released

    Does this mean that backend modules need to be formally released before a UI module pull request can be merged? (Maybe some more recent conversations have superseded this criteria)

    How are module dependencies going to be checked? As part of pull requests?

    Is this related to https://issues.folio.org/browse/FOLIO-1715 which has been closed as won’t do?

    Acceptance

    Feature implemented meets acceptance criteria defined by PO/Lead

    Feature is accepted by PO

    What is the difference between meeting the acceptance criteria and being accepted by the Product Owner?

    Version Changes

    Interface versions and module implementation version are 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.

    This may need refinement to the guidance, for example https://issues.folio.org/browse/FOLIO-1746

    1. Anonymous

Write a comment…