Så testar du din AI-byggda app när du aldrig testat programvara förut

Du byggde en app med AI. Den fungerar på den lyckade vägen – du skriver in ditt namn, klickar på knappen, ser bekräftelseskärmen. Vad nu? Är den redo att skicka till dina tre betatestare? Ditt team? Dina kunder?

Om du saknar programvarubakgrund känns testning som en av de där sakerna “riktiga utvecklare” gör – med ramverk och assertioner och CI-pipelines. Den goda nyheten: det är inte vad det mesta av testning faktiskt är. Det mesta av testning, särskilt när du skeppar något litet och nytt, är en person som klickar runt med avsikt. Det kan du göra. Det här inlägget handlar om att göra det medvetet, så att du hittar buggarna innan dina användare gör det.

Målet är inte att testa din AI-byggda app som ett proffs. Det är att testa den som en paranoid vän som genuint vill att den ska fungera.

Tvålistorstricket

Innan du klickar på något, sätt dig ner i tio minuter med ett tomt dokument och skriv två listor.

Lista A – de lyckade vägarna. Vilka är de tre eller fyra saker en användare är tänkt att göra med den här appen? För en typisk SaaS kan det vara: registrera sig, skapa sitt första projekt, bjuda in en kollega, exportera ett resultat. För en katalogliknande app: söka, filtrera, klicka på en post, spara den. Tre eller fyra riktiga flöden, på vanlig svenska.

Lista B – de olyckliga vägarna. Tänk om användaren gör något nästan rätt men inte riktigt? Skriver sin e-post med ett stavfel. Trycker på bakåtknappen mitt i ett flöde. Öppnar två flikar och redigerar samma sak i båda. Skickar in ett tomt formulär. Klistrar in innehållet i ett Word-dokument – formatering och allt – i ett textfält. Stänger laptopen och öppnar den igen tio minuter senare. Försöker bjuda in en kollega med en e-postadress som redan finns i systemet.

Lista över lyckade vägar är vad din AI-appbyggare optimerade för. Det är vad AI:n mentalt testade medan den skrev koden. Listan över olyckliga vägar är där buggarna bor, eftersom nästan ingen – inte AI:n, inte du när du instruerade den – tänkte på de fallen.

När du faktiskt testar, gå igenom Lista A först för att bekräfta att grunderna fungerar. Lägg sedan merparten av din tid på Lista B. Lista B är där värdet finns. Lista B är också där du upptäcker vad du faktiskt vill att appen ska göra när saker går snett, vilket ofta tvingar fram ett klargörande samtal med AI-byggaren (“när formuläret är halvifyllt, ska det varna eller spara automatiskt?”).

Tre saker att ha sönder med flit

När du väl har dina listor, här är tre kategorier som fångar majoriteten av riktiga buggar i AI-byggda appar.

Tomma och konstiga inmatningar. Skicka in formuläret utan att fylla i något. Skicka in det med ett fält ifyllt. Skicka in ett namn som är 500 tecken långt. Skicka in ett namn med emoji. Klistra in en URL i ett fält som förväntar sig ett namn. Prova e-postfältet med “test”, med “test@”, med “test@example”, med adressen “a@b.co” – accepterar det legitima korta e-postadresser? AI-appbyggare lägger ofta till validering, men valideringen kan vara fel åt båda håll – för strikt (avvisar riktiga användare) eller för slapp (accepterar skräp).

Gå bakåt och i sidled. De flesta appar fungerar fint om du går igenom dem som en lydig turistgrupp. De går sönder i samma stund någon utforskar. Klicka på bakåtknappen. Klicka framåt igen. Uppdatera sidan mitt i ett flöde. Öppna samma sida i två flikar och redigera i båda. Logga ut och in igen. Om du har en “ångra”-knapp, klicka på den tre gånger i rad. Det här är inte specialfall. Så här använder riktiga människor programvara.

Datan efteråt. Bygg det din app bygger. Ett projekt, ett inlägg, en post, vad som helst. Kom sedan tillbaka imorgon. Finns det fortfarande där? Överlevde formateringen? Om du redigerar det, sparas redigeringen? Om du raderar det, är det faktiskt borta, eller kommer det tillbaka när du uppdaterar? AI-appbyggare spikar ofta “skapa”-flödet och glömmer att allt du skapar behöver bestå och kunna redigeras senare.

