Understrukna ord finns i lektionsordlistan. Tryck på ett ord för att se alla översättningar. Lägg till eller redigera ord i messages/glossary.json (alla språknycklar du lägger till visas i rutan).
Coding, debugging, and design
Testing and quality assurance
Jag ska skriva några enhetstester (unit tests) för den här nya funktionen under eftermiddagen.
Vi måste verkligen utöka vår kodtäckning (code coverage), den ligger på en alldeles för låg nivå just nu.
Jag använder mig av mock-data för att fejka svaret från det externa API:et i testerna.
Våra integrationstester i pipelinen fallerar helt oväntat, jag måste undersöka varför omedelbart.
Har någon haft tid att testa den här fixen manuellt i QA-miljön innan vi skickar ut den?
Jag jobbar mycket med Test-Driven Development (TDD) – jag skriver alltid testet innan själva koden.
Vi måste säkerställa att inga gamla buggar kommer tillbaka, så jag skriver ett regressionstest.
Det är viktigt att vi testar systemet i flera olika webbläsare för att hitta alla skumma rendering-fel.
Vårt E2E-ramverk (End-to-End) automatiserar stora delar av testerna som vi tidigare gjorde för hand.
Jag har satt upp en helt isolerad testdatabas för att testerna inte ska påverka varandra alls.
Några av enhetstesterna verkar vara väldigt instabila (flaky) och misslyckas slumpmässigt ibland.
Vi bör verkligen lasttesta systemet innan vi skickar ut det till den enorma användarbasen på fredag.
Kvalitetssäkringen (QA) har returnerat biljetten eftersom de hittade två allvarliga buggar i flödet.
Jag lägger till ett litet test för det här märkliga undantagsfallet (edge case) för säkerhets skull.
Vi måste säkerställa att formuläret inte går att skicka in om datan som användaren matat in är ogiltig.
Kan vi konfigurera pipelinen (CI/CD) så att den absolut inte tillåter merges om testerna misslyckas?
Jag håller på att skriva ett automatiserat skript som fyller databasen med realistisk testdata åt oss.
Testet förväntar sig att få tillbaka en array, men funktionen returnerar plötsligt ett objekt.
Vi behöver nog införa penetrationstester för att säkerställa att säkerheten är på absolut toppnivå.
För att testa komponenterna i frontend på ett smidigt sätt använder vi Jest och React Testing Library.
Det är väldigt skönt att automatisera QA-processen så mycket det bara går, det sparar massor av tid.
Skulle du vilja hjälpa mig att manuellt klicka igenom flödet för att se om du hittar något konstigt?
Testrapporten från testteamet visar att vi har en hel del prestandaproblem i just den här vyn.
Jag refaktorerar koden enbart för att den ska bli enklare att skriva enhetstester på i framtiden.
Vi bör ha som absolut minimum att varje ny fil som checkas in har minst åttio procent kodtäckning.
Jag använder mutationstester för att se hur pass robusta våra nuvarande enhetstester egentligen är.
Hur hanterar vi testning av asynkrona funktioner och timeouts utan att testet fryser helt?
Det här är ett extremt viktigt 'happy path'-test som säkerställer att användarens huvudflöde alltid fungerar.
Vi måste dokumentera exakt hur vi utförde testet så att QA-teamet kan replikera det senare.
Jag har hittat en kritisk bugg i testmiljön (staging), som tur är nådde den aldrig produktionsmiljön.
Jag ska bygga om testsviten eftersom den tar på tok för lång tid att köra igenom, nästan tjugo minuter.
Den här metoden är tyvärr alldeles för tätt kopplad till databasen, jag måste injicera ett mock-objekt här.
Vi testar användargränssnittet med visuella regressionstester för att fånga upp oönskade designändringar.
QA-miljön verkar ligga nere för tillfället, är det någon som uppdaterar servern just nu?
Ett av säkerhetstesterna varnar för att vi inte rensar inputen (sanitization) från användaren ordentligt.
Jag har precis stängt av den inbyggda cachen för att försäkra mig om att testerna är hundra procent tillförlitliga.
Vårt testteam gör ett fantastiskt jobb med att upptäcka extremt subtila buggar i våra nya funktioner.
Kan vi automatisera testningen av tillgängligheten (accessibility) så att den uppfyller WCAG-standarden?
Vi får ständigt falska positiva resultat i testerna, vi måste göra testverktyget lite mer stabilt och pålitligt.
Det sista steget innan lanseringen är User Acceptance Testing (UAT), där kunden får klämma och känna.
Genom att integrera SonarQube i pipelinen får vi en väldigt bra automatisk kvalitetsgranskning av koden.
Jag ser alltid till att köra hela testsviten lokalt på min maskin innan jag ens öppnar en pull request.
Vi utvärderar just nu Playwright som ett mycket snabbare alternativ till vårt gamla E2E-verktyg.
Testet sprack direkt eftersom texten på knappen hade ändrats från 'Spara' till 'Skicka in'.
Det är extremt viktigt att inte logga ut känslig information och personuppgifter i de publika testloggarna.
Vi måste stresstesta nätverket för att se exakt hur systemet beter sig under väldigt dåliga förhållanden.
Jag har lyckats isolera felet, nu skriver jag ett snabbt test som tvingar fram buggen varje gång.
Vår QA-ingenjör har skrivit fantastiskt detaljerade testfall (test cases) baserat på alla våra acceptanskriterier.
Manuell QA-testning är otroligt värdefullt eftersom systemen aldrig helt och hållet kan ersätta det mänskliga ögat.
Alla nittio testerna lyste äntligen grönt, jag godkänner och rullar ut koden till produktion nu!
