Kategorier
Nyheder

Ny kontrakt

Testmakker.dk har underskrevet kontrakt med en ny kunde, May Consulting, på en opgave for Epista A/S.
Aftalen gælder for 7. november 2024 til 31. januar 2025 med option forlængelse.
I følge aftalen skal Jakob Ravnbak arbejde som Test Case Designer og Test Manager i et implementeringsprojekt.

Kategorier
Nyheder

Ny kontrakt

Testmakker.dk har underskrevet kontrakt med en ny kunde, Twins Consulting, på en opgave for Region Hovedstaden.
Aftalen gælder for 26. januar 2023 til 30. juni 2023 med option forlængelse.
I følge aftalen skal Jakob Ravnbak levere test- og testmanagement ydelser i et leveranceprojekt på kundensiden. Projektet inkluderer en leverandør og et antal forskellige fagområder på kundesiden. Opgaven omfatter kvalitetssikring og test af et nyt RIS/PACS system fra den norske leverandør Sectra, der skal understøtte forretningsgange på tværs af alle hospitaler i Region Hovedstaden.

Kategorier
Nyheder Viden om test

Opsummering på 2022

Livet i år 2022 som freelance testmanager er gået sin gang med bump på vejen, der giver erfaring og visdom.
Det er samtidigt god næring til min nysgerrighed.

Min virke som tester betyder, at jeg oplever en masse omkring test-faget i mine opgaver.
Udover det faglige, så er der også oplevelser fra arbejdslivet, der vækker en sund undren i mig.

Det er naturligt at undre sig, så jeg har lavet en undre-liste.

Det undrer mig,

  • at det kun er få personer jeg møder, der har forstået at udskifte ordet “agil” med “fleksibel”
  • at personer med certifikater ikke kan anvende det faglige de har lært(?) i praksis i en opgave
  • at SCRUM bliver opfattet som det at være agil, når nu SCRUM er en (stiv) proces
  • at test stadig opfattes som en dyr tillægsydelse i stedet for som f.eks. en forsikring mod skader (test er også mere end det)
  • at Story Points omregnes til timer med en fast faktor i større organisationer
  • at teams og organisationer stadig tør opbygge en testgæld, fordi “vi har en god risiko appetit”
  • at ledelser tror at automatisering er svaret på testproblemerne
  • at der tages kalendertid fra testaktiviteter og så tror man ikke, det er en risiko
  • at en testmanager kan være det sidste led i en godkendelseskæde, inden produktet lægges i produktion
  • at udviklere kan være nervøse for at få en tester med på teamet
  • at jeg skal forsvare, at test tager tid og at en tester ikke er uddannet på Hogwarts (Harry Potters skole)

Der er mere jeg kan skrive på min undre-liste. Visse elementer holder jeg for mig selv, da det i meget højere grad handler om menneskelige egenskaber og ikke ret meget om noget med test af systemer eller software.

Kategorier
Nyheder

Ny kontrakt

Testmakker.dk har underskrevet kontrakt med en ny kunde i Forsikrings- og pensionsbranchen. Aftalen gælder for 12. september 2022 til 31. december 2022 med option på forlængelse. I følge aftalen skal Jakob Ravnbak levere testmanagement og testanalytiker ydelser i to projekter, der anvender en hybrid leverancemodel. Opgaverne omfatter kvalitetssikring og test af ændringer til et eksisterende produkt, der får en ny udvidelse og et helt nyt produkt, der skal gøre forretningsgangen enklere i forsikrings- og pensionsbranchen. Testen omfatter systemtest, systemintegrationstest, driftaccepttest og brugeraccepttest. Der er områder som nye beregningsfunktioner, nyt API og brugergrænseflade under test.

Kategorier
Nyheder

Ny kontrakt

Testmakker.dk har underskrevet kontrakt med en ny kunde i IT serviceleverandør sektoren. Aftalen gælder for 21. marts 2022 til 31. december 2022 med option forlængelse. I følge aftalen skal Jakob Ravnbak levere testmanagement ydelser i et projekt der anvender en hybrid leverancemodel. Projektet inkluderer en it serviceleverandør og et antal underserviceleverandører. Opgaverne omfatter kvalitetssikring og test af helt ny infrastruktur, nye support og operationelle processer samt enhedshåndtering og servicering af brugere.

