Hos Key2Quality har vi fornøjelsen af at have et stærkt aspirantteam, hvor nye talenter udvikler sig i takt med, at de skaber værdi for vores kunder. Blandt dem er Morten Engberg – en engageret og proaktiv junior testkonsulent, der med sin analytiske tilgang og passion for kvalitet bygger bro mellem IT og forretning.

Morten er cand.it. i IT, Kommunikation og Organisation fra Aarhus Universitet og har siden september 2024 været en del af vores aspirantforløb, hvor han målrettet opbygger sine kompetencer inden for test og kvalitetssikring gennem både certificeringer og hands-on erfaring.

Morten er videbegærlig og nysgerrig af natur, og han trives med nye faglige udfordringer, som skubber til hans udvikling. Han er ikke bange for at tage initiativ, og han bidrager gerne, hvor han kan se, at der er mulighed for at gøre en forskel – og lære noget nyt!

Han trives i teams, hvor han møder både kolleger og kunder i øjenhøjde, og hans styrke ligger i at omsætte tekniske detaljer til løsninger, der skaber reel værdi – altid med samarbejde og kvalitet i centrum.

Hvad kan du godt lide ved at arbejde som konsulent?

Som konsulent bliver jeg hele tiden udfordret i nye kontekster, miljøer og teknologier. Det betyder, at jeg konstant skal være nysgerrig og omstillingsparat – og det driver virkelig min faglige og personlige udvikling. Jeg lærer noget nyt hver gang, jeg træder ind i et nyt projekt, og det er både spændende og givende.

Hvordan hjælper du vores kunder med at skabe værdi? Hvordan gør du en forskel for dem?

Som testanalytiker bidrager jeg ved at skabe overblik og tydelighed. Jeg bruger min analytiske tilgang til at vurdere risici og identificere, hvor testindsatsen bør fokuseres. Det handler om at placere indsatsen, hvor den skaber mest værdi – og samtidig sikre, at testdesign og test cases understøtter det overordnede mål.

På den måde bidrager jeg til mere effektive testforløb og en mere robust løsning for kunden.

Hvad er dit faglige speciale? Hvorfor netop det, og hvordan kommer det i spil i dine opgaver?

Mit speciale er testanalyse – kombineret med en spirende interesse for testautomatisering og teknisk test.

Jeg er fascineret af, hvordan automatisering kan styrke testindsatsen og effektivisere arbejdsgange. Derfor bevæger jeg mig målrettet i den retning, samtidig med at jeg styrker mine kompetencer på området. Det er et område, hvor jeg oplever stort fagligt potentiale – og hvor jeg kan kombinere analyse og teknik på en meningsfuld måde.

For som jeg ser det, handler automatisering er ikke bare om teknik – det er en genvej til kvalitet, der virker i praksis.

Hvad motiverer dig mest i dit arbejde?

Jeg bliver motiveret af at lære – og af at udvikle mig fagligt. Hver gang jeg træder ind i et nyt miljø, får jeg ny indsigt og nye perspektiver. Det udfordrer mig – og det holder mig skarp. Det er den faglige progression, der driver mig.

Hvordan holder du dig opdateret og skarp i dit felt?

Jeg er nok lidt af en nørd, når det kommer til ny viden. Jeg følger aktivt med i udviklingen inden for test og teknologi via fagmedier som Ingeniøren, ITWatch og internationale tech-sider.

Derudover deltager jeg i kurser og certificeringsforløb – både via Key2Quality og i min fritid.

Jeg har ikke en udviklerbaggrund, så jeg arbejder målrettet på at opbygge mine kompetencer inden for testautomatisering og teknisk test. Det kræver en ekstra indsats – men det er en investering, jeg glæder mig over hver dag.

Hvordan ser en typisk arbejdsdag ud for dig?

Dagen starter typisk med et standup-møde, hvor teamet deler status og planlægger dagens opgaver. Derefter skaber jeg overblik over mine egne opgaver – og så går jeg i gang.

Når jeg ikke er tilknyttet en kundeopgave, bruger jeg tiden på selvstudier og på at bidrage til vores interne qAI-projekt – blandt andet via test. Det er en god måde at holde sig i gang og udvikle sig mellem opgaver.

Hvad kendetegner en god konsulent, efter din mening?

En god konsulent møder kunden i øjenhøjde, lytter og forholder sig objektivt til både problemstillinger og behov.

Det handler om at skabe værdi – både fagligt og menneskeligt. Man skal kunne sætte sig ind i kundens situation og handle ud fra den – og samtidig turde stille de rigtige spørgsmål og udfordre, når det er nødvendigt.

Er der et projekt eller en opgave, som du bliver særligt glad eller stolt af at tænke tilbage på?

I mit seneste projekt som testanalytiker tog jeg initiativ til at drive et automatiseringsprojekt videre – selvom jeg ikke havde erfaring med det på forhånd.

Sammen med en erfaren testmanager lykkedes det at opbygge en ny, strømlinet struktur, som gjorde det muligt for kunden faktisk at anvende løsningen i praksis. Det var en stor sejr – både for projektet og for min personlige udvikling.

