Innledning
God ettermiddag, Khabrovsk-innbyggere. Akkurat nå løste jeg en testoppgave for en QA Lead ledig stilling for et fintech-selskap. Den første oppgaven, å lage en testplan med en komplett sjekkliste og eksempler på testtilfeller for testing av en vannkoker, kan løses trivielt:
Det er vanskelig å tenke på en bedre testplan med en fullstendig sjekkliste.
Men den andre delen viste seg å være et spørsmål: "Er det noen problemer som er felles for alle testere som hindrer dem i å jobbe mer effektivt?"
Det første jeg tenkte på var å liste opp alle de mer eller mindre merkbare problemene jeg møtte under testingen, luke ut de små tingene og oppsummere resten. Men jeg innså raskt at den induktive metoden ville svare på et spørsmål som ikke gjaldt "alle", men i beste fall bare for "flertallet" av testerne. Derfor bestemte jeg meg for å nærme meg det fra den andre siden, deduktivt, og dette er hva som skjedde.
definere
Det første jeg vanligvis gjør når jeg løser et nytt problem, er å prøve å forstå hva det handler om, og for å gjøre dette må jeg forstå betydningen av ordene som utgjør det. Nøkkelordene for å forstå er følgende:
- problem
- tester
- tester jobb
- testerens effektivitet
La oss gå til Wikipedia og sunn fornuft:
(gammelgresk πρόβλημα) i vid forstand - et komplekst teoretisk eller praktisk problem som krever studier og løsning; i vitenskap - en motstridende situasjon som vises i form av motstridende posisjoner i forklaringen av fenomener, objekter, prosesser og krever en tilstrekkelig teori for å løse den; i livet er problemet formulert i en form som er forståelig for folk: "Jeg vet hva, jeg vet ikke hvordan," det vil si at det er kjent hva som må skaffes, men det er ikke kjent hvordan man gjør det . Kommer fra sent. lat. problem, fra gresk. πρόβλημα «kastet frem, plassert foran»; fra προβάλλω «kast frem, legg foran deg; skylde på".
Det gir ikke mye mening, faktisk, "problem" = "noe som må håndteres."
- en spesialist (vi vil ikke dele inn i typer, siden vi er interessert i alle testere) som deltar i testing av en komponent eller et system, hvis resultat er:
— et sett med aktiviteter knyttet til testing.
(lat. effectivus) - forholdet mellom oppnådd resultat og ressursene som brukes (: 2015).
- en konsekvens av en kjede (serie) av handlinger (resultat) eller hendelser, uttrykt kvalitativt eller kvantitativt. Mulige utfall inkluderer fordel, ulempe, gevinst, tap, verdi og seier.
Som med "problemet" er det liten mening: noe som kom ut som et resultat av arbeid.
- den kvantitativt målbare muligheten for å utføre enhver aktivitet til en person eller et folk; forhold som gjør det mulig å oppnå ønsket resultat ved bruk av visse transformasjoner. Testeren er en person, og i samsvar med teorien om vitale ressurser er hver person eier av fire økonomiske eiendeler:
kontanter (inntekt) er en fornybar ressurs;
energi (livskraft) er en delvis fornybar ressurs;
tid er en fast og grunnleggende ikke-fornybar ressurs;
kunnskap (informasjon) er en fornybar ressurs, den er en del av menneskelig kapital som kan vokse og ødelegges.
Jeg vil bemerke at definisjonen av effektivitet i vårt tilfelle ikke er helt korrekt, siden jo mer kunnskap vi bruker, jo lavere effektivitet. Derfor vil jeg redefinere effektivitet som "forholdet mellom oppnådde resultater og ressursene som brukes." Da er alt riktig: kunnskap er ikke bortkastet under arbeidet, men det reduserer kostnadene for testerens eneste grunnleggende ikke-fornybare ressurs - hans tid.
beslutning
Så vi ser etter globale problemer med testere som svekker effektiviteten til arbeidet deres.
Den viktigste ressursen som brukes på en testers arbeid er hans tid (resten kan reduseres til det på en eller annen måte), og for at vi skal snakke om riktig beregning av effektivitet, må resultatet også reduseres til tid .
For å gjøre dette bør du vurdere et system hvis levedyktighet testeren sikrer gjennom sitt arbeid. Et slikt system er et prosjekt hvis team inkluderer en tester. Prosjektets livssyklus kan grovt representeres av følgende algoritme:
- Arbeid med krav
- Dannelse av tekniske spesifikasjoner
- utforming
- Testing
- Slipp i produksjon
- Support (gå til element 1)
I dette tilfellet kan hele prosjektet rekursivt deles inn i delprosjekter (funksjoner), med samme livssyklus.
Fra prosjektets synspunkt, jo mindre tid brukt på det, desto mer effektiv er implementeringen.
Dermed kommer vi til definisjonen av den maksimalt mulige effektiviteten til en tester fra prosjektets synspunkt - dette er tilstanden til prosjektet når tiden for testing er null. Et vanlig problem for alle testere er manglende evne til å oppnå denne tiden.
Hvordan håndtere dette?
Konklusjonene er ganske åpenbare og har blitt brukt av mange i lang tid:
- Utvikling og testing bør begynne og avsluttes nesten samtidig (dette gjøres vanligvis av avdelingen ). Det ideelle alternativet er når all funksjonaliteten som utvikles allerede er dekket av autotester når den er klar, organisert i regresjons- (og, hvis mulig, pre-commit) testing ved bruk av en slags .
- Jo flere funksjoner et prosjekt har (jo mer komplekst det er), jo mer tid vil det måtte brukes på å sjekke at den nye funksjonaliteten ikke bryter den gamle. Derfor, jo mer komplekst prosjektet er, desto mer automatisering kreves det .
- Hver gang vi savner en feil i produksjonen og en bruker finner den, må vi bruke ekstra tid på å gå gjennom prosjektets livssyklus fra punkt 1 (Å jobbe med krav, i dette tilfellet brukere). Siden årsakene til å gå glipp av en feil generelt er ukjente, sitter vi igjen med bare én optimaliseringsbane - hver feil som finnes av brukere må inkluderes i regresjonstesting for å være sikker på at den ikke vises igjen.
Kilde: www.habr.com