Important part of the test harness is deployment(can the software run?) and communication (can it get HTTP requests?).
We can showcase openIMIS or Camunda during the presentation to show real results (not mocked ones). We can only present that the configuration made for one BB can be reused for other BB configuration.
Improvements to the testing app before Deep Dive:
Filter branches to only show main branch results (currently there are multiple results from softwares) .
Performance of the testing app, data is loading too slow.
We should avoid switching environments during presentation and just describe screenshots from the app instead of switching from slides and testing app.
We should explain why the technology used in the testing harness is an effective way for this solution.
Terminology - we should explain all the terminology we’re using like example implementation, softwares, building block, execution, etc… to make sure it’s well described. During the first technical session there will be an introduction to the terminology.
Add one slide with terminology explained to our testing harness presentation .
Text is too small and there are too many white spaces (applies to all slides).
Add summary of the tests and APIs that are already implemented in the GovStack (summary by BBs).
We should add a slide to describe “Why the solution is unique?”, “Why to choose this solution?” and “How the community collaborate?”.
@Taylor Downs notes:
Taylor, please add your notes here . OK!
For the presentation, @Dominika Bieńkowska, (cc @Satyajit Suri) a screen grab with actual candidate test results. Some pass, some fail. I think this is good example. (see below)
More slide 4 notes: the most fundamental requirements to be a govstack BB are: deployability (how can we set it up?) and communication via HTTP (how can we hit a REST API?).
Slide 8 - attempt at the simplest explanation of the flow
when a change is made to a specification
or when a candidate is added or updated (new version)
the test harness iterates through every single candidate and test suite and
deploys the app, configures it for a given test suite, and runs the tests against it
then it sends the results for all suites and candidates to testing.govstack.global
Slide 10 - put boxes around each. title the boxes: “bb repo”, “candidate”, “test suite”
Slide 13 - add why this matters. external stakeholders look at testing.govstack.global, a dev trying to make code changes to the spec, the tests, or the candidate config looks at github/circleCi
Discussion - what is missing, what should be changed or removed
All participants
Future plans:
We should add a note about compliance form and extending the testing app.
Compliance aspect might be very important for the audience.
