<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Tina Daa Løfquist Archives - Key2Quality</title>
	<atom:link href="https://key2quality.dk/forfatter/tina-daa-loefquist/feed/" rel="self" type="application/rss+xml" />
	<link>https://key2quality.dk/forfatter/tina-daa-loefquist/</link>
	<description>IT-kvalitet gennem ledelse, kvalitets­sikring og uddannelse</description>
	<lastBuildDate>Tue, 01 Apr 2025 07:01:39 +0000</lastBuildDate>
	<language>da-DK</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	

<image>
	<url>https://key2quality.dk/wp-content/uploads/2024/02/k2q_logo-150x150.png</url>
	<title>Tina Daa Løfquist Archives - Key2Quality</title>
	<link>https://key2quality.dk/forfatter/tina-daa-loefquist/</link>
	<width>32</width>
	<height>32</height>
</image> 
	<item>
		<title>Hvorfor skal udviklere lære mere om test?</title>
		<link>https://key2quality.dk/hvorfor-skal-udviklere-laere-mere-om-test/</link>
		
		<dc:creator><![CDATA[Trine Zachariassen]]></dc:creator>
		<pubDate>Mon, 31 Mar 2025 06:14:48 +0000</pubDate>
				<category><![CDATA[e-learning]]></category>
		<category><![CDATA[forsiden]]></category>
		<category><![CDATA[Key2Learn]]></category>
		<category><![CDATA[Nyheder]]></category>
		<category><![CDATA[Test]]></category>
		<category><![CDATA[Testautomatisering]]></category>
		<category><![CDATA[Udvikling]]></category>
		<category><![CDATA[Vidensdeling]]></category>
		<category><![CDATA[Tina Daa Løfquist]]></category>
		<guid isPermaLink="false">https://key2quality.dk/?p=8674</guid>

					<description><![CDATA[<p>At skrive god kode er én ting – at sikre, at den også fungerer stabilt i praksis, er en anden. Fejl, der først opdages sent i udviklingsprocessen, kan føre til forsinkelser, teknisk gæld og frustrerede brugere. Når test bliver en naturlig del af udviklingsprocessen, skaber det en række fordele: Mindre tid brugt på fejlrettelse – [&#8230;]</p>
<p>The post <a href="https://key2quality.dk/hvorfor-skal-udviklere-laere-mere-om-test/">Hvorfor skal udviklere lære mere om test?</a> appeared first on <a href="https://key2quality.dk">Key2Quality</a>.</p>
]]></description>
										<content:encoded><![CDATA[		<div data-elementor-type="wp-post" data-elementor-id="8674" class="elementor elementor-8674" data-elementor-post-type="post">
				<div class="elementor-element elementor-element-4f3eb043 e-flex e-con-boxed e-con e-parent" data-id="4f3eb043" data-element_type="container">
					<div class="e-con-inner">
				<div class="elementor-element elementor-element-542b9908 elementor-widget elementor-widget-text-editor" data-id="542b9908" data-element_type="widget" data-widget_type="text-editor.default">
				<div class="elementor-widget-container">
			<style>/*! elementor - v3.22.0 - 26-06-2024 */
.elementor-widget-text-editor.elementor-drop-cap-view-stacked .elementor-drop-cap{background-color:#69727d;color:#fff}.elementor-widget-text-editor.elementor-drop-cap-view-framed .elementor-drop-cap{color:#69727d;border:3px solid;background-color:transparent}.elementor-widget-text-editor:not(.elementor-drop-cap-view-default) .elementor-drop-cap{margin-top:8px}.elementor-widget-text-editor:not(.elementor-drop-cap-view-default) .elementor-drop-cap-letter{width:1em;height:1em}.elementor-widget-text-editor .elementor-drop-cap{float:left;text-align:center;line-height:1;font-size:50px}.elementor-widget-text-editor .elementor-drop-cap-letter{display:inline-block}</style>				<p><span class="NormalTextRun SCXW72299271 BCX0">At skrive god kode er én ting – at sikre, at den også fungerer stabilt i </span><span class="NormalTextRun SCXW72299271 BCX0">praksis,</span><span class="NormalTextRun SCXW72299271 BCX0"> er en anden. Fejl, der først opdages sent i udviklingsprocessen, kan føre til forsinkelser, teknisk gæld og frustrerede brugere.</span></p><p>Når test bliver en naturlig del af udviklingsprocessen, skaber det en række fordele:</p><ul><li><strong>Mindre tid brugt på fejlrettelse</strong> – Jo tidligere en fejl findes, desto billigere er den at rette. Tidligt identificerede fejl reducerer spildtid på debugging og rework.</li><li><strong>Bedre kodekvalitet</strong> – Test-drevet udvikling (TDD) skaber mere robust og lettere vedligeholdbar kode. En testvenlig kodebase understøtter modularitet og genbrug af komponenter.</li><li><strong>Mere effektive CI/CD-pipelines</strong> – Automatiserede tests sikrer hurtigere og mere stabile releases ved at fange fejl tidligt og reducere behovet for manuelle regressionstests.</li><li><strong>Mere pålidelige leverancer</strong> – Ved at integrere test tidligt og kontinuerligt kan teams levere funktionalitet med færre uforudsete fejl, hvilket øger forudsigeligheden i releases.</li><li><strong>Øget agilitet</strong> – Testkompetencer hos udviklere gør det lettere at arbejde iterativt og hurtigt reagere på ændringer i krav eller arkitektur.</li></ul><h3>Test-drevet udvikling (TDD)</h3><p>Mange udviklere kender til <strong>testdrevet udvikling (TDD)</strong> i teorien, men har aldrig rigtig prøvet det af i praksis. Ofte oplever teams, at test skrives efter implementeringen – eller i værste fald udelades helt. Dette kan føre til flere bugs, sværere vedligeholdelse og en kodebase, hvor testdækningen bliver et efterslæb frem for en integreret del af udviklingen.</p><p>Når TDD bruges korrekt, fungerer det som en kvalitetssikring i realtid, hvor<strong> tests definerer funktionalitet før koden skrives</strong>. Dette skaber en mere gennemtænkt arkitektur, reducerer teknisk gæld og sikrer, at udviklere kun skriver den nødvendige kode for at bestå testen – hverken mere eller mindre.</p><h3>Shift-left test – lær at tænke test tidligt</h3><p>En klassisk udfordring i softwareudvikling er, at test først implementeres i slutningen af udviklingsprocessen. Dette betyder ofte, at fejl først opdages, når store dele af koden allerede er skrevet – hvilket gør fejlrettelse dyrere og mere tidskrævende.</p><p>I et traditionelt &#8220;test-last&#8221; setup kan udviklere bruge dage eller uger på at bygge funktionalitet, der først testes, når featuren er næsten færdig. Hvis der opstår problemer, skal koden omskrives eller tilpasses, hvilket ofte fører til rework, teknisk gæld og forsinkede leverancer.</p><p><strong>Ved at teste tidligere i forløbet kan teams:</strong></p><ul><li>Identificere fejl allerede i design- og udviklingsfasen.</li><li>Skrive testcases parallelt med kravspecificering, hvilket sikrer bedre forståelse af kravene.</li><li>Undgå store omskrivninger senere, da fejl kan rettes løbende i små iterationer.</li></ul><p>Når shift-left test bliver en naturlig del af udviklingskulturen, får teams mere stabile leverancer, reducerer teknisk gæld og minimerer tidsspild på senere rettelser.</p><h3>Automatiseret test i CI/CD – gør det til en del af udviklerens workflow</h3><p>CI/CD er effektivt, men kun hvis de rigtige tests kører automatisk ved hver kodeændring. Uden velintegreret testautomatisering risikerer teams at bruge tid på manuelle tests eller overse kritiske fejl, hvilket kan føre til ustabil kode og langsommere releases.</p><p>Ved at gøre test til en naturlig del af udviklingsprocessen skabes en mere pålidelig og effektiv CI/CD-pipeline, hvor fejl fanges tidligt, og udviklerne kan arbejde mere effektivt.</p><h3>Bedre fejlsøgning og fejlhåndtering – lær af tidligere fejl</h3><p>Mange fejl gentager sig, fordi udviklingsteams ikke dokumenterer eller lærer af tidligere problemer. Uden en systematisk tilgang til fejlanalyse risikerer teams at spilde tid på at løse de samme bugs igen og igen.</p><p>Ved at integrere systematisk fejlanalyse i udviklingsprocessen kan teams forhindre, at de samme fejl opstår igen og igen. Dette skaber en mere effektiv fejlhåndtering, højere kodekvalitet og bedre produktivitet i udviklingsarbejdet. Når teams lærer af tidligere fejl, bliver softwareudviklingen mere forudsigelig, mindre stressende og mere fokuseret på innovation frem for brandslukning.</p><h3>E-learning som løftestang for bedre test i udviklingsteams</h3><p>Med vores e-learning platform, Key2Learn, kan du løfte testkompetencerne i dit udviklingsteam. <a href="https://key2quality.dk/key2learn/">Læs mere om Key2Learn her</a>, eller kontakt chefrådgiver og områdeleder for kompetencer og viden, <a href="https://key2quality.dk/vores-team/gitte-ottosen/">Gitte Ottosen</a> på <a href="mailto:gitte@key2quality.dk">gitte@key2quality.dk</a> eller 4940 8552 for at høre mere.</p>						</div>
				</div>
					</div>
				</div>
				</div>
		<p>The post <a href="https://key2quality.dk/hvorfor-skal-udviklere-laere-mere-om-test/">Hvorfor skal udviklere lære mere om test?</a> appeared first on <a href="https://key2quality.dk">Key2Quality</a>.</p>
]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>Online facilitering af system- og accepttest</title>
		<link>https://key2quality.dk/online-facilitering-af-system-og-accepttest/</link>
		
		<dc:creator><![CDATA[ah]]></dc:creator>
		<pubDate>Wed, 27 Oct 2021 12:54:40 +0000</pubDate>
				<category><![CDATA[Online facilitering]]></category>
		<category><![CDATA[System- og accepttest]]></category>
		<category><![CDATA[Vidensdeling]]></category>
		<category><![CDATA[Tina Daa Løfquist]]></category>
		<guid isPermaLink="false">https://key2quality.dk/?p=5546</guid>

					<description><![CDATA[<p>Hvordan faciliterer du som test manager bedst muligt system- og accepttest med distribuerede teams i forskellige tidszoner? Og med flere testtyper parallelt inden for samme tidszone? I denne artikel deler jeg mine erfaringer med online facilitering af system- og accepttest i de to forskellige setups. Som test manager faciliterer jeg forskellige testaktiviteter, hvor det ofte [&#8230;]</p>
<p>The post <a href="https://key2quality.dk/online-facilitering-af-system-og-accepttest/">Online facilitering af system- og accepttest</a> appeared first on <a href="https://key2quality.dk">Key2Quality</a>.</p>
]]></description>
										<content:encoded><![CDATA[<p><strong><em>Hvordan faciliterer du som test manager bedst muligt system- og accepttest med distribuerede teams i forskellige tidszoner? Og med flere testtyper parallelt inden for samme tidszone? I denne artikel deler jeg mine erfaringer med online facilitering af system- og accepttest i de to forskellige setups.</em></strong></p>
<p>Som test manager faciliterer jeg forskellige testaktiviteter, hvor det ofte er umuligt at sidde på samme lokation – enten fordi involverede teams er distribuerede eller – som tilfældet det sidste halvandet år – at COVID-19 har gjort det umuligt.</p>
<p>Jeg har erfaring med to setups, der har fungeret for mig: Det ene setup var med distribuerede teams i forskellige tidszoner, og det andet var med flere parallelle testtyper inden for samme tidszone.</p>
<p>Rammerne for online facilitering er i begge tilfælde et ”hovedmøde”, som fungerer som en slags reception, og tilhørende ”undermøder” hvor den planlagte test foregår. På hovedmødet er der i løbet af dagen en række checkpoints, som sikrer kontinuerlig kommunikation om testen og adresserer løsninger på udfordringer i fællesskab. Hovedmøderne varer 15 minutter, hvorefter testerne går tilbage til deres specifikke undermøde og fortsætter testen.</p>
<p>Inden testen udarbejdes ”guidelines med gode råd til deltagelse i online-møder” for at sikre den rette ånd og et fælles afsæt. Også artefakter såsom oversigter over mødelinks, vagtordning, kontaktoplysninger og diverse how-to’s er nyttige.</p>
<h2>Distribuerede teams i forskellige tidszoner</h2>
<p>Her er tre tidszoner involveret, og der er seks timer til rådighed pr. dag til fælles test – øvrig tid foregår lokalt.</p>
<p>I Indien startede testen flere timer før Norge og Rusland – ligeledes fortsatte testen i Norge og Rusland senere end i Indien. Men det tidsrum, hvor alle parter arbejdede på samme tid, blev udnyttet.</p>
<p>Testen blev understøttet af Microsoft Teams, hvor hovedmødet var et Teams-møde, og de tilhørende undermøder foregik i Teams-kanaler. Checkpoints foregik på Teams-mødet og selve testen i relevante Teams-kanaler. Testerne havde mulighed for at returnere til hovedmødet og bede om den hjælp, der var brug for – ligeledes kunne de fra hovedmødet sende hjælpen i den retning, hvor behovet var.</p>
<p>I starten var der en del modstand mod de tre daglige checkpoints, som blev set som et overhead, men der gik ikke længe, før værdien blev tydelig; der var stort set altid emner at tage en kort snak om, og vi var alle løbende informeret og tog fælles ansvar for testen. Kunden deltog også og kunne bidrage konstruktivt med forretningsindsigt. Kunden valgte at gennemføre deres accepttest på samme måde – her deltog vi som leverandør og kunne også bidrage smidigt uden efterfølgende afklaringsmøder.</p>
<div><img fetchpriority="high" decoding="async" class="alignnone size-full wp-image-5547" src="https://key2quality.dk/wp-content/uploads/2024/04/Billede1.png" alt="" width="643" height="355" srcset="https://key2quality.dk/wp-content/uploads/2024/04/Billede1.png 643w, https://key2quality.dk/wp-content/uploads/2024/04/Billede1-300x166.png 300w" sizes="(max-width: 643px) 100vw, 643px" /></div>
<h2>Flere testtyper parallelt – samme tidszone</h2>
<p>I den anden case var der 13 parallelle testtyper involveret, alle med hvert sit fokus. En del testtyper havde afhængigheder til fysisk udstyr, eksterne tredjeparter og specifikke faggrupper – der var omkring 200 interessenter på tværs af alle testtyper. Og så var der selvfølgelig corona, der tilførte yderligere kompleksitet til testgennemførelsen. Testforløbet varede i 5,5 måned, og på trods af omstændighederne færdiggjorde vi testen indenfor tidsrammen og gik live planmæssigt.</p>
<p>Jeg brugte samme setup som ved de distribuerede teams, blot i en lidt større skala. Testen blev understøttet af Webex, hvor hovedmødet var et ”gruppemøde”, og ”undergrupper” fungerede som undermøder.</p>
<p>Der var et hovedmøde for den overordnede testledelse, og her blev alt defect management håndteret. Mødet var bemandet hele dagen, og formålet var at have et forum, hvor testerne hurtigt kunne henvende sig, når de havde behov for assistance fra ledelsen. Whiteboard-funktionalitet blev brugt til forskellig information fra programmet og relevante metrikker.</p>
<div><img decoding="async" class="alignnone size-full wp-image-5548" src="https://key2quality.dk/wp-content/uploads/2024/04/Billede2.png" alt="" width="643" height="277" srcset="https://key2quality.dk/wp-content/uploads/2024/04/Billede2.png 643w, https://key2quality.dk/wp-content/uploads/2024/04/Billede2-300x129.png 300w" sizes="(max-width: 643px) 100vw, 643px" /></div>
<div>Hver testtype havde ligeledes sit eget hovedmøde, hvor test manageren og testkoordinatorerne skiftedes til at passe ’receptionen’ og havde styr på, hvilke test der foregik i de relaterede undergrupper. I løbet af dagen var der tre checkpoints, der fulgte op på testen. Whiteboard-funktionalitet blev flittigt brugt til at fejre mærkedage og andet godt.</div>
<div><img decoding="async" class="alignnone size-full wp-image-5549" src="https://key2quality.dk/wp-content/uploads/2024/04/Billede3.png" alt="" width="643" height="396" srcset="https://key2quality.dk/wp-content/uploads/2024/04/Billede3.png 643w, https://key2quality.dk/wp-content/uploads/2024/04/Billede3-300x185.png 300w" sizes="(max-width: 643px) 100vw, 643px" /></div>
<p>Den praktiske deltagelse foregik ved at gå frem og tilbage mellem hovedmødet og undergrupperne.</p>
<p>Som program-testmanager kunne jeg let følge med i de parallelle aktiviteter ved på skift at deltage i disse checkpoints. Jeg havde også mulighed for at deltage i enkelte testsessioner i en undergruppe.</p>
<div><img loading="lazy" decoding="async" class="alignnone size-full wp-image-5550" src="https://key2quality.dk/wp-content/uploads/2024/04/Billede4.png" alt="" width="643" height="249" srcset="https://key2quality.dk/wp-content/uploads/2024/04/Billede4.png 643w, https://key2quality.dk/wp-content/uploads/2024/04/Billede4-300x116.png 300w" sizes="(max-width: 643px) 100vw, 643px" /></div>
<h2>Lessons learned</h2>
<p>Som afslutning på testen afholdt vi et retrospective på blandt andet de fordele og ulemper, der var ved at gennemføre alt online. Blandt deltagerne var test managers, testkoordinatorer og programledelse.</p>
<p>Nedenstående opsummerer de kommentarer, der var fra parterne. Der var en masse gode refleksioner – både over, hvad der fungerede godt, og hvad der fungerede dårligt.</p>
<p>Der var klart nogle uhensigtsmæssigheder, såsom at det var udfordrende at opfange signaler ved stress og konflikter. Der manglede den der ’i døren snak’, og det var sværere at skabe relationer. Men der var også fordele, som at det faktisk var nemmere og hurtigt at få hjælp, struktur med checkpoints og sparet tid på transport.</p>
<p>Fælles var erkendelsen af, at online møder er kommet for at blive men også at de kræver, at folk kender hinanden i forvejen.</p>
<div><img loading="lazy" decoding="async" class="alignnone size-full wp-image-5551" src="https://key2quality.dk/wp-content/uploads/2024/04/Billede5.png" alt="" width="643" height="367" srcset="https://key2quality.dk/wp-content/uploads/2024/04/Billede5.png 643w, https://key2quality.dk/wp-content/uploads/2024/04/Billede5-300x171.png 300w" sizes="(max-width: 643px) 100vw, 643px" /></div>
<h2>Mine refleksioner</h2>
<p>Det lykkedes ikke konsekvent at overholde guidelines ved deltagelse i online møder – for eksempel havde en del af mødedeltagerne det svært med kameraet – forståeligt nok, da vi jo trådte direkte ind i hinandens privatsfære. Uden kameraet er det bare endnu sværere at mærke små signaler og at kunne reagere på dem.</p>
<p>Ofte er energien dér, hvor folk er fysisk sammen. Især tests, der krævede specielt udstyr, havde en fordel i dette setup – alle havde samme forudsætninger, og energien var lige præcis dér, hvor behovet var. Efterhånden som testerne blev rutinerede i at være online, fik de en helt særlig måde at overdrage teststeps til hinanden, og de var meget tålmodige overfor hinanden og delte villigt skærm, så alle kunne følge med.</p>
<p>Generelt var det en succes med setup’et. Alle havde nemt ved at finde ud af det og hoppede uproblematisk mellem hovedmødet og undermøderne. Vi havde arbejdet og testet setup’et grundigt inden testafvikling og fik på den måde gode ambassadører til at videreformidle ideen. Kun få gange var vi udfordret på manglende netværksforbindelse, og det var ikke noget, der påvirkede testforløbet markant. Personligt havde jeg en mikrofon til at stå på skrivebordet. Det kan anbefales for at skåne ørerne – det er hårdt med headset hele dagen.</p>
<p>Jeg forestiller mig ikke, at den næste test, jeg skal facilitere, vil være <em>enten</em> online <em>eller</em> fysisk – men derimod en kombination – måske med de tre checkpoints online suppleret med fysisk test, i tilfælde af at alle testere kan være fysisk sammen, og online, hvis ikke alle kan være til stede.</p>
<p>The post <a href="https://key2quality.dk/online-facilitering-af-system-og-accepttest/">Online facilitering af system- og accepttest</a> appeared first on <a href="https://key2quality.dk">Key2Quality</a>.</p>
]]></content:encoded>
					
		
		
			</item>
	</channel>
</rss>
