Grunnleggende problem med testing

Innledning

God dag, Habr-borgere. Jeg jobbet nylig med en testeroppgave for en stilling som QA Lead hos et fintech-selskap. Den første oppgaven, å lage en testplan med en fullstendig sjekkliste og eksempler på testscenarioer for å teste en elektrisk vannkoker, ble løst trivielt:

• GOST 7400-81. Elektriske vannkokere og elektriske samovarer for husholdningen. Tekniske spesifikasjoner (med endringer N 1-8)
• GOST IEC 60335-1-2015 Husholdnings- og lignende elektriske apparater. Sikkerhet. Del 1. Generelle krav
  Det er vanskelig å tenke ut en bedre testplan med en full sjekkliste.

Men den andre delen viste seg å være et spørsmål: "Er det noen problemer som er felles for alle testere og hindrer dem i å jobbe mer effektivt?".

Det første som kom til meg: å liste opp alle mer eller mindre merkbare problemer jeg hadde støtt på under testing, filtrere bort småting og deretter generalisere det som gjensto. Men jeg innså raskt at induktiv metode ville svare på et spørsmål som gjaldt ikke alle, men i beste fall bare flertallet av testere. Derfor bestemte jeg meg for å angripe det fra en annen vinkel, deduktiv, og her er hva jeg kom opp med.

Definisjoner

Det første jeg vanligvis gjør når jeg løser en ny oppgave, er å prøve å forstå hva den handler om, og for det må jeg forstå meningen med ordene den er formulert med. Nøkkelordene som må klargjøres er som følger:

• problem
• tester
• arbeid som tester
• effektivitet i testerarbeid

La oss se til Wikipedia og sunn fornuft:
Problém (fra gammelgresk πρόβλημα) i bred forstand – et komplisert teoretisk eller praktisk spørsmål som krever studier og løsninger; i vitenskapen – en motstridende situasjon som fremstår som motsatte posisjoner i forklaringen av visse fenomener, objekter, prosesser og som krever en adekvat teori for å løse det; i livet formuleres problemet i en forståelig form for folk som "jeg vet hva, jeg vet ikke hvordan", det vil si at det er kjent hva som må oppnås, men det er ukjent hvordan dette skal gjøres. Det stammer fra senlat. problēma, fra gresk πρόβλημα "kastet frem, stilt foran"; fra προβάλλω "kaste frem, stille foran seg; anklage".

Det er ikke mye mening, i hovedsak er "problem" = "hva som helst som må forstås".
Tester — en spesialist (vi skal ikke dele dem opp i typer, for vi er interessert i alle testere) som deltar i testing av komponenter eller systemer, hvor resultatet av aktiviteten er:
Testerjobb — en kombinasjon av aktiviteter relatert til testing.
Effektivitet (lat. effectivus) — forholdet mellom oppnådd resultat og brukte ressurser (ISO 9000:2015).
Resultat — konsekvensen av en rekke handlinger (sluttresultat) eller hendelser, uttrykt kvalitativt eller kvantitativt. Mulige resultater inkluderer fordeler, ulemper, gevinster, tap, verdi og seier.
Som med "problemet" gir det lite mening: noe som oppstod som følge av arbeidet.
Ressurs — målbar kapasitet til å utføre en aktivitet av en eller flere personer; forhold som gjør det mulig å oppnå ønsket resultat gjennom bestemte transformasjoner. Testeren er en person, og i henhold til teorien om vitale ressurser er hver person utstyrt med fire økonomiske aktiva:
penger (inntekt) — en fornybar ressurs;
energi (livskraft) — en delvis fornybar ressurs;
tid — en fast ressurs og prinsipielt ikke-fornybar;
kunnskap (informasjon) — en fornybar ressurs, en del av menneskelig kapital som både kan vokse og forringes.[1].

Jeg vil påpeke at definisjonen av effektivitet i vårt tilfelle ikke er helt korrekt, for jo mer kunnskap vi bruker, desto lavere blir effektiviteten. Derfor ville jeg redefinere effektivitet som "forholdet mellom oppnådd resultat og brukte ressurser". Da er alt korrekt: kunnskap brukes ikke opp i arbeidet, men reduserer utgiftene til den eneste prinsipielt ikke-fornybare ressursen til testeren — hans tid.

Solution

Så, vi søker etter globale problemer hos testere som reduserer effektiviteten i arbeidet deres.
Den mest betydningsfulle ressursen som brukes i testerens arbeid er tiden hans (andre kan på en eller annen måte relateres til den), og for at vi skal kunne snakke om en korrekt beregning av effektivitet, må resultatet også relateres til tid.
La oss vurdere et system hvis levedyktighet sikres av testerens arbeid. Et slikt system er et prosjekt som inkluderer en tester i teamet. Livssyklusen til prosjektet kan grovt sett anses som følgende algoritme:

1. Arbeid med krav
2. Utforming av teknisk spesifikasjon
3. Utvikling
4. Testing
5. Utgivelse i produksjon
6. Støtte (gå til p.1)

Hele prosjektet kan også rekursivt deles opp i delprosjekter (funksjoner) med samme livssyklus.
Fra prosjektets perspektiv er effektiviteten av implementeringen desto høyere jo mindre tid som brukes på det.
Dermed kommer vi til definisjonen av maksimal mulig effektivitet for testeren sett fra prosjektets perspektiv — det er en tilstand av prosjektet der tiden brukt på testing er lik null. Et generelt problem for alle testere er umuligheten av å oppnå denne tiden.

Hva skal vi gjøre med dette?

Konklusjonene er åpenbare og har lenge vært brukt av mange:

1. Utvikling og testing bør starte og avsluttes praktisk talt samtidig (dette håndteres vanligvis av avdelingen QA). Det ideelle alternativet er når all funksjonalitet som utvikles er dekket av autotester på tidspunktet for ferdigstillelse, organisert i regresjonstesting (og i mulig grad pre-commit testing) ved hjelp av en eller annen CI.
2. Jo fler funksjoner i prosjektet (jo mer komplisert det er), desto mer tid må brukes på å sjekke at den nye funksjonaliteten ikke ødela den gamle. Herfra følger at jo mer komplekst prosjektet er, jo mer automatisering kreves for regresjonstesting.
3. Hver gang vi overser en feil i produksjon, og brukeren oppdager den, må vi bruke ekstra tid på å gå gjennom prosjektets livssyklus fra punkt 1 (Arbeid med krav, i dette tilfellet brukernes krav). Siden årsakene til å overse feilen generelt er ukjente, har vi bare én vei for optimalisering — hver feil funnet av brukerne må inkluderes i regresjonstesting for å være sikker på at den ikke dukker opp igjen.

Kilde: habr.com