Hvad laver du, når du ikke er på arbejde? Har du en særlig passion?

Jeg elsker at være i naturen – uanset om det er i skoven eller ved vandet. Naturen giver mig ro og rum til refleksion, og det er vigtigt i en travl hverdag.

Det er dér, jeg finder ny energi – og dér, jeg lader op, så jeg kan være den bedste version af mig selv både privat og professionelt.

Har du et yndlingscitat eller et motto, der afspejler din tilgang til dit arbejde – eller livet som konsulent?

Ja – for nu at fejlcitere Pippi Langstrømpe:

“Det har jeg ikke prøvet før, så det kan jeg sikkert godt.”

Det opsummerer meget godt min tilgang. Jeg er ikke bange for at kaste mig ud i noget nyt – og jeg tror på, at man vokser af at tage chancer og lære undervejs.

Hvordan vil du beskrive Key2Quality med tre ord?

Rummelighed, høj faglighed og glæde.

Her er højt til loftet og plads til forskellighed. Vi kender hinanden godt, støtter hinanden og har det sjovt undervejs. Samtidig oplever jeg stor faglig inspiration i samarbejdet med mine kolleger – og en kultur, hvor vi virkelig trives sammen. Det betyder meget – både for fagligheden og for arbejdsglæden.

Har du brug for en engageret og proaktiv junior testkonsulent, der med sin analytiske tilgang og passion for kvalitet bygger bro mellem IT og forretning?

Så er Morten Engberg måske det rette match!

Kontakt områdeleder for IT-kvalitetssikring og senior konsulent, Jonas Sloth på 4940 2794 eller jonas@key2quality.dk.

The post Mød en konsulent: Morten Engberg appeared first on Key2Quality.

The post Rikke kombinerer sine kompetencer som testmanager med rollen som Scrum Master appeared first on Key2Quality.

Hos Key2Quality er vi så privilegerede at huse nogle fantastisk dygtige konsulenter. Konsulenter, som alle skaber værdi for vores kunder med deres kompetencer inden for softwaretest, IT-kvalitet og IT-projektledelse. En af dem er Alberte Sørensen – en engageret og grundig testkonsulent, der med sit skarpe blik for detaljen og sin analytiske tilgang bidrager til at løfte både kvalitet og samarbejde i de projekter, hun indgår i. 

Som testkonsulent hos Key2Quality har Alberte oparbejdet solid erfaring med testanalyse, testdækning, udarbejdelse og forbedring af testcases samt test management. Hendes evne til at strukturere, koordinere og skabe overblik gør hende til en stærk ressource i komplekse projekter. 

Tidligere kunder beskriver hende som “meget opsøgende, proaktiv og ikke bange for at udfordre – hun siger til, hvis der er noget, man skal være opmærksom på.” Det er netop denne kombination af faglighed og integritet, der gør hende til en værdsat kollega og konsulent. 

Alberte er også en vigtig del af holdet internt i Key2Quality, hvor hun fungerer som mentor for vores aspiranter og bidrager til at løfte det faglige niveau i organisationen. 

Hun er uddannet cand.it. i Informationsvidenskab fra Aarhus Universitet (2021) og har en stor faglig nysgerrighed, som afspejler sig i hendes tilgang til læring. Alberte elsker at lære nyt – og går gerne til eksamen. Trods sine kun 30 år har hun derfor allerede opnået certificeringer i hele fem anerkendte kurser inden for ISTQB og TMAP. Men som hun selv siger med et glimt i øjet: 

“Jeg må nok hellere vente med at tage ‘ISTQB Expert Test Manager’, til jeg har lidt flere års erfaring.” 

Hvad kan du godt lide ved at arbejde som konsulent?

Jeg trives med variationen og muligheden for at dykke ned i forskellige typer IT-projekter og organisationer. Det giver mig en bredere forståelse og udfordrer mig fagligt. Jeg nyder processen med at identificere potentielle problemer og bidrage til at finde løsninger, da det styrker min testfaglighed i forskellige kontekster.

Hvordan hjælper du vores kunder med at skabe værdi? Hvordan gør du en forskel for dem?

Jeg arbejder målrettet for at sikre kvaliteten i projekterne. Det handler om at teste de rigtige ting på det rigtige tidspunkt og skabe overblik, så kunden kan træffe informerede beslutninger før go-live. Jeg trives også i en coachende rolle, hvor jeg hjælper teamet med at anvende testfagligheden effektivt i deres arbejde.

Hvad er dit faglige speciale? Hvorfor netop det, og hvordan kommer det i spil i dine opgaver?

Mit speciale er test og kvalitetssikring, hvilket passer godt til min detaljeorienterede og analytiske tilgang. Jeg stiller ofte de spørgsmål, som andre måske overser, og jeg dykker ned i komplekse systemer for at forstå, hvad der fungerer, og hvad der kan forbedres. Min grundighed og realisme i forhold til deadlines er også en styrke i mit arbejde.

