Agenda

Presenter

Duration

Discussion

• Review pending action items

• Review Risk register

@Esther Ogunjimi

 10 minutes

TECH-175: Technical Committee Action ItemsDone

TECH-278: All BB Leads to confirm if data model has been defined for respective BBs.In Progress

TECH-288: Review BB data core model in GithubIn Progress

TECH-324: Create GitBook instance for wave 3 BBsDone

• Technical Risk Register

Status update

Specification release v1.0

@Steve Conrad @Esther Ogunjimi

30 minutes

Scrum standup-style (what we did this week; plans for next week; blockers/pain points and open/unresolved questions?)

• Review Jira issues that have questions/ need clarification

• Alignment on what the expectations are for the specifications and how they fit together

  • Advance Roadmap

Information Mediator BB

• Not started the specification release tasks

• Stand alone security server is running

• Pilot testing with other BBs with IM - more attention is needed to test IM itself

Next week

• Will be working on the specification and testing deliverables.

Messaging BB

• Working on test framework

• Data structure notification rework is in progress.

• Will be creating test for messaging BB with support of the Soldevelo team to determine the functional testing framework

• Had the first draft of the use case scenario

Registration and Digital Registries BB

• Working on the spec release tasks for the two BBs.

Registration BB should have more API points as this BB is considered to be a no code system, and there is no need to have APIs. However, the team will still hold on to the already defined APIs until there is a real use case where their workflow can be attached to the APIs, and decide the APIs that are needed.

Steve - Do we need to make substantial changes to the BB specs (as the spec is structured as a no code platform)? This is to ensure other platforms can be compliant with the registration and registries specs. The language around the no code might be too specific. There is need to make decision to move forward - the approach to adopt for these BBs and other cases that many come up.

Satay - There is currently one API specified for registration BB. From the test harness perspective, are we testing one API or what are we testing for registration BB? or are we testing local platforms ? or provide test harness for this? Based on the no code, low code for registration BB

Wes - we should try to stay away from broad base functional changes to the specification.

In general we should not be making substantial functional changes to the specs for the 1.0 publication. However, in the specific example of the registration BB, because we could be just removing functional content (the no-code and associated UI stuff) I think that that is worth doing for the 1.0 publication.

Ramukumar - We stick to the capabilities considered. We need to come to the agreement that for v1.0 release, scope will not be added to the specs but clean up what is unclear or represented fully, rather than considering new features and new functionalities.

Ingmar - Impact would be from the different other building blocks, not from the similar building blocks, comparing the digital registries or registration building block to similar products, the compliance will come from there. There is no need to have additional APIs as these additional APIs should come from other BBs that need the API from registration BB. More reason why registration BB is beginning of the user journey.

Steve - who is responsible to make the foundational decisions about whether a no code or low code platform is acceptable for registration BB?

This is to ensure the registration BB spec is not written such that it is only applicable to a single solution or platform because there are multiple existing products that could comply with the spec written.

Wes - We need to make good decision to ensure the 1.0 release resonate with the broader community.

Ingmar - the spec was built to fit similar products to have similar functionalities. The no code, low code application is a practical standard for the next generation of services, and that was what was built into the spec

Schedular BB

• Working on v1.0 release tasks.

Consent BB

• progressing with the test scenarios, and understanding the boundaries of consent BB as regards ID BB and signature.

Definition and Testing of APIs

@PSRAMKUMAR

25 minutes

Ramkumar - what is the API target coverage? what does it mean when we say APIs is tested for V1.0?

Staya - for digital registries, there are 14 end point APIs, there are test case defined in gherkin for the 14 of them, and they have been tested and deployed in Circleci.

There is standaridised template for every APIs on how to write the gherkin and cucumber script; which include sanity test cases, mock test cases etc.

There are 12 endpoints APIs defined for ID BB. Three are tested and deployed completely while nine are still in the process of review.

For payments, we have five tests API endpoints which are developed defined for voucher. G2P UC APIs are being finalised.

Information mediator BB have five API endpoints, two have been tested and the rest is in the review process.

Registration BB have one API.

Consent and Workflow BB are being driven by the individual BBs themselves. Consent BB codes need to be merged. Workflow BB have five endpoints APIs defined with their test cases.

Complete work is required for messaging BB as no API has been defined.

Schedular BB has defined the standardised gherkin test cases and in progress for the rest of the APIs.

The test cases need to be standardised based on the template.

The priorities for March is to complete the test cases based on the standardised template and deploying them onto circle ci to qualify them for test harness capabilities.

Definition of use-case examples for USCT

@Dominika Bieńkowska (Deactivated)

25 minutes

API Testing - status across BBs

Working on the registration BB steps and the flow diagram based on the postpartum UC.

Retro

All

TC Retro 3 | EasyRetro