Indledning
God eftermiddag, Khabrovsk beboere. Lige nu var jeg ved at løse en testopgave til en QA Lead ledig stilling for en fintech virksomhed. Den første opgave, at lave en testplan med en komplet tjekliste og eksempler på testcases til test af en elkedel, kan løses trivielt:
Det er svært at tænke på en bedre testplan med en komplet tjekliste.
Men den anden del viste sig at være et spørgsmål: "Er der nogen fælles problemer for alle testere, der forhindrer dem i at arbejde mere effektivt?"
Det første, der kom til at tænke på, var at liste alle de mere eller mindre mærkbare problemer, som jeg stødte på under testen, luge ud i de små ting og opsummere resten. Men jeg indså hurtigt, at den induktive metode ville besvare et spørgsmål, der ikke gjaldt "alle", men i bedste fald kun for "de fleste" af testere. Derfor besluttede jeg at gribe det an fra den anden side, deduktivt, og det er, hvad der skete.
definere
Det første, jeg plejer at gøre, når jeg løser et nyt problem, er at prøve at forstå, hvad det handler om, og for at gøre dette er jeg nødt til at forstå betydningen af de ord, der udgør det. Nøgleordene for at forstå er følgende:
- et problem
- tester
- tester job
- testerens effektivitet
Lad os vende os til Wikipedia og sund fornuft:
(oldgræsk πρόβλημα) i bred forstand - et komplekst teoretisk eller praktisk spørgsmål, der kræver undersøgelse og løsning; i videnskab - en modstridende situation, der optræder i form af modsatrettede positioner i forklaringen af ethvert fænomen, objekter, processer og kræver en passende teori for at løse det; i livet er problemet formuleret i en form, der er forståelig for folk: "Jeg ved hvad, jeg ved ikke hvordan," det vil sige, det ved, hvad der skal opnås, men man ved ikke, hvordan man gør det . Kommer fra sent. lat. problem, fra græsk. πρόβλημα "kastet fremad, placeret foran"; fra προβάλλω “kast frem, læg foran dig; bebrejde".
Det giver ikke meget mening, faktisk "problem" = "alt, der skal håndteres."
- en specialist (vi opdeler ikke i typer, da vi er interesserede i alle testere), som deltager i test af en komponent eller et system, hvis resultat er:
— et sæt aktiviteter relateret til test.
(lat. effectivus) - forholdet mellem det opnåede resultat og de anvendte ressourcer (: 2015).
- en konsekvens af en kæde (række) af handlinger (resultat) eller begivenheder, udtrykt kvalitativt eller kvantitativt. Mulige resultater omfatter fordel, ulempe, gevinst, tab, værdi og sejr.
Ligesom med "problemet" er der lidt mening: noget, der kom ud som et resultat af arbejde.
- den kvantitativt målbare mulighed for at udføre enhver aktivitet af en person eller et folk; forhold, der gør det muligt at bruge visse transformationer for at opnå det ønskede resultat. Testeren er en person, og i overensstemmelse med teorien om vitale ressourcer er hver person ejer af fire økonomiske aktiver:
kontanter (indkomst) er en vedvarende ressource;
energi (livskraft) er en delvist vedvarende ressource;
tid er en fast og grundlæggende ikke-fornyelig ressource;
viden (information) er en vedvarende ressource, den er en del af menneskelig kapital, der kan vokse og ødelægges.
Jeg vil gerne bemærke, at definitionen af effektivitet i vores tilfælde ikke er helt korrekt, da jo mere viden vi bruger, jo lavere effektivitet. Derfor vil jeg omdefinere effektivitet som "forholdet mellem de opnåede resultater og de forbrugte ressourcer." Så er alt korrekt: viden spildes ikke under arbejdet, men det reducerer omkostningerne til testerens eneste grundlæggende ikke-fornyelige ressource - hans tid.
beslutning
Så vi leder efter globale problemer med testere, der forringer effektiviteten af deres arbejde.
Den vigtigste ressource, der bruges på en testers arbejde, er hans tid (resten kan reduceres til det på den ene eller anden måde), og for at vi kan tale om den korrekte beregning af effektivitet, skal resultatet også reduceres til tid .
For at gøre dette skal du overveje et system, hvis levedygtighed testeren sikrer gennem sit arbejde. Et sådant system er et projekt, hvis team omfatter en tester. Projektets livscyklus kan groft repræsenteres af følgende algoritme:
- Arbejde med krav
- Dannelse af tekniske specifikationer
- design
- Test
- Frigives i produktion
- Support (gå til punkt 1)
I dette tilfælde kan hele projektet rekursivt opdeles i delprojekter (features), med samme livscyklus.
Fra projektets synspunkt, jo mindre tid der bruges på det, desto mere effektiv er implementeringen.
Således kommer vi til definitionen af den maksimalt mulige effektivitet af en tester set fra projektets synspunkt - dette er projektets tilstand, når tiden for test er nul. Et fælles problem for alle testere er manglende evne til at nå denne tid.
Hvordan skal man håndtere dette?
Konklusionerne er ret indlysende og har været brugt af mange i lang tid:
- Udvikling og test skal begynde og slutte næsten samtidigt (dette udføres normalt af afdelingen ). Den ideelle mulighed er, når al den funktionalitet, der udvikles, allerede er dækket af autotest, når den er klar, organiseret i regression (og, hvis det er muligt, pre-commit) test ved hjælp af en form for .
- Jo flere funktioner et projekt har (jo mere komplekst det er), jo mere tid skal der bruges på at kontrollere, at den nye funktionalitet ikke bryder den gamle. Derfor, jo mere komplekst projektet er, jo mere automatisering kræves der .
- Hver gang vi savner en fejl i produktionen, og en bruger finder den, skal vi bruge ekstra tid på at gennemgå projektets livscyklus fra punkt 1 (Arbejd med krav, i dette tilfælde brugere). Da årsagerne til at mangle en fejl generelt er ukendte, står vi tilbage med kun én optimeringssti - hver fejl fundet af brugere skal inkluderes i regressionstest for at være sikker på, at den ikke dukker op igen.
Kilde: www.habr.com