Varför behöver programmerare testas?
De kommande nivåerna kommer att ägnas åt att testa på det sätt som programmerare behöver det . Men först, låt oss ta reda på vad testning är och varför det behövs.
När det gäller mjukvara kan vi säga att uppgiften med att testa är att kontrollera att programmet:
- gör vad hon måste göra
- gör inte det hon inte borde göra
Den andra punkten är för övrigt inte mindre viktig än den första, men mer om det senare.
Låt oss börja med den första punkten. Vad betyder "programmet gör vad det ska göra"?
Först måste någon göra en lista över alla användningsfall för programmet. För det andra behöver de beskriva hur programmet ska fungera, hur användaren ska bete sig och vilka resultat som förväntas. Du kan inte fortsätta längre.
Så fort vi skrev "hur användaren ska bete sig" föll hela idén med att skriva bra dokumentation. Människor är inte maskiner, dessutom beter sig människor väldigt ofta med mjukvara som de vill . Ingen börjar sin bekantskap med teknik genom att studera instruktionerna. Det är fakta.
Därför får vi ett nytt faktum: det speciella med programvaran är att den har många olika arbetsscenarier. Vissa av dem är uppenbara, andra kan dokumenteras, andra kan antas, andra kan gissas, och de andra 50% kommer inte ens att falla dig in.
Ur en programmerares synvinkel är de flesta buggar inte buggar alls. Ett fel är när ett program inte fungerar som det ska eller som förväntat. Och det finns många situationer när det inte är klart hur programmet ska fungera, eller scenarier som motsäger varandra ...
Det finns ett oändligt antal scenarier, och det kommer alltid att finnas fall i produkten när programmet inte beter sig som förväntat (programmeraren skrev koden för bara ett par dussin scenarier). Därför kan det hävdas att det alltid finns buggar i alla program och alla produkter kan förbättras i det oändliga .
Efter det handlar allt om ändamålsenligheten. Först fixar programmeraren de största buggarna, sedan de mindre buggarna och så vidare. Och slutligen kommer det ett skede då ägaren av produkten anser att det inte är ekonomiskt möjligt att fortsätta arbeta med den.
Men tillbaka till felen som alla känner igen som fel: programmet gör uppenbarligen något fel, föll, gick sönder något etc. Sådana fel kan villkorligt delas in i 3 kategorier: stora, medelstora och små.
Och väldigt ofta händer det att en programmerare arbetar med att fixa medelstora eller till och med små buggar, även om det fortfarande finns många allvarligare problem i projektet. Han hittade dem bara inte , så han jobbar på de största han känner till.
Därför bör det finnas testare i alla projekt. Dessa människor lär sig specifikt att titta på produkten från olika vinklar. Så du kan se fler scenarier av programmet. Deras uppgift är att hitta fel och skriva ner dem (för att inte hitta samma fel flera gånger).
Testning är en process som syftar till att hitta fel. Dessa buggar bör hittas, beskrivas och prioriteras. Först efter prioritering av fel kan vi prata om en effektiv process för mjukvaruförbättring.
Kom ihåg att det första steget för att lösa ett problem är att erkänna att det finns ett problem . Du kan inte fixa ett misstag du inte känner till.
Testa automatisering
Jag tror att vi alla var överens om att testning är viktigt, så låt oss titta på testning som programmerare. Hur ser programmerare på testning? Programmerare automatiserar andra människors arbete. Det sista yrket som försvinner blir programmeringsyrket.
Vi automatiserar alla processer vi stöter på. Så testerna måste automatiseras. Och hur automatiseras sökningen efter fel? Kort svar: nej. Men även här kommer det faktum att vi är programmerare till vår hjälp.
Mjukvaruutvecklingsprocessen består av ständiga förändringar av den. bara i färd med att ständigt göra ändringar, bryter programmerare väldigt ofta något som fungerade bra tills nyligen.
Och testare, istället för att leta efter nya fel, tvingas ständigt kontrollera om vi har gått sönder något som har fungerat bra under en längre tid. Den så kallade regressionstestningen. Det är denna typ av testning som kan och bör automatiseras.
Här kan all mjukvara delas upp i två delar:
- programmet interagerar med personen
- programmet interagerar med ett annat program
Det första alternativet är svårare att automatisera, det kräver speciella automattestare, de kallas även QA Automation eller Software Test Engineer.
Men det andra alternativet kan och bör automatiseras oberoende. Om du har en mjukvara som:
- funkar bra
- redan testat
- implementeras som en separat modul eller logiskt block
- planerar inte att ändra
- andra moduler eller program beror på det
- funktionsfel är kostsamt
Jag rekommenderar att du tar dig tid att skriva tester för den som fångar viktiga aspekter av dess nuvarande funktionalitet. Det skulle vara rimligt att avsätta 5 % av din arbetstid för detta , eller 1 dag per månad.
Inget behov av att skriva prov för provens skull.
Ingen kommer att stödja dina tester. Inte andra programmerare, inte du själv. Ingen gör det. 99 % av alla skriftliga prov är övergivna och/eller inaktiverade. Om du inte kan skriva prov – skriv inte. Skriv bara om du absolut inte klarar dig utan dem.
Typer av testning
Varje programmerare, om han inte har genomgått särskild utbildning, kommer att kunna berätta med sina egna ord vad testning är: att kontrollera om programmet gör vad det ska. Men yrkesverksamma inom detta område särskiljer hela områden (typer) av testning.
All testning kretsar egentligen kring programvarans tillförlitlighet och tillgänglighet, men för att bättre förstå testriktningen, låt oss titta på några exempel.
Låt oss säga att du testar en typisk webbutik. Sedan kan testområdena delas in i följande typer: prestandatestning, funktionstestning, integrationstestning och enhetstestning.
Om webbplatsägaren bestämmer sig för att lansera en seriös reklamkampanj, kommer många användare att komma till webbplatsen samtidigt. Det kan mycket väl vara så att sajten inte faller, men vissa av dess avsnitt kan vara långsamma eller till och med sluta fungera.
För att förhindra att detta inträffar måste du identifiera sådana problem i förväg och vidta åtgärder för att eliminera dem. Detta görs med hjälp av belastningstestning , eller så kallas det även prestandatestning.
Du kanske också vill testa hur ditt backend-API fungerar och testa alla funktioner i det: registrering, inloggning, lägg till i kundvagn, betalningshantering, databasskrivningar etc. Allt ska fungera enligt TOR. I det här fallet måste du utföra funktionstestning .
Din webbutik är med största sannolikhet integrerad med tredjepartstjänster: skicka brev och SMS, betalningssystem, supportchattar online, samla in feedback från användare, reklamsystem etc. För att säkerställa att allt detta fungerar som det är tänkt behöver du integreringstesta .
Slutligen är komplexa produkter ofta uppdelade i oberoende moduler. Från sådana moduler kan du montera den slutliga produkten, som från en konstruktör. Om du utvecklar en sådan modul eller interagerar med sådana moduler, måste du göra enhetstestning .
Sammanfattningsvis kan vi säga att funktionstestning behövs för att testa varje enskild funktion på sajten. Integration - för att testa interaktionen mellan stora moduler och system i din produkt. Modulär - för att testa en separat modul, ja, prestandatestning - för att kontrollera hur din webbplats fungerar under belastning.
Det kan finnas ännu fler typer av testning: ju mer komplex produkten är, desto fler aspekter av dess utveckling måste kontrolleras.