En lidt anderledes opgave for en Test Manager, da softwareudvikling ikke udgør hovedparten af opgaven, men alligevel med en hjemmebane fordel i og med, det er gennemført tidligere i lignende projekter.

Kategorier
Viden om test

Testværdigt

Dette er en del af ”The Little Black Book On Test Design” af Rikard Edgren, som jeg har valgt at oversætte til dansk og udgive på denne blog.

Formålet med dette indlæg er at hjælpe testere med at finde den mest testværdige test blandt de til tider uendeligt mange muligheder for at teste, der er at vælge blandt.

På et tidspunkt skal du beslutte, hvilke tests, der skal afvikles og evalueres. Grundlaget for beslutningen kommer frem f.eks. under analyse af testgrundlag, under brainstorm om testideer eller når andre test afvikles.

Sandsynligvis gør du det hele tiden: du tager stilling til hvilke tests, som du finder, er vigtigst – bevidst eller ubevidst. Der er intet magisk i denne proces og den inkluderer mange forskellige faktorer: risiko, hastighed, muligheder, løfter, historik, held eller erfaring.

Du har ikke lyst til at anvende en masse tid på at vælge og prioritere test, så det vil føles helt naturligt at have en grænse, der hedder om noget er testværdigt.

En test er testværdig, når vi mener at den information, som vi kan få ved at afvikle testen, er tiden værd. Altså, informationen er så værdifuld, at det giver mening at bruge ressourcer på testen – uanset risici, krav, testtilgang osv.

Gerd Gigerenzer beskriver i bogen Adaptive Thinking (1) sin teori (der stammer fra Herbert Simon), om at intuition er baseret på heuristik, og at vi bruger hurtige og sparsommelige beslutningstræer for at foretage gode vurderinger i en kompleks verden med begrænset information.

For at kunne forklare og dele et ræsonnement, så giv din intuition noget gennemsigtighed ved at du prøver at bruge et beslutningstræ (2) til testtriage(3):

Rækkefølgen og indholdet af dine spørgsmål kan variere. I dette tilfælde tjekkes hastighed før vigtighed, fordi der er chancer for at finde ting, vi ikke vidste var vigtige.

I den anden ende kan det “relevante” spørgsmål fjerne tests, der ville have været perfekte, men det er OK. Vi kan ikke inkludere alt.

Der er også en balance, hvis det er umagen værd at afvikle testen, se mere på Erik Jacobsons blog indlæg ”Eight Things You May Not Need To Test”, http://www.testthisblog.com/2012/01/eight-things-you-may-not- need-to-test.html

(1) Gerd Gigerenzer, Adaptive Thinking: Rationality in the Real World, Oxford University Press, New York 2000.

(2) Metoden er ikke skudsikker, men den kan give de bedste resultater ifølge Gerd Gigerenzer, Gut Feelings: The Intelligence of the Unconscious, Penguin Group, New York 2007.

(3) More on test triage by Robert Sabourin, What Not to Test, Better Software magazine November/December 2004.

Kategorier
Værktøj Viden om test

Testgrundlag

Når man som jeg har arbejdet med test, så bliver man med tiden klogere på, hvad der skal til for at kunne gøre et godt stykke arbejde med at få testet software, inden det sættes i produktion.

Helt grundlæggende er det vigtigt at forstå at test ikke er et mål i sig selv, men det er en støtteproces til udvikling af software (udviklingsprocessen). Det gælder uanset hvilken udviklingsmodel man har valgt i sin virksomhed, lige fra traditionel vandfaldstilgang og frem til f.eks. SAFe (Scaled Agile Framework) eller LeSS (Large Scale Scrum).

En af de væsentlige input til test er det som vi testere kalder Testgrundlag eller Testbasis.

Testgrundlaget er dokumentation af eller viden om produktet.

