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

Testing Mnemonics

“A mnemonic device is a mind memory and/or learning aid. Mnemonics rely on associations between easy-to-remember constructs which can be related back to the data that is to be remembered.”, Wikipedia.

The following is a list of software testing related mnemonics. This is something I have collected from different testing resources around the testing community. I try on a regular basis to keep them updated.

Kategorier
Værktøj

Test Management tool

Når jeg arbejder med test i projekter er gode værktøjer vigtige for hvor effektivt jeg selv kan arbejde, men specielt også for hele test teamets success med at opsamle den dyrebare information der findes under test processen.

Mit favorit test management værktøj for tiden er Testrail fra Gurock.com. Efter min mening er det et fornuftigt kompromis mellem tilgængelighed, integrationsmuligheder, funktionalitet og pris.