Hvad motiverer dig mest i dit arbejde?

Jeg motiveres af at løse testfaglige udfordringer, især i samarbejde med engagerede kunder og kollegaer. Det giver mig energi at se, hvordan mit arbejde gør en forskel og bidrager til projektets succes.

Hvordan holder du dig opdateret og skarp i dit felt?

Jeg holder mig fagligt skarp ved at tage relevante certificeringer og arbejde med vores e-learning-platform, som både udfordrer og udvider min viden. Derudover deltager jeg aktivt i interne guildmøder og søger inspiration fra forskellige kilder, herunder ChatGPT, for at få nye perspektiver.

Hvordan ser en typisk arbejdsdag ud for dig?

Mine arbejdsdage varierer afhængigt af opgaven. Som test lead involverer en typisk dag møder, koordinering og planlægning med forskellige interessenter som release management og projektledelse. Jeg sparrer også med teamet om opgaveprioritering og problemløsning. I andre projekter fokuserer jeg mere på analysearbejde, hvor jeg kortlægger testgrundlaget og vurderer anvendelsen af testdesignteknikker.

Hvad kendetegner en god konsulent, efter din mening?

En god konsulent udviser ordentlighed, faglighed og glæde. Med ordentlighed mener jeg, at konsulenten er problemløsende, proaktiv og transparent i sin kommunikation. Det er vigtigt at afstemme forventninger med kunden og være ærlig om, hvad der er muligt. Fagligheden er selvfølgelig også vigtig. Understøttet af et stærkt bagland giver den faglige ballast troværdighed og gennemslagskraft. Glæde og engagement er også afgørende, især for at løfte teamets motivation og opbygge de relationer, som gør, at teamet skaber reel værdi.

Er der et projekt eller en opgave, som du bliver særligt glad eller stolt af at tænke tilbage på?

CRM-projektet for en kunde i energisektoren var både spændende og komplekst, og jeg arbejdede sammen med mange dygtige mennesker. Det var en opgave, der virkelig udfordrede mig og gav mig mulighed for at anvende mine færdigheder fuldt ud.

Hvad laver du, når du ikke er på arbejde? Har du en særlig passion?

Jeg nyder god mad, især når jeg ikke selv skal lave den, og jeg værdsætter tid med mine nærmeste. Jeg holder også af at være i naturen og tager ofte på vandre- og shelterture. I efteråret 2024 gik jeg for eksempel Caminoen, som længe havde stået på min ønskeliste.

Hvordan vil du beskrive Key2Quality med tre ord?

Ordentlighed, faglighed og glæde. Disse værdier gennemsyrer vores arbejde og samarbejde med kunderne.

The post Mød en konsulent: Alberte Sørensen appeared first on Key2Quality.

The post Hvorfor skal udviklere lære mere om test? appeared first on Key2Quality.

The post Er testmanagement-rollen død? appeared first on Key2Quality.

Tilmelding til seminar

Tilmeld dig via formularen herunder.

Når du har tilmeldt dig, modtager du automatisk en bekræftelse pr. mail.

Navn

Indtast din e-mail

Titel

Firma

Vælg dato for seminar

13. november 2024: AI i test og kvalitetssikring

Evt. besked

Send

The post Når brugerne tester: Derfor er grundlæggende testforståelse afgørende appeared first on Key2Quality.

En af de rigtig store udfordringer i softwareudvikling er den allerførste, vi støder på; at forstå hvad vores bruger/kunde har brug for. Uanset udviklingsmodel så er det en af de største udfordringer i forhold til en succesfuld løsning. Alt for mange af de fejl, vi opdager under accepttest og i produktion, kommer af misforståede krav, eller krav vi slet ikke kendte til.

Måske kender du denne tegning? Den illustrerer det så godt:

Tanken med definitionen af værdisættet og principperne omkring det agile manifest (www.agilemanifesto.org)  var netop, at de forskellige grupper skulle komme tættere sammen, at vores største fokus skulle være på at skabe værdi for vores kunder (husk det første princip: ”Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”.) Men vi kæmper med at gøre det i praksis. Har I f.eks styr på jeres user stories og acceptkriterier? Kender teamet til de arbejdsgange og processer, som jeres system skal supportere? Er forretningen en flittig gæst i jeres team/tog/squad?

Misforståede krav giver ubrugelige løsninger

Måske sidder du på kundesiden af et projekt med ekstern leverandør, og skal have styr på, hvad det egentlig er for nogle test-scenarier, I skal lave for at få valideret, at kravene fra jeres brugere er opfyldt, men har kun en laaaang liste af krav i et kravdokument eller regneark? Alt for ofte er det desværre det eneste grundlag, vi har, for at forstå vores brugeres behov, og alt for ofte overser vi noget eller også misforstår vi deres krav. Jeg tror ikke, jeg er den eneste, der har siddet til en accept test og har skullet finde op og ned i de observationer, kundens testere gjorde i forhold til, hvad der var kravsat, og har kunnet konstatere, at brugerne ikke mente, de kunne bruge løsningen i praksis – det ikke var ”fit for purpose” og understøttede deres arbejdsgange og behov.

