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.

ISTQB Advanced Test Analyst

I april, maj og juni måned deltager Jakob Ravnbak på ISTQB Advanced Test Analyst kursus hos Testhuset.dk.

Målet er at få genopfrisket og opdateret viden om testdesignteknikker til test af software, så fremtidige kunder og testkollegaer får glæde af en Testmanager, der også er kompetent på hvordan test cases udvælges og designes.

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

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.

Læs videre “Testing Mnemonics”

GDPR – Privacy by Design

Jeg har været på kursus vedrørende GDPR, Privacy by Design med Agge Kempff-Andersen (privacytree.eu).

Kursets beskrivelse lyder:

“På dette kursus lærer du hvad Privacy by Design betyder og hvilke overvejelser du skal gøre dig, når du designer og bygger løsninger, der involverer persondata. Herunder vil du få en introduktion til hvordan du kan indarbejde Privacy by Design i din udviklingsproces og få indsamlet lovpligtig dokumentation.

Du vil få en generel introduktion til hvad persondata er; samt nogle teknikker til hvordan man kan forsøge at beskytte allerede indsamlede persondata ved at bruge teknikker som data maskering, aggregering, pseudonymisering, kryptering m.m.”

I min typisk rolle som Test Manager i projekter er dette meget interessant.

For det første er det ofte en stor opgave at finde eller konstruere testdata til sine testforløb. Med GDPR er der kommet ekstra at tænke over, men samtidigt virker det også som om GDPR forordningen giver en hjælpende hånd med de overvejelser man skal gøre sig omkring testdata.

For det andet så er det med GDPR forordningen blevet lidt sværere at anvende ressourcer til testopgaver der er lokaliseret udenfor EU. Det skal jeg som Test Manager også været opmærksom på.

Tak for kurset, Agge!

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.