Testing i livet til en programmerer

Hvorfor trenger programmerere testing?

De neste par nivåene vil bli viet til testing på den måten som programmerere trenger det . Men først, la oss finne ut hva testing er og hvorfor det er nødvendig.

Med hensyn til programvare kan vi si at oppgaven med å teste er å sjekke at programmet:

• gjør det hun må gjøre
• gjør ikke det hun ikke burde gjøre

Det andre punktet er forresten ikke mindre viktig enn det første, men mer om det senere.

La oss starte med det første punktet. Hva betyr "programmet gjør det det skal gjøre"?

Først må noen lage en liste over alle brukstilfellene for programmet. For det andre må de beskrive hvordan programmet skal fungere, hvordan brukeren skal oppføre seg, og hvilke resultater som forventes. Du kan ikke fortsette videre.

Så snart vi skrev «hvordan brukeren skulle oppføre seg», falt hele ideen om å skrive god dokumentasjon fra hverandre. Folk er ikke maskiner, dessuten oppfører folk seg veldig ofte med programvare som de vil . Ingen begynner å bli kjent med teknologi ved å studere instruksjonene. Det er fakta.

Derfor får vi et nytt faktum: Det særegne ved programvaren er at den har mange forskjellige arbeidsscenarier. Noen av dem er åpenbare, andre kan dokumenteres, andre kan antas, andre kan gjettes, og de andre 50% vil ikke engang falle deg inn for deg.

Fra en programmerers synspunkt er de fleste feil ikke feil i det hele tatt. En feil er når et program ikke fungerer som det skal eller som forventet. Og det er mange situasjoner når det ikke er klart hvordan programmet skal fungere, eller scenarier som motsier hverandre ...

Det er et uendelig antall scenarier, og det vil alltid være tilfeller i produktet når programmet ikke oppfører seg som forventet (programmereren skrev koden for bare et par dusin scenarier). Derfor kan det hevdes at det alltid er feil i ethvert program , og ethvert produkt kan forbedres i det uendelige .

Etter det kommer alt ned til hensiktsmessighet. Først fikser programmereren de største feilene, deretter de mindre feilene, og så videre. Og til slutt kommer det et stadium hvor eieren av produktet mener at det ikke er økonomisk mulig å fortsette å jobbe med det.

Men tilbake til feilene som alle gjenkjenner som feil: programmet gjør åpenbart noe galt, falt, ødela noe osv. Slike feil kan betinget deles inn i 3 kategorier: stor, middels og liten.

Og veldig ofte skjer det at en programmerer jobber med å fikse middels eller til og med små feil, selv om det fortsatt er mange mer alvorlige problemer i prosjektet. Han fant dem bare ikke , så han jobber med de største han vet om.

Derfor bør det være testere i ethvert prosjekt. Disse menneskene lærer spesifikt å se på produktet fra forskjellige vinkler. Så du kan se flere scenarier av programmet. Deres oppgave er å finne feil og skrive dem ned (for ikke å finne den samme feilen flere ganger).

Testing er en prosess som tar sikte på å finne feil. Disse feilene bør finnes, beskrives og prioriteres. Først etter prioritering av feil kan vi snakke om en effektiv programvareforbedringsprosess.

Husk at det første trinnet for å løse et problem er å erkjenne at det er et problem . Du kan ikke fikse en feil du ikke vet om.

Test automatisering

Jeg tror vi alle var enige om at testing er viktig, så la oss se på testing som programmerere. Hvordan ser programmerere på testing? Programmerere automatiserer arbeidet til andre mennesker. Det siste yrket som forsvinner blir programmeringsyrket.

Vi automatiserer alle prosesser vi møter. Så testing må automatiseres. Og hvordan automatisere søket etter feil? Kort svar: nei. Men her kommer igjen det faktum at vi er programmerere til unnsetning.

