testmakker.dk
Testmakker.dk har forlænget den nuværende aftale med yderligere 3 måneder frem til og med 28. februar 2019, hvor Jakob Ravnbak skal levere test- og QA-ydelser på opgaver i et projekt som KMD udfører for e-Boks.
Aftalen er indgået gennem ProData Consult.
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!
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.
Testmakker.dk har forlænget den nuværende aftale med yderligere 2 måneder til og med november 2018, hvor Jakob Ravnbak skal levere test- og QA-ydelser på opgaver i et projekt som KMD udfører for e-Boks.
Aftalen er indgået gennem ProData Consult.
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.
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.
Der er åbnet for tilmelding til årets DSTB test konference og jeg deltager i år.
Jeg håber på at se tidligere kollegaer og kunder og få en god omgang networking med ligesindede indenfor test faget.
Testmakker.dk har indgået en ni måneders aftale i perioden fra januar til og med september 2018, hvor Jakob Ravnbak skal levere test- og QA-ydelser på opgaver i et projekt som KMD udfører for e-Boks.
Aftalen er indgået gennem ProData Consult.
Min overordnede tilgang er at omkostningerne til testaktiviteter under udvikling af ens software applikation skal stå i forhold til de risici for tab der kan være, hvis applikationen svigter under drift.
Det er her det gælder om at finde det rette “sweet spot”: Hvor meget vil man investere i forebyggelse af fejl og svigt inden applikationen sættes i drift kontra hvilke omkostninger man kan tåle ved svigt, når forretningen er blevet afhængig af applikationens funktionalitet.
A = B+C: (”Sweet spot”) Omkostninger ved kvalitet; Summen af udgifter til forebyggelse/opdagelse af fejl og udgifter ved svigt.
B: Udgifter til forebyggelse/opdagelse af fejl;
C: Udgifter ved svigt;
Test skal sammen med kunden forberedes og gennemføres på baggrund af løbende risikovurderinger helt fra forretningsniveau, hvor produktet med tiden forventes at fungere, og ned til de enkelte funktioner der er indlejret i og udgør det samlede produkt.
Test skal udføres i hele produktets levetid, fra vugge til grav, i en veltilpasset målestok, med et defineret formål og efter fornuftige processer.
Nogle organisationer har en generel testmetode, som i et vist omfang er fleksibel mht. indhold, men kan være strengt kontrolleret af dikterede processer. Det kan have sin relevans at teste sit produkt efter en sådan metode, hvis man ønsker at sende en raket til Mars med mennesker ombord eller hvis man har et farmaceutisk præparat til brug på mennesker. Der kan i stedet for menneskeliv være store værdier på spil, som man vil undgå at tabe, f.eks. i en bank eller en pensionsfond.
I disse tilfælde kan en generel testmetode efter en kendt model, måske endda reguleret ved lov, være en hensigtsmæssig fremgangsmåde for at imødegå uventede overraskelser.
I andre organisationer kan test efter en tilpasset eller skabt-til-formålet testmetode være tilstrækkeligt.
Hvert produkt har sin helt egen karakter der defineres af en række egenskaber. Det medfører samtidigt at den test man ønsker at udsætte produktet for er nødt til at være tilpasset til formålet.
Det vigtigste formål med test er at man skal indsamle informationer nok til at kunne evaluere produktet og samtidigt nok til at lære produktet tilstrækkeligt godt at kende.
Derfor skal der ikke testes for lidt for så kan der komme for mange overraskelser senere. Der skal heller ikke testes for meget, da omkostningerne kan blive højere uden at man lærer mere om produktet og tiden indtil produktet kan tages i anvendelse kan blive længere end planlagt.
Testmanagerens indsats sikrer en kvalificeret og struktureret håndtering af testaktiviteterne. Testmanageren etablerer en løbende fokusering på de kvalitetsmæssige egenskaber af produktet i projektet.
Testmanageren leverer informationer til ledelsen der gør det muligt at træffe de bedste beslutning i den givne situation ud fra en kvalitativ og objektiv status på produktets tilstand.
Testmanageren styrer testforløbene fra projektets start til aflevering af det endelige produkt og bidrager til at ledelsen kan fokusere på at styre projektet sikkert i det ønskede mål.
Jeg var projektdeltager med titel af Test Manager på et transitionsprojekt for en kunde hvis formål var en total flytning af eksisterende it-systemer og kunde- og virksomhedsdata til en ny software- og hardware platform hos en ny hosting partner. Projektet havde en forventet levetid på 18 måneder og et budget på 18 mio DKK.
Projektet endte med at bruge i runde tal ca. 1 mio DKK i hele projektets levetid på at forberede og gennemføre test løbende på delleverancer. Samtidigt havde projektet hensat ca. 2 mio DKK til reserver for det tilfælde at delleverancerne var fejlbehæftede, mangelfulde, forsinkede eller lignende.
Ud af 24 delleverancer blev der afleveret 24 til tiden. Der var ingen fejl eller mangler som forhindrede ibrugtagning af kunden og kunden oplevede efter ibrugtagningen få og mindre problemer, som kunne løses indenfor samme dag.
Projektet blev ikke pålagt dagbøder eller andre reklamationer. Kunden havde ingen produktionstab eller datatab.
Det var en god forretning at teste i projektet.
| Cookie | Varighed | Beskrivelse |
|---|---|---|
| CookieLawInfoConsent | 1 year | No description |