Kontekst og behov skal være grundlag for test

For mig er det helt fundamentalt at forstå de arbejdsgange, vi skal understøtte. Vi skal bidrage til at få dem identificeret og dokumenteret, og  bruge dem som udgangspunkt, når vi gennemfører en test.. Det sidste er i allerhøjeste grad tilfældet i konteksten af formelle accepttests og afleveringsforretninger, men bestemt også i den løbende test i teamet – det er for sent at opdage at vi ikke er ”fit for purpose” når vi står til vores accepttest lige før vi går i produktion.

Tre konkrete redskaber til til dokumentation af behov, og grundlag for test

Flowdiagrammer

Hidtil har jeg brugt klassiske data flowdiagrammer som dokumentation og som udgangspunkt for testteknikken, procescyklustest (PCT). Samtidig kan flowdiagrammer være et godt udgangspunkt, når vi diskuterer selve løsningen af en konkret problemstilling. De hjælper os at afklare de valg, vores brugere har i et givent beslutningspunkt, og hvad output for deres handling bliver.

Business Process Model and Notation (BPMN)

Der er mange måder og metoder at gøre det på, men fælles for dem alle er, at det vigtigste til hver en tid er dialog og fælles forståelse for arbejdsgangene, vi skal understøtte–og hvad det betyder for den løsning, vi skal lave. I forbindelse med min akkreditering som underviser til ISTQB Foundation Acceptance Testing blev jeg introduceret til et par andre metoder, der har tilsvarende formål og giver rigtig god værdi. Den, der bedst kan sammenlignes med ovenstående, er Business Process Model and Notation (BPMN), som også er en del af uddannelsen som forretningsanalytiker. Denne metodik benyttes til grafisk at gengive forretningsprocesser og har et fast regelsæt for notation, der er nem at gå til, og som kan skabe en mere rig illustration end det traditionelle dataflow diagram som vi bruger det til PCT.

Decision Model and Notation

En anden testdesignteknik, der også har en søster ovre hos forretningsanalytikerne, er teknikken beslutningstabeller (Decision tables). I konteksten af forretningsanalyse er der en tilsvarende metode der hedder Decision Model and Notation (DMN). En beslutningstabel er et fantastisk værktøj til brug i både test og kravdefinition. Den hjælper med at formulere krav, når man beskæftiger sig med komplekse forretningsregler. Beslutningstabeller bruges til at modellere kompliceret logik, og gør det nemmere at se de forskellige kombinationer af betingelser, der skal overvejes.

Igen en metode der visualiserer krav og danner et godt fundament for at kunne diskutere behov og løsning. Og som efterfølgende danner grundlag for vores acceptest.

Men hvis du kigger i din værktøjskasse af testdesignteknikker, så vil du opdage, at flere af dem er rigtig gode til det indledende arbejde med at afklare brugerens behov. Det kræver bare lidt kreativ brug af dem. Jeg har også med godt resultat brugt f.eks. klassifikationstræer som illustrationsmetode når jeg diskuterer funktionalitet med en bruger, som en del af at forstå datakombinationer og deres output.

Deltag i Key2Quality kurset om ISTQB Foundation Acceptance Testing

Hvis du er nysgerrig efter at lære mere om, hvordan de to roller forretningsanalytiker og testanalytiker med fordel kan spille sammen, skabe mere værdi som team, og hvordan det påvirker kvaliteten af de accepttests,vi laver, så meld dig til vores kursus ISTQB Foundation Acceptance Testing. Kurset foregår online 24 – 26 marts.

The post Den gode accepttest appeared first on Key2Quality.

Hører du tit sætninger som ”vi laver risikobaseret test”, læser master testplaner, hvor der står en eller anden variation af det samme, men når du kigger på den test, der bliver gennemført, så er det ikke noget, der gennemsyrer aktiviteten? Der er med andre ord ingen rød tråd fra det, der står i teststrategien, til den test, der er blevet specificeret og afviklet, og det endda selvom man kan se, der er blevet lavet en produktrisikoanalyse.

Produktrisikoanalyse har jeg allerede talt om i to tidligere artikler, du kan finde her:

Produktrisikoanalyse i en agil kontekst
Produktrisikoanalyse

Se desuden denne video, hvor jeg fortæller om risikobaseret teststrategi.

Men produktrisikoanalysen er jo kun første skridt på vejen, derefter skal der fastlægges en teststrategi der bedst muligt adresserer de risici der er identificeret, og sidst men ikke mindst så skal der designes og specificeres test der udlever teststrategien. De aktiviteter, der gennemføres i projektet omkring test og kvalitetssikring, skal alle støtte op om opgaven med at mitigere risici.

For at dette kan ske i praksis så er der et par punkter der skal være på plads:

1. Alle kender til resultatet af produktrisikoanalysen
2. Testplanlægning gennemføres på basis af PRA. Det betyder at den intensitet vi planlægger og designer test med, skal matche den risiko den addresserer
3. Valg af testdesignteknikker til testdesign sker på basis af teststrategien, altså på basis af den produktrisiko de skal mitigere
4. Prioriteringen af testafviklingen skal afspejle risikobilledet – højest risiko testes først

