Bygga snabbt, testa noga

Från behov till krav

I kapitel 4 skrev du kriterier innan du byggde. I teknikämnet hör det till teknikutvecklingsarbetet, som brukar delas in i faser: ta reda på behovet, undersök, föreslå lösningar, konstruera och pröva. Med AI går konstruktionen på någon minut. De andra faserna kräver fortfarande att du tänker och testar, och de avgör om resultatet håller.

Allt börjar med ett behov. Klass 9B ska sälja kakor på skolans vårmarknad. Förra året blev 40 bitar kladdkaka över, och kanelbullarna tog slut på en kvart. Behovet är alltså inte en snygg sida, utan att veta i förväg vad folk vill köpa. Klassen vill ha en sida där man beställer i förväg.

Ett krav är något som lösningen måste klara. Ett önskemål är bra om det finns med, men lösningen fungerar utan det. Ett bra krav går att testa: ”Sidan ska vara lätt att använda” går inte att pröva, men ”fyra av fem testare ska kunna beställa på under två minuter utan hjälp” gör det. Kraven samlas i en kravspecifikation.

Tre av kraven skyddar människor. K3 gäller säkerhet, eftersom en allergi kan vara farlig. K4 gäller personuppgifter: det som aldrig samlas in kan inte läcka, som Ett meddelande, många kopior visar. K5 gäller tillgänglighet. Sedan 28 juni 2025 kräver en lag att bland annat e-handel och banktjänster ska vara tillgängliga för personer med funktionsnedsättning.[2] Tillgänglighet hör alltså till kraven, inte till önskemålen.

Kravspecifikationen kan bli en del av prompten. Men om AI-verktyget svarar att alla krav är uppfyllda är det ett påstående, inte ett test.

När testet sa nej

Att något fungerar betyder inte att det håller. Tre kända fel visar hur det kan gå.

Provet visade felet, men det ledde inte till något beslut. Lärdom: bestäm i förväg vad som händer om testet säger nej.

Den 4 juni 1996 sköts den europeiska raketen Ariane 5 upp för första gången. Efter omkring 40 sekunder bröts den sönder och exploderade. Programmet i det system som mätte raketens läge och fart hade återanvänts från den mindre Ariane 4, där det hade fungerat. Men Ariane 5 fick högre fart i sidled, ett tal blev större än programmet hade plats för, och programmet stannade. Reservsystemet stannade av samma skäl. Den del av programmet där felet uppstod behövdes dessutom bara före starten. Enligt utredningen hade systemet inte analyserats och testats tillräckligt.[6] Lärdom: kod som har fungerat någon annanstans är inte testad här.

I september 1999 gick NASA:s rymdsond Mars Climate Orbiter förlorad vid Mars. Ett program på jorden räknade ut hur styrraketerna påverkade kursen, i amerikanska enheter i stället för de metriska som specifikationen krävde. Programmet som tog emot talen räknade med metriska enheter, så i beräkningarna blev effekten ungefär 4,45 gånger för liten, och sonden hamnade på fel bana. Utredningen pekade också på att navigeringsprogrammen inte hade prövats fullständigt från början till slut.[7] Lärdom: testa hela kedjan, inte bara delarna.

När AI skriver koden

Alla tre felen går att göra med AI-verktyg också, bara fortare. Lovable i Stockholm säljer en tjänst för vibe coding. Du beskriver en app, och tjänsten bygger den, ofta med en databas där användarnas uppgifter sparas. Databasen behöver regler för vem som har behörighet att läsa och ändra vad. I de 170 apparna saknades sådana regler eller var för svaga, så vem som helst kunde läsa och ibland ändra uppgifterna. Den som gjorde granskningen arbetade på konkurrenten Replit och hade berättat om felet för Lovable flera månader tidigare.[1]

Lovable svarade att företaget ännu inte var där det ville vara med säkerheten och skulle fortsätta att förbättra den.[8] Företaget menade också att varje kund ansvarar för att skydda uppgifterna i sin app.[9] I dag granskar Lovable automatiskt bland annat databasens regler när en app ska publiceras, men enligt Lovables egna råd ska den som bygger appen ändå kontrollera reglerna själv.[10]

Blir man då snabbare? I juli 2025 publicerade forskningsorganisationen METR ett experiment med 16 erfarna programmerare och 246 uppgifter i stora program som de själva arbetade med. För varje uppgift lottades det om AI-verktyg var tillåtna. Med AI tog uppgifterna 19 procent längre tid. Före experimentet trodde programmerarna att AI skulle göra dem 24 procent snabbare, och efteråt trodde de att det hade gått 20 procent snabbare.[13] I februari 2026 skrev METR att programmerare troligen får mer hjälp av verktygen nu, men att ett nytt experiment inte kunde visa hur mycket, bland annat eftersom många inte längre ville arbeta utan AI.[14] Känslan av fart är alltså inget mått.