I det efterfølgende handler det primært om hvilken dokumentation der er en del af testgrundlaget. Når det handler om viden, der ikke er dokumenteret, kaldes det for orakler – det tager jeg i et andet indlæg.

Indholdet i et testgrundlag kan opdeles i følgende grupper.

Krav

Krav beskriver de ønskede funktionelle eller ikke-funktionelle komponenter eller systemadfærd.

  • forretningskrav,
  • funktionelle krav,
  • systemkrav,
  • epics,
  • user stories,
  • use cases

eller lignende arbejdsprodukter.

Design

Design specificerer komponent eller systemstruktur.

  • diagrammer eller
  • dokumenter,

der beskriver system- eller softwarearkitektur,

  • designspecifikationer,
  • kaldegrafer,
  • modeldiagrammer,
  • grænseflade-specifikationer

eller lignende arbejdsprodukter.

Implementering

Implementering af komponenten eller systemet selv, herunder kode, database metadata og forespørgsler og grænseflader.

Risikoanalyserapporter

Risikoanalyser der kan vurdere funktionelle, ikke-funktionelle og strukturelle aspekter af komponenten eller systemet.

Kvalitetsmål

F.eks. ISO 250xx eller lignende, virksomheds-standarder, branchestandarder, regulatoriske krav

Dækningskriterier

Testgrundlaget (for alle de niveauer eller typer af test, der overvejes) har målbare dækningskriterier specificeret.

Dækningskriteriet kan fungere effektivt som key performance indikatorer (KPI’er) til at styre de aktiviteter, der viser resultaterne af softwaretestens målsætninger.

Eksempel: en mobil app har en liste af krav samt en liste over understøttede enheder. Dette medfører to dækningskriterier: Krav og understøttede enheder.

Når der ikke er et testgrundlag eller et mangelfuldt testgrundlag

Når man som tester får en opgave med af få testet et stykke software, hvor der mangler f.eks. krav, beskrivelser, forretningsflows og lignende, så står man allerede to skridt bagud i forhold til at få løst sin opgave.

Der er ingen vej uden om at få fremskaffet tilstrækkelig information om softwaren og den forretning, hvor softwaren skal passe ind.

Det betyder at testeren går i detektiv-mode og prøver at opsnuse så meget information som muligt fra alle de mulige kilder, der er tilgængelige.

Min oplevelse er at den type af information, der er sværest tilgængelig, er den viden der sidder i hovedet på nøglepersoner (kaldet orakler af testere). Det næstsværeste er at have et referencesystem (også kaldet orakel) til rådighed (et system der skal erstattes med noget nyt).

For meget ofte har har nøglepersoner ikke tilstrækkelig tid til at levere informationen – sætningen “du kan bare spørge hvis du vil vide noget” kan tage modet fra selv den bedste tester. Lidt det samme med referencesystemer, hvor der sjældent er noget dokumentation og de personer der oprindeligt har fremstillet systemet er ikke længere til rådighed. Gys.

Så jeg har et meget firkantet udsagn, indrømmer jeg, men alligevel:

“Ingen testgrundlag – ingen test”.

 

Kategorier
Værktøj Viden om test

Definition of Done

Hvis du er tester eller testmanager i softwareudviklingsprojekter, så har du helt sikkert ligesom jeg stiftet bekendskab med begrebet “Definition of Done” og kender til værdien af, at bruge denne definition aktivt i projekt- eller teamarbejde.

Desværre oplever jeg stadig ledere, som siger “koden er færdig, så I kan bare teste løs”. Så gælder det om at være diplomatisk i sit svar til pågældende, for selvfølgelig er koden ikke færdig, når testen ikke er gennemført med et accepteret resultat. Eller hvad? I virkeligheden kender lederen måske ikke til Definition of Done for lige netop den del af produktet eller også er der slet ikke defineret noget.

Så her er min forklaring på begrebet “Definition of Done”:

  • ”Definition of Done” forkortes som ”DoD”.
  • DoD er en tjekliste over værdiskabende aktiviteter, der kræves for at producere software.
  • DoD er den primære rapporteringsmekanisme for teammedlemmer.
  • DoD er en kontrollerbar tjekliste.
  • DoD er ikke en statisk størrelse.
  • DoD er ikke produktkrav.