Punkt 1 har jeg allerede adresseret i tidligere artikler, så lad os springe videre til punkt 2.

Fra produktrisiko til teststrategi

Med gennemførelsen af produktrisikoanalysen har du grundlaget for din teststrategi i form af en tabel der ser ca. sådan her ud:

Du har med andre ord identificeret testmål, fundet ud hvilke kvalitetsattributter der er relevante for dem, og har vurderet dem ud fra konsekvens og sandsynlighed – og derfra udledt risikoklassen. Men at du har en række med ABC er jo ikke rigtig tilstrækkeligt ? så næste punkt er at komme fra disse til en egentlig strategi. Første punkt i den forbindelse er at identificere hvilke testniveauer (eller testaktiviteter hvis du er agil og ikke vild med det andet mere traditionelle begreb) der bør være i dit projekt. Unit test er givet (håber jeg) men udover det så kunne det f.eks. være systemtest, systemintegrationstest, brugeraccepttest osv. Altså testaktiviteter med hvert sit fokus. Uanset om du er i et traditionelt eller agilt projekt vil du jo have forskellige aktiviteter, og det kan jo også være din kontrakt siger noget som måske ligger udenfor det du synes er ”rigtig agilt” – f.eks. en formel brugeraccepttest, en overtagelsesprøve eller en driftstest, men også de forskellige testaktiviteter som du finder i de agile testkvadranter.

Du sætter hver af de identificerede aktiviteter op i tabellen, en pr kolonne – og gerne i ca. den rækkefølge du forventer at de gennemføres i (unittest, systemtest, accepttest f.eks.). og så kommer vi til det svære; nu skal du for hver kombination af testmål og kvalitetsattribut identificere hvordan du bedst muligt adresserer den. Hvor skal der være mest test (=højest intensitet)?

Det kan være svært at få hul på denne del, hvor er det smartest at lægge den høje testintensitet. Her er der et par gode tommelfingerregler at have med:

1. Adresser risici så tidligt som muligt.
2. Højeste intensitet og dermed testfokus bør ligge inden accepttest med slutbrugere, det er for sent at mitigere risici når du står med dem.

Arbejdet med at identificere den bedste måde at mitigere det risikobillede der blev identificeret i forbindelse med PRAen skal du naturligvis ikke sidde alene med. Et forslag kunne være at du laver et oplæg til hvordan du mener det skal adresseres, og så vender du det f.eks. med en arkitekt eller en lead udvikler. Dette for at få indspark i forhold til især den tekniske del af testen. Det kan jo godt være du gerne vil have højest intensitet på unit test niveau for at adresserer risici så tidligt som muligt, men hvad nu hvis det er en performance risiko der først for alvor kan adresseres som en del af systemtesten. Så det er en god ide at sparre med nogen med den dybe indsigt i hvad der er muligt tæt på koden.

Så langt så godt, nu har du en ide om hvornår hvad skal testes hvor meget ? men der mangler en væsentlig del; hvordan? Hvordan skal testeren/teamet oversætte de der prikker til en eller anden form for dækning eller tilgang til test?

Leo Van der Aalst beskriver i sin artikel ”Test design was not invented to bully the testers”  fordelen ved brug af testdesignteknikker, men har også en fin matrice baseret på TMap metoden der giver indsigt i hvilke teknikker der er bedst ved hvilken intensitet. Det handler om at få tilstrækkelig dækning, ikke for meget og ikke for lidt. Måden den benyttes er at du identificerer hvilken kvalitetskarakteristik du skal teste med hvilken intensitet, og kan så finde den celle i tabellen hvor forslag til teknikker er listet. F.eks. hvis du skal teste funktionalitet detaljeret med en intensitet på 2 ”**” så er oplægget at du bruger en af teknikkerne DCoT-pairwise testing (Data Combination Test), ECT-modified condition/decision coverage (Elementary Comparison Test) eller exploratory test (ET). For et indblik i disse teknikker kan du besøge tmap.net – hen ad vejen vil vi besøge en række af teknikkerne på vores blog og/eller videos, Annemette Clement er vores 100-meter mester udi disse ?

I den overordnede teststrategi skal testmanageren IKKE bestemme i detaljen hvilken teknik der skal bruges hvor, du giver et antal teknikker ud fra matricen, men der er ingen tvivl om hvem der i sidste ende beslutter hvilken teknik der benyttes – det gør den person der i detaljen kender til opgaven og derfor kan vurdere hvilken er den bedste, med andre ord testeren.

Nu kan jeg umiddelbart forestille mig mindst to indvendinger:

1. Mine testere kan ikke testteknikker så det giver ikke nogen værdi at lave produktrisikoanalysen
2. Vi er agile så vi laver ikke produktrisikoanalyse.

