Kategori: Viden om test

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
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
Viden om test

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
Viden om test

Tanke om test trend i 2019

Mange steder udskiftes ordet “test” med QA (Quality Assurance) for at gøre test-faget mere legitimt.
Desværre er det uheldigt da QA og test i oprindelig betydning ikke nødvendigvis er det samme, men der er et overlap.
Jeg oversætter forkortelsen QA til “Question Asker” som tester. Jeg stiller spørgsmål og finder svar og derigennem kan kvaliteten af produktet evalueres.

“Quality is value to some person, at some time, who matters.“
– Jerry Weinberg, James Bach og Michael Bolton

Kategorier
Værktøj Viden om test

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.

Fortsæt læsning “Testing Mnemonics”
Kategorier
Viden om test

Test cases er ikke test

På min vej i softwarens verden i projekter eller i organisationer møder jeg den dag i dag stadig mange personer i Danmark der har et snævert syn på test af software – alt for snævert. Og ja, ordene “test cases” dukker op i næsten alle de samtaler jeg har med disse personer, når dialogen falder på emnet “test”.

Jeg bryder mig ikke om, at den professionelle karriere jeg har valgt som levevej, som jeg har taget uddannelser indenfor, betragtes som noget simpelt og nemt.

Jeg forstår godt de spørgsmål jeg umiddelbart bliver mødt af, når jeg befinder mig blandt ikke-testkyndige, men beslutningsdygtige personer. F.eks. “Hvorfor skal du bruge så meget tid til test?”, “Er det værktøj virkelig nødvendigt?”, “Hvorfor automatiserer du ikke bare testen?”, “Hvorfor har du brug for design dokumentation?”, “Hvor mange test cases tror du der er brug for i dette projekt?”. Og mange flere lignende spørgsmål.

Nogle gange føler jeg at mine kompetencer bruges mere på at lære beslutningstagere op i testfaget end at jeg får lov til at udføre mit arbejde. Det er blevet et vilkår i mit fag – at oplære andre i det.

I magasinet “Testing Trapez”, udgave februar 2014 kan du finde en rigtig god og også vigtig artikel, som jeg foreslår at du læser, hvis du er tester.

TEST CASES ARE NOT TESTING:  TOWARDS A CULTURE OF TEST PERFORMANCE (side 30)
Af James Bach, Washington, USA og Aaron Hodder, Wellington, New Zealand

Testing is the evaluation of a product by learning about it through experiment; by seeing it in action. The reason we test is to analyse product risk: the danger that the product will cause trouble for its users or otherwise fail in some way to fulfill its purpose. In other words, we look for anything about the product that might significantly impair its value. We are looking primarily for “bugs.” We want to find every important bug, although there will be no way to know for sure that we have succeeded.

Jamen, hvad er en test case så?

Nu vil jeg forklare det med en analogi. Her skal man huske på at der er en fælde ved at anvende analogier. Nemlig, at man altid kun fokuserer på hvor analogien passer sammen med det man gerne vil forklare. Men man glemmer at forklare hvor og hvorfor analogien ikke passer helt. (det var et side spring).

En test case kan bedst beskrives som en opskrift. Altså en beskrivelse af hvordan man gennemfører en bestemt aktivitet. Her vil jeg sammenligne det med en opskrift på en omgang aftensmad (min analogi).

En opskrift indeholder ingredienserne du skal bruge i de rette mængder, beskrivelse af fremgangsmåde, den forventede tilberedningstid og nogle gange endda den ernæringsmæssige energifordeling og om det færdige resultat er fryseegnet.

Opskriften fortæller nogle gange om hvilke værktøjer du skal bruge, men ikke hvordan du bruger dem og sjældent om alle værktøjerne. Der står aldrig, hvordan opskriften er opstået eller blevet udviklet, måske noget om oprindelsessted. Nogle opskrifter anvender endda fagudtryk, hvor du må slå op andetsteds, for at forstå hvad det betyder.

Sidst, men ikke mindst: Det er heller ikke forklaret hvilken oplevelse du får når du spiser retten – det ved du først når du smager på det færdige resultat.

Hvis jeg skal konkludere på ovenstående:

En test case er en opskrift (dokumentation).

En test case kræver ofte forkundskaber og altid viden.

En test case er ikke en internationalt defineret enhed.

Test case indholdet vil variere – fra test case til test case.

En test case kan hjælpe dig frem til information om dit produkt, men først når du bruger dit produkt.

Kategorier
Viden om test

A Practical Guide to Testing in DevOps

Katrina Clokie har udgivet en e-bog der handler om test af software i et DevOps setup.

Nu vil jeg ikke forsøge mig med at anmelde bogens indhold, det er der flere andre der har gjort (se linket ovenfor).

Jeg vil nævne at det er en bog med god inspiration til dig, der skal finde dine ben at stå på i DevOps som tester. For selvom DevOps flere steder er beskrevet som om der næsten ikke findes test (ligesom i flere andre rammeværk, f.eks. SAFe), så bliver der stadig testet på livet løs. Og ja, dine færdigheder indenfor testfaget er der stadig brug for, blot i en lidt anden kontekst.

Det var en fornøjelse for mig at læse den og jeg blev klogere på test i DevOps.

Kategorier
Værktøj Viden om test

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.