DoD er formet af virkeligheden eller den kontekst, hvor den indgår, f.eks.:

  • DoD for en feature (User Story eller Product Backlog Item eller lignende)
  • DoD for en iteration (sprint i Scrum sprog) (En samling af features udviklet indenfor en iteration)
  • DoD for en release (potentielt mulig at sætte releasen i produktion)

Når jeg skal afgøre, hvor i udviklingsforløbet at en aktivitet til DoD hører til, stiller jeg følgende spørgsmål:

  1. Kan vi udføre denne aktivitet for hver feature? Hvis ikke, så
  2. Kan vi udføre denne aktivitet for hver iteration? Hvis ikke, så
  3. Vi skal udføre denne aktivitet før vores release!

Lad os kigge på nogle eksempler på en User Story med Acceptkriterier og Definition of Done:

User Story:

Som bruger ønsker jeg at kunne resette mit password, så jeg kan komme ind på min konto, når jeg har glemt mit password.

Acceptkriterier:

Når en bruger fejler sit log-in gives der mulighed for at opdatere password.
Når password resettes med en ukendt e-mail-adresse, skal der ikke sendes en e-mail og der skal gives besked om at e-mail-adressen er ukendt.
Når password resettes skal det nye password bekræftes.

Definition of Done:

  1. Unittest gennemført
  2. Koden er refaktoreret
  3. Koden er kommenteret
  4. Unittesten er automatiseret med en kodedækning på min 70%
  5. Feature’en er testet af teamet i samarbejde med PO
  6. Dokumenteret (just enough)
  7. Dokumentationen er reviewed
  8. Ikke-funktionelle test er gennemført
  9. Regressionstest gennemført som afsluttende test

Blot for at slå det helt fast: I dette eksempel er den pågældende User Story først helt færdig, når alle aktiviteter på DoD er gennemført!

I eksemplet har jeg brugt en User Story, men jeg kunne også have betragtet et sprint eller en release, hvilket vil indeholde andre aktiviteter, som i den sammenhæng skaber værdi at gennemføre.

Det er vigtigt at have Definition of Ready på plads inden man overhovedet begynder på arbejdet. Jeg ved godt, at det her er i omvendt rækkefølge, Definition of Ready er først, og jeg vil ikke gå i detaljer med ovenstående eksempel. Jeg vil blot dele den tjekliste, jeg ofte anvender, når jeg arbejder med Definition of Ready:

Definition of Ready:

  1. Indeholder alle tre felter (hvem, hvad og hvorfor)
  2. Forstås af udviklingsteamet
  3. Har et målbart udbytte
  4. Beskriver en funktion som ikke indeholder en løsning
  5. Opfylder INVEST-kriteriet (Independent, Negotiable,
  6. Valuable to Customer, Estimatable, Small, Testable)
  7. Har acceptkriterier som teamet forstår
  8. Definerer brugeren som en rolle
  9. Identificerer ethvert support-dokument som er relevant
Kategorier
Nyheder

Ny kontrakt

Testmakker.dk har underskrevet ny kontrakt med en tidligere kunde. Aftalen gælder for 1. februar 2021 til 31. januar 2022 med option forlængelse. I følge aftalen skal Jakob Ravnbak levere test- og testmanagement ydelser i et projekt der anvender en hybrid agil udviklingsmodel. Projektet inkluderer en softwareleverandør og et større antal partnere og aktører. Opgaverne omfatter kvalitetssikring og test af to helt nye systemer der skal understøtte forretningsgange på tværs af aktørerne i den finansielle sektor.

Kategorier
Nyheder

Ny kontrakt

Testmakker.dk har underskrevet kontrakt med en ny kunde i pensionsbranchen. Aftalen gælder for perioden juni – december 2020 med option på yderligere forlængelse.I følge aftalen skal Jakob Ravnbak levere test- og testmanagement ydelser i et projekt der anvender en hybrid agil udviklingsmodel. Opgaverne omfatter test af releases til et helt nyt produkt for kunden, et produkt der skal erstatte flere forældede it-systemer.