Med hensyn til den med testteknikkerne; En produktrisikoanalyse tegner et fælles billede af hvad det er for en testopgave vi står overfor, det er vigtigt uanset om testerne/teamet kan teknikker eller ej. Du kan stadig give dem en rettesnor for hvor meget test der skal specificeres og afvikles udfra en række tommelfingerregler som f.eks.;

Ovenstående er blot ment som et eksempel på hvordan du kan benytte output fra din produktrisikoanalyse til at give en række tommelfingerregler for hvad der skal testes, definer dem der passer til din kontekst.

Nu har testerne et grundlag for deres test specifikation, men de skal naturligvis i detaljen beslutte hvordan de bedst muligt adresserer de risici der er identificeret.

Når det så er sagt så kan jeg kun anbefale at i som team bruger lidt kræfter på at sætte jer ind i som minimum de mest basale testteknikker, jeg er sikker på at i vil finde værdi i dette ikke kun ud fra et testmæssigt perspektiv men også ud fra et behov for at forstår forretningens behov, finde strukturerede men ikke tungt dokumenterede metoder til at fastholde disse og ikke mindst til at visualisere hvad det er systemet skal kunne.

Med hensyn til punkt to, så vil jeg tillade mig at henvise til tidligere artikel samt video om hvordan man får produktrisikoanalysen integreret i den agile måde at arbejde på. Risikopoker kan sagtens køres videre i forhold til ovenstående beskrivelse af identifikation af teststrategi. I nedenstående har jeg simplificeret strategitabellen ud fra den device at man ikke taler om test niveauer i agile, men du kan selvfølgelig stadig bruge det lige som du har lyst til – der er ingen silver bullet, gør det der virker bedst i din kontekst.

En lille advarsel i forhold til nedenstående. I Tmap har man vist dette eksempel til den agile kontekst, men pas på ikke KUN at have fokus på userstories, tænk også på produktrisici i forhold til featuren og til systemet som helhed – de skal også adresseres.

Hvis vi genbesøger den løsning jeg beskrev i artiklen med udgangspunkt i PRISMA, så kan du også her finde en letvægtsmetode til at dokumentere teststrategien, du skal simpelthen ”bare” udvide din graf en lille smule.

Denne tilgang er meget visuel, især hvis du får den tegnet på flipover eller andet så den faktisk kan hænge på væggen i teamets område, er I ikke sammen må den selvfølgelig laves elektronisk men så fastholdt et sted hvor teamet kommer. (med andre ord ikke i word ?)

Når man går i gang med en ny feature så genbesøge produktrisikoanalysen og dermed teststrategien. Der kan være sket ændringer med scope, både at man har skåret i featuren men også den modsatte vej (scope creep), så det kan være nødvendigt at ændre/tilføje risici. Dermed kan der også være behov for at ændre i den relaterede teststrategi så vi har rette grundlag for det videre arbejde. Dette er et arbejde som testeren/teamet som udgangspunkt gør som en integreret del af testforberedelserne, det kræver ikke genkørsel af PRA eller større bureaukrati, bare at man tager stilling og agerer i forhold til det nye billede.

Nu har I en risikobaseret teststrategi, men husk nu punkt 4 fra tidligere ”Prioriteringen af testafviklingen skal afspejle risikobilledet – højest risiko testes først”; det er ikke nok at specificere den rette test, du skal også sikre, at I har det rette fokus, når I afvikler testen.

The post Risikobaseret teststrategi appeared first on Key2Quality.

Hvorfor skal vi lave en produktrisikoanalyse?

Hvis vi nu antog at vi havde al den tid og alle de ressourcer vi skulle bruge til at teste en applikation, så kunne vi jo ”bare” teste alt lige meget – og teste i bund (selv om man pr definition ikke kan teste ALT). Men det er vist ikke den verden ret mange af os befinder os i. Der er begrænsninger på de ressourcer vi har til rådighed, og der er begrænsninger på kalendertid. Derfor så er vi hele tiden nødt til at lave den gode prioritering; hvor skal vi lægge den største indsats, hvor kan vi teste mindre – og ikke mindst med hvilket fokus skal vi teste?

Vi skal altså definere og implementere den bedst mulige teststrategi indenfor de rammer vi er blevet givet. PRA’en er en helt essentiel brik i den forbindelse, som grundlag for at definere projektets eller teamets test strategi, og dermed fundamentet for at kunne definere og implementere en risikobaseret tilgang til test. Uden den kan vi reelt ikke vurdere hvor vi skal lægge indsatsen i testen, og hvad der skal have mest fokus.

Samtidig er PRAen med til at give et fælles billede i forhold til risici, det er ikke kun for test at den giver værdi. Den kommunikation vi har når vi gennemfører en PRA, uanset vores udviklingsmodel og metode for PRA, er essentiel for at skabe et fælles billede af hvad det er vi står overfor. Hvor skal vi have vores fokus.

Det kan nogle gange skabe lidt forvirring når vi taler om produkt risici, idet mange kun er vant til at fokusere på risici relateret til projektets succesfulde afvikling, altså projektrisici. Det er vigtigt at have et fælles billede af forskellen på de to.

