Kategorier
Nyheder

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
Nyheder Værktøj

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
Nyheder Værktøj

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.

Kategorier
Nyheder

Om test af software

Dette er nogle af de artikler om test som jeg synes der er med til at definere testfaget udover de kendte kurser og certificeringsforløb:

Hvad laver en tester egentligt?

What Do Software Testers Do?

Hvorfor kalder man det for manuel test?

Manual testing never existed

Hvorfor er alle test aktiviteter ikke automatiseret for længe siden? (Hvorfor er det at skrive kode ikke automatiseret for længe siden?)

Test automation – the bitter truth

Hvad er sammenhængen mellem test og automatisering?

The missing link between testing and automation

Nu sidder du sikkert med det indtryk at jeg kæmper en forgæves kamp med begreber som “Manuel test” og “Automatisering”.

Dertil må jeg delvist svare bekræftende. Det er i den grad lykkedes ikke-test-kyndige personer at vanskeliggøre det arbejde jeg er rigtig glad for og også dygtig til, nemlig at teste systemer og software.

Jeg kan kun ærgre mig over at ikke-test-kyndige personer har fået beslutningstagere til at tro på misforståede budskaber om at “manuel test” for alt i verden skal undgås og at “automatisering” er en sølvkugle der kan redde software og fjerne alle fejl inden det sættes i produktion.

Test af software er langt mere end manuel test og automatisering – det er en proces der grænser til forskning og kræver kritisk tankegang og pragmatisme, som det ikke er lykkedes at sætte på formel – endnu.

Jeg vil gerne opfordre dig til at læse artiklerne jeg har henvist til i ovenstående links og når du så spørger dig selv: “Jamen, hvad gør jeg så?”  – så tager du kontakt til mig.

Kategorier
Nyheder

AI seminar hos Testhuset

Mandag den 13. januar 2020 var jeg til AI seminar hos Testhuset i Ballerup.

Seminaret havde to gode indlæg der begge kom rundt om hvad AI er og hvordan man anskuer test i forhold til AI.

En væsentlig ting som jeg bed mærke i omkring AI er at det er dine data som skaber programmet. Principielt er programmet på én linjes kode, nemlig den linje der starter AI’en. Det er de data der fodres til AI’en der bestemmer, hvad den senere er i stand til at udføre.

Et andet væsentligt element er at dine data kan være “biased”. Jeg er ikke helt sikker på hvad det engelske ord skal oversættes med til dansk, men noget i retning af “Partisk” eller “Fordom”.

Data kan indeholde nogle åbenlyse fordomme, f.eks. køn eller religion. Det kan man så fjerne i sine data. Men det forhindrer ikke nødvendigvis at data får fordomme alligevel. Et eksempel er at hvis der om personen i data findes en reference til at vedkommende handler meget i Matas, så kan AI’en drage den konklusion at det må være en kvinde, da det statistisk mest er kvinder der handler i Matas. Selvfølgelig forholder det sig ligeledes med mænd og f.eks. El-giganten eller Silvan.

Der var flere gode emner på seminaret, der virkelig fik sat nogle tanker i gang hos mig og jeg overvejer at deltage i det nye AiU-kursus hos Testhuset.

Hvis du ønsker at læse mere om seminaret er her Top 5 Take-aways.

Kategorier
Nyheder

Forlængelse af kontrakt

Testmakker.dk har underskrevet en forlænget kontrakt med nuværende kunde (som ikke må offentliggøres på dette tidspunkt). Aftalen gælder for 1. kvartal 2020.

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 test af releases med ny funktionalitet, rettelser og mindre forbedringer af et produkt der allerede anvendes i produktion i dag.

Kategorier
Nyheder

Ny kontrakt

Testmakker.dk har underskrevet ny kontrakt med en ny kunde (som ikke må offentliggøres på nuværende tidspunkt). Aftalen gælder for 4. kvartal 2019 med option på 1. kvartal 2020. 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 test af releases med ny funktionalitet, rettelser og mindre forbedringer af et produkt der allerede anvendes i produktion i dag.

Kategorier
Nyheder

Certificeret ISTQB Advanced Level Test Analyst

Den 11. juni 2019 har Jakob Ravnbak bestået eksamen til Dansk-IT’s certificering som ISTQB Advanced Level Test Analyst.

Det betyder forstærkede kompetencer inden for softwareudvikling og -test, specielt inden for testanalyse, testdesign, testimplementering og testafvikling.