2021-04-14 Meeting Notes

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:
    
    • critical path functions deserve more extensive tests
  • 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? 
    • some wiki documentation exists but is not yet in final form

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:

• Stripes Force (extant)
• PTF: Performance Tasks Force (extant)
• Spring Force (nascent)

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.