Projektrisici er i forhold til projektets succesfulde afvikling, når vi i mål som planlagt, hvad hindrer os i det? F.eks. om testmiljøet bliver klar, om vi har de nødvendige kompetencer osv.

Omvendt så er Produktrisici i forhold til produktets kvalitet – det vi leverer til kunden. Hvad er kritisk for brugerne, hvad er svært at lave – vi kigger altså på det forventede slutprodukt

Men brugt rigtigt så er en produktrisikoanalyse et utroligt vigtigt værktøj at have i værktøjskassen, ikke kun som testmanager eller tester – men for hele teamet.

Hvornår laver man en PRA?

Det næste er så hvornår du skal lave en PRA, og det er kan reelt være både i starten af projektet, i starten af en release, i starten af sprint eller måske når i skal i gang med en ny feature – så den kan give værdi på mange forskellige tidspunkter med mange forskellige detaljeringsgrader.

• Når projektet starter (eller når det agile release train starter op … eller det agile team etablerer starten på en backlog) så er det lidt i helikopter perspektiv vi laver en PRA, vi kigger på den samlede opgave overordnet i forhold til den viden vi har (kravgrundlag, kontrakt etc)
• For en enkelt release, eller for et program inkrement eller et sprint går vi lidt mere i detaljen. Kigger på scopet i den kontekst, og her ved vi gerne lidt mere omkring detaljerne og kan bryde product risici ned og gøre dem mere konkrete.
• For en enkelt feature eller story. Nu er vi helt nede i materien – her er vi allermest konkrete. Vi har udelukkende fokus på scope for den givne feature/story og hvad den måtte påvirke, vi kan blive mere detaljerede og kan mappe det direkte mod den udviklings- og testopgave der følger efter.

Hvem skal med til en PRA?

Når du skal i gang med at facilitere en produktrisiko er det vigtigt at have forskellige interessenter med, det vil sige deltagere med forskellige perspektiver på den enkelte produktrisiko.

Dels selvfølgelig interessenter med forretningsperspektivet der har indsigt i den reelle brug af systemet så de kan vurdere hvad konsekvensen af en fejl i en givet del af systemet vil være forretningen. Men også interessenter fra IT der har indsigt i kompleksiteten af det system der skal udvikles, modenheden af den eksisterende arkitektur og selvfølgelig også kompetencer og erfaring i teamet.

Og så skal vi selvfølgelig ikke glemme testeren i denne forbindelse. Hun kan reelt have viden i forhold til ”begge sider” – en erfaren tester har som regel en del forretningsviden og vil kunne give indspark til brugen af systemet, men har også erfaringer fra test af systemet til at vurdere hvor det ofte går galt, hvor fejl potentielt plejer at hobe sig op.

Hvordan laver man en PRA?

Der er mange forskellige metoder til at lave PRA, for mig er det ikke så vigtigt hvilken du bruger – bare du gør det og tager den sammen med dit team. I det følgende giver jeg en introduktion til en af de metoder jeg selv har brugt rigtig meget gennem årene, jeg vil senere supplere med lidt inspiration til den agile kontekst.

Jeg har som regel lavet lidt hjemmearbejde og har f.eks. oplæg til en eller anden form for nedbrydning af opgaven, måske i features, i funktionelle områder eller lignende. Men denne nedbrydning er ikke hugget i sten, den kan til enhver tid tilpasses så den dækker det billede som deltagerne har f opgaven. Det er udelukkende ment som en hjælp til at få diskussionen i gang, det er så meget nemmere end baseret på et tomt whiteboard.

Listen diskuteres og tilrettes til man er enig om at dette er scope. Derefter skal vi i gang med næste del – at identificere hvilket perspektiv i forhold til de enkelte punkter som skal have fokus. Her mener jeg, er det f.eks. funktionalitet der er centralt i nedbrydningen – selve den funktionalitet der bliver stillet til rådighed? Eller kunne det være vigtigt hvordan performance er? Er der nogen utalte krav? Er der en bekymring i forhold til dette? Husk at de nonfunktionelle kvalitetsattributter ofte er de der bliver fokuseret mindst på, men som kan have en voldsom effekt hvis de fejler.

Så for hvert punkt på listen afklarer vi hvad der er i fokus. Jeg står ikke med hele listen fra ISO-standarden, der er rigtig mange og det giver ikke værdi. Ofte har jeg kigget lidt i kontrakter, krav, featurebeskrivelser, diskuteret lidt med arkitekten mv – og måske nået til en liste på 4-5 stykker. For det meste er funktionalitet, performance, sikkerhed og brugervenlighed givne. Dertil kan så komme andre i henhold til konteksten.

Nu har vi så en liste af ”testmål”, og for hvert af disse har vi en indikation af hvilke kvalitetsattributter der er vigtig. Så kommer vi til den sværeste del, vurderingen af hvor alvorlige disse er, hvad risikoklassen er for hver enkel kombination.

