Flere har et behov for forenklet manuell bygging av funksjonelle testscenarioes

[LeifHelstad]

Situasjon

For å kunne legge inn nye testdata i form av dialogs med tillhørende activities og transmissions har ikke-utviklere disse mulighetene:

1. Gjøre API kall via Postman.
2. Be samarnbeidspartnere (Skatteetaten) eller 3.parts aktører som samarbeider bortenfor disse igjen om å legge inn data via sine "serviceOwner" systemer.

For å kunne gjøre visse oppdateringer på eksisterende dialoger finnes det et tredje alternativ

3. https://github.com/Altinn/dialogporten-serviceprovider kan ta i mot http-kall fra guiActions i arbeidsflate og agere på disse ved å gjøre API-kall til dialogporten (som en hvilken som helst annen serviceOwner).

Utfordring

Via Postman

• Tidkrevende å bygge ett og ett kall manuelt for å bygge opp et funksjonelt scenario.
• Det er en kompetanseterskel i selve verktøyet og i å forstå API-kallenes returverdier.
• Det benyttes en felles collection der en del variable knyttet til "party" blir ombrukt mye slik at det er en risiko for å klusse med "andres data".

Via samarbeidspartnere

• Begrensinger i variasjon i data basert på aktørenes testsystemer og implementerte funksjonalitet.
• Uhensiktsmessig å være avhengig av 2. eventuelt 3. part for å kunne populere egne systemer med testdata.

Løsning

Målet er å kunne forenkle mest mulig for å manuelt kunne simulere funksjonelle handlinger ServiceOwner kan gjøre. Dette for å kunne ha data EndUser ser og kan agere på i Arbeidsflate.

Målgruppen er primært testteamet og desingteamet.

Formålet er å kunne enkelt danne variasjon i testdata for

• Verifisering av endringer i FAT og UAT
• Brukertest som ledes av designteamet
• annen testing som produktteamet eller produktledelsen ønsker å gjøre for å verifisere eller utforske produket videre.

Forenklinger i datagenerering

Det er identifisert tre mulige hovedlinjer for å kunne generere data på json format som kan kjøres direkte i postman uten videre modifisering.
Denne løsningen fritar ikke den som skal bygge data fra en del komplikasjoner rundt autorisasjon og forståelse av Postman.
Gevinsten ligger i spart tid ved å unngå "klipp og lim" av tidligere benyttede filer for å bygge nye scenarios

A. Testdatagenerator

Tanken er å bygge en testdatagenerator som lager nye .json filer som kan kjøres direkte i Postman

A sine fordeler

• Stor frihet i å velge og prioritere hvilke kall man skal generere for og hvilke data som skal inngå.
• Denne kan rendyrkes som en "Scenario Builder"
• Blant de tre altenativene for datagenerering virker denne som den mest fleksible på å hente tilbake med dialogid og berike eksisterende dialoger videre.

A sine ulemper

• Noe sårbarhet i forhold til større API endringer.
• Kan kreve en del vedlikehold og videreutvikling

B. react-jsonschema-form

Click here to download the output of ./extract_schema.sh https://altinn-dev-api.azure-api.net/dialogporten/swagger/v1/swagger.json. This can be used in https://rjsf-team.github.io/react-jsonschema-form/

B sine fordeler

Testdata bygges alltid basert på oppdatert swagger

B sine ulemper

• Data må legges inn helmanuelt på den ekstene siden. (Det er sikker mulig å trikse til noe med Bookmarklets, men da mister man den beskrevne fordelen.)

C. .json eksport fra Prototype

• Dagens prototyper har en mulighet for å eksportere de presenterte data som .json

C sine fordeler

• Data kan eksporteres fra prototypen rett inn i testmiljøet slik at forventninger lett kan avstemmes

C sine ulemper

• Å bygge data i prototypen krever en del manuell innsats hvis ikke dataene allerede er definert default.

Utvide https://github.com/Altinn/dialogporten-serviceprovider med et UI/GUI

D. ServiceOwnerMock

Det finnes allerede en oppgave på dette Altinn/dialogporten-serviceprovider#3
Hvis denne løsningen velges kreves det prioritering, spesifisering og noe utviklingskapasitet.
Tanken er å bygge en CRUD mulighet for de mest brukte kallene for dialogs, activities og transmissions.
Denne blir en mer generell "dialog generator"
Løsningen er i praksis en mock-service-owner-gui.
I dagens løsning gjøres alle kall tilsynelatende av "Testdepartement". Mulig det må lages mer fleksibilitet?

D sine fordeler

• Kallene gjøre i en løsning som har "minne" og kan bygge på hvernandre
• Ingen bruk av Postman, alt skjer i en flate

D sine ulemper

• Krever antakelig mest tid fra utviklere av alle forslagene og konkurrerer med tid brukt på selve produktet

Senere utvidelser av løsningen

Mer enn dialoger

I første omgang er tanken at løsningen skal dekke dagens testdatabehov knyttet til dialoger. Løsningen bør kunne utvides til å danne API kall for Meldinger og Skjemainstanser også.

[LeifHelstad]

A. Testdatagenerator

I løpert av ikke så lang tid har jeg laget en generator der man kan velge avsender og slå av og på om man skal ha med additionalInfo og mainContentReference i dialgen. Har testet generert .json i Postman med en, begge og ingen av disse valgene samt ulike verdier på status. Postman og Dialogporten godtar disse kallene og dialogene fremkommer som forventet i arbeidsflate.

Det er klart for å fylle på med funksjonelle utvidelser. Jeg tar en avklaring rundt behov med design team.

En tidlig utgave er delt på https://digdir.atlassian.net/wiki/spaces/BF1/pages/3004497930/ScenarioBuilder+for+dialogporten