Programvareutviklingsprosessen består av konstante endringer i den. bare i ferd med å stadig gjøre endringer, bryter programmerere veldig ofte noe som fungerte bra inntil nylig.

Og testere, i stedet for å lete etter nye feil, blir tvunget til hele tiden å sjekke om vi har ødelagt noe som har fungert bra i lang tid. Den såkalte regresjonstestingen. Det er denne typen testing som kan og bør automatiseres.

Her kan all programvare deles inn i to deler:

• programmet samhandler med personen
• programmet samhandler med et annet program

Det første alternativet er vanskeligere å automatisere, det krever spesielle automatortestere, de kalles også QA Automation eller Software Test Engineer.

Men det andre alternativet kan og bør automatiseres uavhengig. Hvis du har et stykke programvare som:

• fungerer fint
• allerede testet
• implementert som en egen modul eller logisk blokk
• planlegger ikke å endre
• andre moduler eller programmer avhenger av det
• funksjonssvikt er kostbart

Jeg anbefaler at du tar deg tid til å skrive tester for den som fanger opp viktige aspekter ved den nåværende funksjonaliteten. Det vil være rimelig å sette av 5 % av arbeidstiden din til dette , eller 1 dag per måned.

Ingen grunn til å skrive tester for testenes skyld.

Ingen vil støtte testene dine. Ikke andre programmerere, ikke deg selv. Ingen gjør det. 99 % av alle skriftlige prøver blir forlatt og/eller deaktivert. Hvis du ikke kan skrive prøver - ikke skriv. Skriv bare hvis du absolutt ikke kan klare deg uten dem.

Typer testing

Hver programmerer, hvis han ikke har gjennomgått spesiell opplæring, vil med egne ord kunne fortelle hva testing er: å sjekke om programmet gjør det det skal. Imidlertid skiller fagfolk på dette feltet hele områder (typer) av testing.

All testing dreier seg egentlig om påliteligheten og tilgjengeligheten til programvare, men for bedre å forstå testretningen, la oss se på noen få eksempler.

La oss si at du tester en typisk nettbutikk. Deretter kan testområdene deles inn i følgende typer: ytelsestesting, funksjonstesting, integrasjonstesting og enhetstesting.

Hvis nettstedeieren bestemmer seg for å starte en seriøs reklamekampanje, vil mange brukere komme til nettstedet samtidig. Det kan godt hende at siden ikke faller, men noen av delene kan være trege eller slutte å fungere.

For å forhindre at dette skjer, må du identifisere slike problemer på forhånd og ta skritt for å eliminere dem. Dette gjøres ved hjelp av belastningstesting , eller det kalles også ytelsestesting.

Det kan også være lurt å teste hvordan din backend API fungerer og teste hver funksjon av den: registrering, pålogging, legg til i handlekurv, betalingsbehandling, databaseskriving osv. Alt skal fungere i henhold til TOR. I dette tilfellet må du utføre funksjonstesting .

Din nettbutikk er mest sannsynlig integrert med tredjepartstjenester: sending av brev og SMS, betalingssystemer, nettstøttechatter, innhenting av tilbakemeldinger fra brukere, annonsesystemer osv. For å være sikker på at alt dette fungerer etter hensikten, må du integrasjonsteste .

Til slutt blir komplekse produkter ofte brutt ned i uavhengige moduler. Fra slike moduler kan du sette sammen sluttproduktet, som fra en konstruktør. Hvis du utvikler en slik modul eller samhandler med slike moduler, må du utføre enhetstesting .

Oppsummert kan vi si at funksjonstesting er nødvendig for å teste hver enkelt funksjon på nettstedet. Integrasjon - for å teste samspillet mellom store moduler og systemer i produktet ditt. Modulær - for å teste en separat modul, vel, ytelsestesting - for å sjekke driften av nettstedet ditt under belastning.

Det kan være enda flere typer testing: Jo mer komplekst produktet er, jo flere aspekter av utviklingen må kontrolleres.