Siden viruset fortsatt setter begrensninger for å møtes fysisk ble denne månedens Quality Day helvirtuell. Heldigvis er entusiastene like motiverte og siden mange nå kjenner på det å sitte hjemme og jobbe hele tida, var vi nærmest fulltallig da dagen begynte med en felles sesjon på Teams.
Formålet med Quality Day er å sette av tid til egen faglig oppdatering, både gjennom studie på egenhånd og gjennom kunnskapsdeling mellom kollegaer. Så vi begynte dagen med en digital kaffekopp og en gjennomgang av dagens agenda og en felles presentasjon om GDPR og innebygd personvern, før alle gikk over til selvstudium. Senere møttes vi igjen til digital lunsj, før vi fortsatte med fagdagen. Dagen ble avsluttet med avdelingsmøte og digital Julebrus-testing sånn at vi alle kunne få noen tips til hva man bør handle inn til julekosen.
Under er en oppsummering av de temaene det ble jobbet med:
En av kvalitetsentusiastene holdt et foredrag med utgangspunkt i personopplysningsloven, også kjent som GDPR. Det ble gjennomgått hva som er en personopplysning, hvilke krav som skal være oppfylte for å kunne registrere disse, og hvilke begrensninger som ligger i personopplysningsloven når det gjelder bruk, kobling av innsamlede opplysninger, vedlikehold og sletting.
Loven stiller strenge krav på alle punktene, og det er noe man skal være klar over før man begynner å lage applikasjoner som samler inn og lagrer personopplysninger.
Kravene til å beskytte informasjonen mot utilsiktet tilgang er også et hett tema, hver uke leser vi om manglende sikring og datainnbrudd både i Norge og andre land. I tillegg er det mange tilfeller av applikasjoner som ikke oppfyller kravene til å ivareta innebygget personvern, det er flere tilfeller innen helse og skole hvor datatilsynet har vært nødt til å bøtelegge fordi personopplysninger er for dårlig beskyttet eller har kommet på avveie.
I avdelingen ønsker vi å utvide vårt tjenestetilbud, og ett av områdene det jobbes med er å se på om Quality-As-A-Service kan være en vei å gå. Målet er å forenkle testløpet for våre kunder, slik at de kan bestille teststøtte som vi kan levere uten å være til stede i kundens lokaler.
Vi kom i løpet av dagen godt i gang med å definere opp et grunnlag for videre arbeid, hvor det første målet er å sette opp en analysetjeneste via en selvbetjent web-løsning som vi tilbyr bedrifter/kunder. Vi vil ha en intern testlab som tilbyr ulike testverktøy for ulike formål, hvor vi selv er eksperter. I noen tilfeller vil vi også kunne bruke verktøy som kunden allerede har installert.
Pakketerte tjenester
Vi ønsker som del av QaaS å tilby eksperter på sikkerhets-/penetrasjonstesting, UU-, ytelses- og mobiltestere. Input til en testmodell vil eksempelvis være estimater for gjennomføring av ytelsestest av et system. Ressurser kan da bookes for en periode og man kan i testmodellen se når en ressurs er ledig for nytt oppdrag.
Quality Maturity Assessment — QMA
Vi kom også innpå tema ITIL og hvorvidt vi i Knowit Quality har noen som er sertifiserte i ITIL. Det stilles relativt ofte ønske om ITIL sertifisering i oppdragsbeskrivelser, og det ble diskutert om vi burde ha ITIL Foundation sertifisering. Et langsiktig mål kan være at vi i Quality på sikt har ressurser som er erfarne nok til å gjennomføre en QMA for en større bedrift.
Business Model Canvas
Det ble jobbet med konkretisering av vår påbegynte satsning på Quality-as-a-Service i form av en Business Model Canvas. Business Model Canvas er en metode for å konkretisere forretningsmodeller på en visuell og konsis måte. Man blir tvunget til å få de viktigste detaljene og prioritere tekst og bilder ned til en A3 side. Se her for mer informasjon om Business Model Canvas: https://www.strategyzer.com/canvas
Som tester ønsker man gjerne å kunne kjøre automatiske regresjonstester, f.eks. før produksjonssetting av ny kode. Da er det nyttig å ha et verktøy som gjør denne jobben for oss. Cypress er et slikt verktøy som jeg undersøkte litt nærmere på fagdagen vår i dag.
Cypress er et JavaScript ende-til-ende testrammeverk for applikasjoner som kjører i en browser. Det er relativt kjapt å komme i gang med Cypress, som er en desktop-applikasjon som kan installeres på både Mac, Linux og Windows.
Instruksjoner på hvordan du installerer Cypress finnes på https://docs.cypress.io/ og her er også eksempler og guider på hvordan man kommer i gang. Verktøyet er svært kraftfullt og kort oppsummert er dette de store fordelene med Cypress:
• Cypress tar snapshots når testene kjøres så man i etterkant kan se nøyaktig hva som skjedde under kjøringen
• Debugging er gjort enkelt med lesbare logger og stack-tracer
• Cypress venter automatisk før den går videre, ingen behov for å legge til vente-stepp
• Det tas automatisk skjermbilder når feil oppstår eller video av hele testen når man kjører fra kommandolinje
• Testene kan kjøre i flere forskjellige browsere, Chrome, Firefox og Edge
En annen kvalitetsentusiast brukte Cypress på en litt annen måte.
Tilnærmingen hans var å bruke axe-core som er et Open-Source bibliotek som fanger opp en del tilgjengelighetsproblemer på nettinnhold basert på WCAG 2 (Retningslinjer for tilgjengelig webinnhold).
Axe-core er designet for å fungere i alle moderne nettlesere og med verktøy, rammer, biblioteker og miljøer som er mye brukt. Axe leveres og støttes av Deque Systems, en stor leverandør av verktøy for testing av tilgjengelighet.
Pros:
- Muligheten til å integrere axe i eksisterende automatiserte tester
- Muligheten til å definere spesifikk hva som skal sjekkes fra WCAG retningslinjene
Som nybegynner i bruk av Postman som er verktøy for API-testing, ble dagen brukt til å gjennomgå noen emner hvor det brukes Postman og Newman. Dette omfattet emnene:
- Hva er Newman i Postman
- Installasjon av Newman ved bruk av NPM (Node Package Manager)
- Installasjon og konsepter av Node.js
- Installasjon og konsepter i NPM
- Kjøre innsamlingen vha Newman
- Kjøre innsamlinger med Newman gjennom delte lenker
- Kjøre innsamlingen med Newman gjennom å eksportere det som JSO
A single source of truth
En kilde til sannhet er kjernen i source control/branching strategien som ligger til grunn for continuous integration — kontinuerlig integrering. Utviklerne jobber på feature branches som fortløpende integreres inn i main-repoet. Her er scope viktig! Mange som gjør utvikling tar ut en feature branch, jobber på den til den nye funksjonaliteten er klar, og merger den så inn i main. I et — i mangel av et bedre ord — «tradisjonelt» utviklingsløp vil utviklere gjerne jobbe relativt lenge på en feature i en egen branch, inntil de mener den er klar til å bli deployet. Et typisk problem som oppstår da, særlig i større prosjekter med mange team som jobber på samme produkt/prosjekt (kort og godt at de pusher kode gjennom samme pipeline) er at når dagen kommer for å merge de ulike branchene inn i main på miljøet, oppstår det mange konflikter som ofte er langtekkelige og vonde å løse. Hyppigere, og — ikke minst — mindre endringer som merges inn i main flere ganger om dagen er et svar på dette problemet. Det kan midlertidig blokkere andre som jobber i miljøet (ved å pushe en endring som brekker funksjonalitet f.eks.), noe som er en typisk innvending fra utviklere på prosjekter som skal begynne med CI/CD prosjekter som baserer seg på en slik branching-strategi. Her ligger derimot noe av gevinsten, for på den andre siden blir dette et insentiv til å jobbe sammen om å løse eventuelle problemer som oppstår så raskt og effektivt som mulig; fokuset flyttes ut av det lille stykket kode man jobber med der og da, og over til et mer helhetlig perspektiv. I kontrast til et utviklingsprosjekt hvor miljø blir liggende i en ødelagt tilstand mye lenger enn de burde fordi de fleste på teamet jobber på egne branches, hvor de ikke — enda — merker problemene. Effekten man forhåpentligvis oppnår er at man får et miljø som er mye mer stabilt å jobbe på, som i prinsippet alltid skal være «prod-klart» — altså at det er i en kjent tilstand som til enhver tid kan produksjonsettes. Dermed jobber også alle på samme, kjente, «kilde» — som reduserer faren for uhyggelige overraskelser når kode merges, eller deployes til et nytt miljø, og — i prinsippet — kan hvem som helst trykke på knappen for å produksjon-sette noe når som helst.
Etter at Quality Day var over var det avdelingsmøte.
Kristian hadde forberedt et innholdsrikt program, hvor vi var innom nytt fra både konsern-nytt som Creuna oppkjøp og andre oppdateringer. Nytt for møtet var at alle kollegaer i teamet ble presentert med bilde og logo fra kunden de har oppdrag hos. Dette ga en fin oversikt over teamet.
Etter avdelingsmøtet ble de som hadde anledning igjen på Teams for sosial “mingling”.
Først ble det gjennomført en quiz på Kahoot. Temaet var Halloween — skrekk og gru.
Vinneren fikk en velfortjent premie som stod i stil med tema i quizen.
Kvelden ble avsluttet med en uoffisiell Knowit Julebrus smakskonkurranse hvor Coop sin røde 1.5 l Julebrus gikk helt til topps!
Until next time, be communicative, but keep a distance!
Mvh. Jon Anders