| | | |
|---|
25 min | Continuation: Expectations for Testing items | @Anton Emelianov (Deactivated) | Continuation of last week's discussion: Create a unified list of expectations relative to testing items that should be part of Definition of Done is this about changing who does testing and when, or is it about the kinds of testing we do? Mark D: that presentation gave an excellent "ideal view" of things, but it wasn't clear what the short-term roadmap looks like, i.e. how we get to the ideal view Marc: we're already telling backend teams they'll to write karate tests questions for @Anton Emelianov (Deactivated): revisit integration and end-to-end test expectations with an eye toward concrete tasks for teams to take and clear guidance about who will be involved in managing these test plans (devs, POs, etc). how should we allocate our testing budget? we can't just write all levels of tests for everything all the time. don't need to test all scenarios, but how do we assess which scenarios need to have automated scenarios?
@Raman Auramau: there are existing best practices around this: @Jakub Skoczen: what is the process for individual teams to add/manage these tests? want to avoid having every single team writing a "test login" function postman tests made it difficult to share common test functions across modules it is expected that the API test repo is structured in such a way that common functions/utilities are easily shareable across modules need to figure out how, when a test spans multiple modules, an individual team can be responsible for maintaining tests some modules closer to the edge may have more isolatable test cases (e.g. mod-orders) whereas others' logic (e.g. mod-circulation) are not so easily separable want to avoid having mod-circ tests that cover the same ground as mod-circ-storage tests
Not clear what overlap between Karate tests and end-to-end tests is
@Marc Johnson summary : who should write these tests? how should they be organized? what scenarios need this kind of coverage?
@md331 (Deactivated) Great to hear this is being communicated to existing teams; where/how are we collecting this guidance so future teams, external devs, etc. can set their expectations?
|
25 min | Set the stage for Spring Way discussion | TC | Status of Spring Way (can leverage this discussion to determine the process for approving new technology)
Discuss whether to formalize the "Force" pattern used to manage and maintain cross-cutting Folio componentry.
We already have: There are other potential candidates to this approach which could benefit from formalization: Elasticsearch Force Kafka Force
@VBar: SpringWay is an example of a broader pattern of a module/pattern/tool that is used across FOLIO (stripes-components, managed by Stripes Force, is another example; Performance Testing Framework (PTF) as well) SpringWay is 90% complete: how do we assign responsibility for maintenance of this going forward since it doesn't make sense to assign it a particular module-oriented team Can/should we formalize this as a pattern: we also have Elastic Search, Kafka as similar examples of modules that cut across teams best practices? ES and data-import use kafka in different ways leading to multi-tenant issues, so having BP doc would be helpful. need to have some person/team take on the tech-architect role to reduce friction across the project so ... when we adopt new shared things, want to be able to consolidate how it gets used in the project one of the challenges of moving modules among teams is domain expertise, but different tech practices across modules compounds this. sometimes components like ES, Kafka get adopted by a particular team for a particular feature, but then need to be sustained moving forward. This is becoming a problem with e.g. RMB. This is not just a people problem, but about establishing dedicated Slack channels, Wiki pages, etc documentation resources. So the question is: how do we move this stuff from "internal to a team" vs "standardized by FOLIO"? @VBar: this is about: when we want to formalize something as The FOLIO Way, how do we do this? Next step: having introduced this topic, need a small group to make a concrete proposal to the TC WRT defining how to establish long-term support of cross-cutting components in FOLIO. Very high level guidelines about expectations for management and responsibility of shared components. @VBar to solicit members.
|
5 min | Volunteers for Future TC Meetings | TC | Zak to run next week's meeting and review the following: a11y statement proposed for FOLIO LSP; Zak to contact the SIG and ask a member to attend the 2021-04-21 meeting testing review: exactly what kinds of tests are we prescribing, and who will be responsible for writing, running, maintaining, and monitoring them? Zak to review today's notes with @Anton Emelianov (Deactivated) and ask him to attend the 2021-04-21 meeting
|
5 min | future agenda items | | A11y SIG has updated the proposed accessibility statement for FOLIO LSP; we should invite a SIG rep and review this in the near future. Zak to contact the SIG and ask a member to attend the 2021-04-21 meeting testing review: exactly what kinds of tests are we prescribing, and who will be responsible for writing, running, maintaining, and monitoring them? Zak to review today's notes with @Anton Emelianov (Deactivated) and ask him to attend the 2021-04-21 meeting
|