Her vælger jeg som regel at tage et fokus ad gangen. Først er det forretningen der primært har ordet, for vi starter med at kigge på konsekvens. Hvad er konsekvensen for forretningen hvis der identificeres en alvorlig performance fejl i feature X i produktion. Angiv High-medium eller low (eller er i mere til tal så bruger du selvfølgelig bare 3-2-1). Forretningen diskuterer og sætter ord på hvorfor de vælger f.eks. high. Vi arbejder os gennem alle testmål/kvalitetsattributter med forretningsfokus, et ad gangen. IT er som hovedregel stille i dette forløb, vi forventer at det er forretningen der har denne indsigt, men der kan selvfølgelig stilles afklarende spørgsmål ligesom at har man en viden om f.eks. en work around som den pågældende forretningsrepræsentant ikke har, så skal man selvfølgelig flage det.

Når vi er igennem listen, skal IT på banen, og nu er det forretningen der sidder stille ? Nu skal vi nemlig diskutere sandsynligheden for at risicien indtræffer. Er det en meget kompleks kode? Er vi inde og skal tilføje noget til et eksisterende modul som tidligere har givet mange problemer? Er det en helt ny platform? Er det piece of cake fordi vi har lavet noget lignende i forrige release som bare skal tilpasses? Igen diskuteres og afklares.

Facilitatoren har en meget vigtig rolle her! Nogle gange oplever man at ALT er High, så er det vigtigt at vi tager diskussionen ”jamen er det her punkt lige så ”High” som det tidligere? Prøve at få nuanceret klassificeringen.

Efterhånden som i når ned gennem listen så har du altså to punkter for hver risici – en konsekvens og en sandsynlighed. For at udlede risikoklassen som er det vi skal bruge til det efterfølgende arbejde med teststrategien har du to muligheder, alt efter om du valgte High/medium/low eller 3/2/1.

Med det første har du en matrice du kan bruge til at udlede risikoklassen. Nedenstående er en standardmatrice defineret på basis af erfaringer på tværs af brancher, men hvis du f.eks. har en kontekst der kræver højere sikkerhed (life-science, space osv.) så tilretter du naturligvis bare matricen til den kontekst gennem at hæve risikoklasserne så f.eks. også medium konsekvens/sandsynlighed er A og der måske slet ikke er nogen C – den diskussion skal du tage med din forretning.

Hvis du bruger tal i stedet for High-medium-low (3-2-1) så kan det gøres hurtigt ved at gange de to tal med hinanden.

Når man er nået gennem listen på denne måde, har man et billede af risikoprofilen på sit scope – alle punkter har nu en risikoklasse tilknyttet.

Her er det ofte værd at bruge lidt tid på at kigge det igennem i sin helhed, når deltagerne ser risikoklasserne i forhold til hinanden, kan det godt give lidt anledning til yderligere diskussion, og måske også en re-klassificering.

Dette er produktrisikoanalysen. Med basis i den kan vi nu gå i gang med at udlede den bedst mulige teststrategi. Det vil sige hvilken intensitet af test skal gennemføres ved hvilke testaktiviteter. Og når du er nået så langt, så har du givet teamet og testerne et stærkt værktøj i hånden, for den testintensitet giver nemlig dem et vigtigt indspark i forhold til hvilken testteknik de skal bruge, hvordan de bedst muligt skal mitigere risikoen.

The post Produktrisikoanalyse appeared first on Key2Quality.

Ofte når jeg besøger virksomheder bliver ordet brugt i flæng, men jeg kan ikke lade være med at tænke på om vi overhovedet mener det samme? En ting er selvfølgelig om vi taler om kvalitet i processen eller kvalitet i produktet, men også bare helt banalt; hvad betyder ordet kvalitet. Et par eksempler:

Den store Danske Ordbog: Grad af gode egenskaber som noget besidder, fx afhængigt af materialevalg, udførelse, avls- eller dyrkningsmetoder eller talent

Dictonary.com: An essential or distinctive characteristic, property, or attribute

Personligt kan jeg godt lide den som Jerry Weinberg oprindeligt defineret og som senere er blevet beriget af både Michael Bolton og James Bach:

Quality Is Value To Some Person, At Some Time, Who Matters

Og hvorfor er denne diskussion og definition vigtig? jo vi måler til højre og venstre ude i projekter og teams, der defineres metrikker og KPI’er for snart sagt alt under paraplyen af “kvalitet”, men måske det var smart at starte med at finde ud af hvad vi mener kvalitet er før vi sætter mål for hvor vi skal hen og hvordan vi måler om vi kommer dertil?

Måske skulle vi starte med målet inden vi begyndte at finde på alle mulige og umulige metrikker som der skal samles data op til?

Når vi er så langt at vi har den grundlæggende definition på plads, så var det måske værd at besøge Gavin’s 8 dimensioner på kvalitet – hvad er relevant for dit projekt eller produkt?

Og at komme fra fluffy definitioner på kvalitet til mål og metrikker – se det er en helt anden snak som jeg lige vender tilbage med indenfor den nærmest fremtid.

The post Nu siger du nok kvalitet … appeared first on Key2Quality.