Inledning
God eftermiddag, Khabrovsk-bor. Just nu löste jag en testuppgift för en QA Lead ledig tjänst för ett fintechföretag. Den första uppgiften, att skapa en testplan med en komplett checklista och exempel på testfall för att testa en vattenkokare, kan lösas trivialt:
Det är svårt att komma på en bättre testplan med en komplett checklista.
Men den andra delen visade sig vara en fråga: "Finns det några gemensamma problem för alla testare som hindrar dem från att arbeta mer effektivt?"
Det första som kom att tänka på var att lista alla mer eller mindre märkbara problem som jag stötte på under testningen, sålla bort de små sakerna och sammanfatta resten. Men jag insåg snabbt att den induktiva metoden skulle svara på en fråga som inte gällde "alla", utan i bästa fall bara för "majoriteten" av testarna. Därför bestämde jag mig för att närma mig det från andra sidan, deduktivt, och det här är vad som hände.
definiera
Det första jag brukar göra när jag löser ett nytt problem är att försöka förstå vad det handlar om, och för att göra detta måste jag förstå innebörden av orden som utgör det. Nyckelorden att förstå är följande:
- ett problem
- testare
- testarjobb
- testarens effektivitet
Låt oss vända oss till Wikipedia och sunt förnuft:
(forngrekiska πρόβλημα) i vid mening - en komplex teoretisk eller praktisk fråga som kräver studier och lösning; inom vetenskap - en motsägelsefull situation som uppträder i form av motsatta positioner i förklaringen av alla fenomen, objekt, processer och kräver en adekvat teori för att lösa det; i livet är problemet formulerat i en form som är förståelig för människor: "Jag vet vad, jag vet inte hur", det vill säga det är känt vad som behöver erhållas, men det är inte känt hur man gör det . Kommer från sent. lat. problem, från grekiska. πρόβλημα ”kastad fram, placerad framför”; från προβάλλω ”kasta fram, lägg framför dig; skylla".
Det är inte mycket meningsfullt, faktiskt, "problem" = "något som måste hanteras."
- en specialist (vi kommer inte att dela in i typer, eftersom vi är intresserade av alla testare) som deltar i att testa en komponent eller ett system, vars resultat är:
— En uppsättning aktiviteter relaterade till testning.
(lat. effectivus) - förhållandet mellan det uppnådda resultatet och de resurser som används (: 2015).
- en konsekvens av en kedja (serie) av handlingar (resultat) eller händelser, uttryckta kvalitativt eller kvantitativt. Möjliga resultat inkluderar fördel, nackdel, vinst, förlust, värde och seger.
Precis som med "problemet" finns det liten mening: något som kom ut som ett resultat av arbete.
- den kvantitativt mätbara möjligheten att utföra någon aktivitet av en eller flera personer; förhållanden som tillåter användning av vissa transformationer för att uppnå önskat resultat. Testaren är en person, och i enlighet med teorin om vitala resurser är varje person ägare till fyra ekonomiska tillgångar:
kontanter (inkomst) är en förnybar resurs;
energi (livskraft) är en delvis förnybar resurs;
tid är en fast och i grunden icke-förnybar resurs;
kunskap (information) är en förnybar resurs, den är en del av humankapitalet som kan växa och förstöras.
Jag vill notera att definitionen av effektivitet i vårt fall inte är helt korrekt, eftersom ju mer kunskap vi använder desto lägre effektivitet. Därför skulle jag omdefiniera effektivitet som "förhållandet mellan uppnådda resultat och de resurser som förbrukas." Då är allt korrekt: kunskap slösas inte bort under arbetet, men det minskar kostnaderna för testarens enda i grunden icke-förnybara resurs - hans tid.
beslutet
Så vi letar efter globala problem med testare som försämrar effektiviteten i deras arbete.
Den viktigaste resursen som spenderas på en testares arbete är hans tid (resten kan reduceras till det på ett eller annat sätt), och för att vi ska kunna prata om korrekt beräkning av effektivitet måste resultatet också reduceras till tid .
För att göra detta, överväg ett system vars lönsamhet testaren säkerställer genom sitt arbete. Ett sådant system är ett projekt vars team inkluderar en testare. Projektets livscykel kan grovt representeras av följande algoritm:
- Arbeta med krav
- Utformning av tekniska specifikationer
- utformning
- testning
- Släpps i produktion
- Support (gå till punkt 1)
I det här fallet kan hela projektet rekursivt delas upp i delprojekt (funktioner), med samma livscykel.
Ur projektets synvinkel, ju mindre tid som läggs på det, desto effektivare är genomförandet.
Således kommer vi till definitionen av den maximala möjliga effektiviteten för en testare ur projektets synvinkel - detta är projektets tillstånd när tiden för testning är noll. Ett vanligt problem för alla testare är oförmågan att uppnå denna tid.
Hur ska man hantera det?
Slutsatserna är ganska uppenbara och har använts av många under lång tid:
- Utveckling och testning bör börja och avslutas nästan samtidigt (detta görs vanligtvis av avdelningen ). Det idealiska alternativet är när all funktionalitet som utvecklas redan täcks av autotester när den är klar, organiserad i regressionstestning (och, om möjligt, pre-commit) testning med någon form av .
- Ju fler funktioner ett projekt har (ju mer komplext det är), desto mer tid kommer det att behöva läggas på att kontrollera att den nya funktionen inte bryter den gamla. Ju mer komplext projektet är, desto mer automatisering krävs .
- Varje gång vi missar en bugg i produktionen och en användare hittar den måste vi lägga ytterligare tid på att gå igenom projektets livscykel med start från punkt 1 (att arbeta med krav, i detta fall användare). Eftersom orsakerna till att en bugg saknas i allmänhet är okända, har vi bara en optimeringsväg kvar - varje bugg som hittas av användare måste inkluderas i regressionstestning för att vara säker på att den inte kommer att dyka upp igen.
Källa: will.com