| 15 min | Accessibility statement review | | - Review the proposed accessibility statement for FOLIO LSP, recently updated by the Accessibilty SIG.
- egerman: no substantial changes, but added a link to the Jira a11y dashboard
- this shows the known accessibility issues
- questions about browsers: belief that Safari/Voice Over will work, but Safari still isn't an officially supported browser.
- Julian Ladisch: UXPROD-3043 notes only ~1/2 the requirements needed for EU compliance are incorporated in FOLIO's UX guidelines at present. Do we need to add additional compliance-goals statements? md331 (Deactivated): want to avoid forcing SIG to maintain a copy of the WCAG guidelines as our own checklist. JL: But we need documentation of expectations as a backstop to filing non-compliance bugs and getting devs to accept.
- Can we present the checklists as an aide to assessment, rather than as a standard of assessment?
- How does our process align with this statement? Do we need to revisit our DoD language (or review our baseline DoD generally)?
- The TC has no objections to the document as it currently stands.
- Acknowledge that POs and Scrum Masters may need to review DoDs WRT accessibilty statements in order to help them assess priority of accessibility issues.
|
| 40 min | Continuation: Expectations for Testing items | | - Issues raised last week:
- How do we avoid overlap between karate and e2e tests? Duplicate effort is wasted.
- Where is this being documented? It would be _really_ helpful to be able to point new teams, outside teams, future teams, etc. to a page that can set their expectations.
- Some “closer to the edge” apps(e.g. orders) are isolated compared to “closer to the core” modules (e.g. users, inventory). How are tests with lots of interactions with different modules (which may be maintained by different teams) going to be maintained? e.g. requests interacts with users and inventory and circulation and checkin and checkout; who maintains request e2e tests?
*** - Test expectations are not well organized; YET. Don't worry about overlapping tests just yet; coverage is spotty right now. Limit e2e tests to critical business workflows. Once that is complete, and bugs get filed, we write a few more tests to cover those bug conditions.
- Start by adding some e2e tests based on bugfest test cases, then hopefully find fewer bugs next bugfest, rinse, repeat.
- Should we be testing things like "checkout" in both API integration tests and UI e2e tests? An e2e checkout test inherently covers the APIs, so what is value in having both?
- e2e tests are s.l.o.w. they are valuable, but shouldn't be relied on for coverage.
- it is likely that services covered in e2e tests are likely covered by API tests as well.
- don't want to build "all e2e tests", want to build "just enough tests". the goal is to provide adequate, actionable feedback. e2e should cover key business workflows only.
- There is already a lot of content about test guidelines but no portal that aggregates this, e.g. e2e BigTest, Karate, UI unit. UI e2e testing pilot is finally done (BigTest interactors; Cypress runner). Folks are already well-educated about unit test frameworks and expectations but we need a portal that aggregates additional resources. Anton Emelianov (Deactivated) will write the first iteration of this on the wiki, hoping for support from TC members.
- Need a portal with links to unit, integration, e2e tests
- devs acknowledge that having GitHub and the wiki and dev.folio.org as sources for documentation leads to confusion but we aren't sure of the best way to funnel people to a single source.
|