Säkerhetsföretaget Veracode lät år 2025 mer än 100 AI-modeller skriva kod för 80 uppgifter, där koden kunde bli säker eller osäker. I 45 procent av fallen fick koden en känd sorts säkerhetsfel.[15] I rapporten från juli 2026 följde nästan all kod programspråkets regler, men i genomsnitt klarade bara 56 procent av lösningarna säkerhetstesterna, ungefär som året innan. Modellerna fick inga instruktioner om säkerhet, och ingen människa granskade koden. Veracode säljer själv verktyg för att testa kod.[16]

Fallen visar inte att AI-verktyg är dåliga, utan var människans arbete ligger: att bestämma vad något ska klara, att testa det och att ta ansvar när något går fel.

Testa på riktigt

Kapitlets tre frågor motsvarar tre sorters test:

• Funktionstest: Fungerar det? Går knapparna att trycka på, räknas summan, kraschar något?
• Kravtest: Gör det det jag ville? Du prövar kravspecifikationen, ett krav i taget, och skriver godkänt eller underkänt.
• Användartest: Hur upplevs det? Någon som inte har byggt sidan försöker använda den utan hjälp, medan du tittar och tiger.

Fel gömmer sig ofta i kanterna. Om kravet är 1–10 kakor räcker det inte att beställa 3. Testa 1 och 10, men också 0, 11, −1, 2,5 och ordet ”tre”. Sådana värden kallas gränsfall. Skriv testerna i ett testprotokoll, gärna innan du testar, så att du vet vad som borde hända.

Den som har byggt något testar det hen tänkte på. Andra hittar det hen inte tänkte på. Därför betalar stora företag för felrapporter. Under 2025 betalade Google ut mer än 17 miljoner dollar till över 700 personer som hade hittat säkerhetsfel i företagets tjänster, och sedan 2025 finns ett eget program för fel i Googles AI-tjänster.[17] Men det gäller bara det som ägaren har bjudit in till. Att pröva andras system utan lov kan vara brottet dataintrång.[18] I klassrummet knäcker ni bara varandras prototyper, med lov.

Ett AI-verktyg kan föreslå testfall, till exempel med Vad kan gå fel? i kapitlets promptbyggare. Själva testet gör du, med riktiga människor.

Dokumentera och ta ansvar

När ett test har visat ett fel ändrar du en sak, sparar en ny version och testar igen. Varje version får en rad i en ändringslogg:

• 0.1. Första versionen, byggd med AI-verktyget.
• 0.2. Antal kan bara vara heltal 1–10, efter testfall 2 och 3. Nytt test: godkänt.
• 0.3. Knappen Beställ går att nå med tangentbordet. Nytt test: godkänt.

Med sparade versioner kan du gå tillbaka om en ändring gör saken sämre, och andra ser vad som har ändrats och varför.

Lägg aldrig ut kod som du inte kan förklara. Du behöver inte ha skrivit den, men du ska kunna säga vad varje del gör, vilka uppgifter den sparar och vart de skickas. Använd Förklara koden från kapitlet, och pröva förklaringen: om verktyget skriver att en rad stoppar negativa tal, skriv −2 och se vad som händer.

I en teknisk rapport redovisar du också arbetsfördelningen: vilket verktyg du använde, vilka instruktioner du gav, vilka delar verktyget skrev, vad du ändrade och vilka beslut du fattade. Det är svaret i gruppchatten från kapitlet, fast mer exakt.

Slutuppgift: bygg och testa, eller granska

Välj en av två former, om inte läraren bestämmer.

A. Bygg och testa en egen prototyp för ett verkligt behov i skolan, hemma eller på fritiden. Arbetet ska innehålla:

1. Behovet: vem har problemet, och vad fungerar inte i dag?
2. En kravspecifikation med minst fem krav och två önskemål. Minst ett krav ska gälla säkerhet eller personuppgifter och ett tillgänglighet, och alla krav ska gå att testa.
3. En prototyp, byggd med ett AI-verktyg som skolan har godkänt, med ett annat verktyg eller på papper. Den får inte samla in personuppgifter: inga inloggningar, inga namn, ingen kamera och ingen mikrofon.
4. Ett testprotokoll med gränsfall och minst två testare som inte har byggt prototypen.
5. En ändring som bygger på testet, och ett nytt test som visar vad ändringen gjorde.
6. Arbetsfördelningen: vad AI-verktyget gjorde, vad du gjorde och vilka beslut du fattade.

B. Granska en färdig prototyp som läraren ger dig, till exempel en enkel webbsida som ett AI-verktyg har byggt. Beskriv vilket behov den verkar lösa, skriv en kravspecifikation och testfall med gränsfall och testa. Skriv sedan vilka fel du hittade, hur allvarliga de är och vad du föreslår.

Redovisa på ett av två sätt. Läraren säger vilket.

• En teknisk rapport på 1–2 sidor med kravspecifikationen och testprotokollet.
• En presentation på 4–5 minuter, där du visar prototypen och de viktigaste testerna.