Hur “tillräckligt bra” ser ut

Du kommer aldrig att testa din AI-byggda app till perfektion. Programvara är för intrasslad och din tid är för värdefull. Frågan är inte “är den perfekt” – det är “är den tillräckligt bra för nästa grupp människor jag ska sätta framför den”.

Här är en grov hierarki du kan låna.

Tillräckligt bra för att demonstrera: den lyckade vägen fungerar utan att krascha. Knappar går dit de ska. Du kan visa en skärminspelning utan att klippa bort något.

Tillräckligt bra för vänligt sinnade användare: de olyckliga vägarna förlorar inte data. Formulär berättar vad som är fel i stället för att tyst misslyckas. Att uppdatera sidan har inte sönder något. Tre vänner kan använda det utan att messa dig för hjälp.

Tillräckligt bra för betalande användare: appen hanterar användare du aldrig träffat. Deras webbläsare, deras data, deras vanor. Du har ett sätt att se när saker går sönder (grundläggande felspårning räcker – du behöver ingen påkostad instrumentpanel). Du kan fixa och deploya om utan att ha sönder det för folk som redan använder det.

De flesta byggare skeppar på “vänligt sinnade användare”-nivån och uppgraderar sedan allteftersom återkoppling kommer in. Det är rätt. Misstaget är att försöka hoppa från “tillräckligt bra för att demonstrera” rakt till “tillräckligt bra för betalande användare” utan mellansteget. Vänligt sinnade användare hittar saker som riktiga användare skulle hitta – men de blir inte arga över dem. Använd det gapet.

När du ska be AI:n testa åt dig

Din AI-appbyggare kan hjälpa till med testning, men du måste vara specifik om vad du vill. “Lägg till tester” är en dålig instruktion. Den genererar kod som ser ut som tester och förmodligen går igenom, utan att faktiskt kontrollera något du bryr dig om. De flesta av de där autogenererade testerna bekräftar att 1+1 fortfarande är 2.

En bättre instruktion: “Jag försökte just skicka in registreringsformuläret med ett tomt e-postfält och det kraschade. Hitta var det hanteras och lägg till en kontroll som visar ett vänligt fel i stället.” Specifik bugg, specifik fix, specifikt resultat. AI:n är bra på det här. Den är dålig på “se till att min app är buggfri” eftersom det inte är en uppgift – det är en önskan.

Det andra AI-byggare är bra på är att spela upp din bugg igen. Om du beskriver vad du gjorde, vad du förväntade dig och vad som hände, kan byggaren oftast spåra genom koden och föreslå en fix. Disciplinen du behöver är disciplinen att skriva ner de tre sakerna tydligt. De flesta nybörjarbuggrapporter är någon version av “det fungerar inte”. De flesta fixbara buggrapporter är “jag klickade på X, förväntade mig Y, fick Z”.

Testning är att läsa, inte bara klicka

En sista sak. Du behöver inte förstå varje rad kod i din AI-byggda app för att testa den väl. Men du borde åtminstone skumma. Öppna filen AI:n just ändrade. Läs funktionen den lade till. Du behöver inte veta vad varje nyckelord betyder – du behöver veta om funktionen verkar göra det du bad om.

Många AI-byggda buggar är inte “koden är trasig”. De är “koden gör något lite annorlunda än vad du ville”. Ett fält sparas på fel ställe. En knapp uppdaterar en sak men inte den relaterade. En “radera”-knapp döljer i stället för att radera. Du kan inte fånga de där utan att läsa vad som faktiskt byggdes.

Behandla koden som något du kan granska, inte något du måste skriva. Det är skillnaden mellan en AI-byggd app du litar på och en du bara hoppas fungerar.

Den enkla versionen

Om du inte minns något annat: skriv de två listorna, ha sönder saker med flit, och bestäm vilken “tillräckligt bra”-nivå du skeppar på. De flesta buggar i en AI-byggd app är inte subtila. De sitter på listan över olyckliga vägar som ingen brydde sig om att skriva ner.

Om du vill ha en liten läxa: välj en app du byggt och prova fyra saker – skicka in ett tomt formulär, tryck uppdatera mitt i ett flöde, redigera en post och kontrollera den imorgon, och be en vän använda det utan att du tittar på. Vad som än går sönder är din riktiga bugglista. Allt annat är prokrastinering.