Den grundläggande problematiken kring testning

Introduktion

Hej, Habr-användare. Jag löste nyligen en testuppgift för en QA Lead-tjänst på ett fintechföretag. Den första uppgiften, att skapa en testplan med en komplett checklista och exempel på testfall för att testa en elektrisk vattenkokare, är ganska trivial.

• GOST 7400-81. Elektriska vattenkokare och el-kannor för hushåll. Tekniska villkor (med ändringar N 1-8)
• GOST IEC 60335-1-2015 Hushålls- och liknande elektriska apparater. Säkerhet. Del 1. Allmänna krav
  Det är svårt att komma på en bättre testplan med en komplett checklista.

Men den andra delen blev en fråga: "Finns det några problem som är gemensamma för alla testare som hindrar dem från att arbeta mer effektivt?"

Det första som kom till tankarna: att lista alla mer eller mindre påtagliga problem som jag stött på under testningen, filtrera bort trivialiteter och sammanfatta resten. Men jag insåg snabbt att den induktiva metoden skulle svara på en fråga som inte handlar om "alla", utan i bästa fall bara om "de flesta" testare. Så jag bestämde mig för att närma mig saken från en annan sida, den deduktiva, och här är vad jag kom fram till.

Definitioner

Det första jag vanligtvis gör när jag tar mig an en ny uppgift är att försöka förstå vad den handlar om, och för det måste jag förstå betydelsen av de ord som används för att formulera den. De nyckelord som behöver redas ut är följande:

• problem
• testare
• testarens arbete
• testarens arbetseffektivitet

Låt oss vända oss till Wikipedia och sunt förnuft:
Problém (från äldre grekiska πρόβλημα) innebär i bred bemärkelse en komplex teoretisk eller praktisk fråga som kräver studium och lösning; inom vetenskapen en motsägelsefull situation som framträder i form av motsatta positioner i förklaringen av vissa fenomen, objekt och processer och som kräver en adekvat teori för att lösa; i livet formuleras ett problem på ett sätt som människor förstår som "jag vet vad, jag vet inte hur", det vill säga det är känt vad som behöver uppnås, men oklart hur detta ska göras. Härstammar från senare latin problēma, från grekiska πρόβλημα "kastat fram, ställt framför"; från προβάλλω "kasta fram, ställa framför sig; anklaga".

Det finns inte mycket mening, i grunden = "problem" = "vad-som-helst som man måste reda ut".
Tester — en specialist (vi kommer inte att dela upp på typer, eftersom vi är intresserade av alla testare) som deltar i testning av en komponent eller system, vars verksamhet resulterar i:
Testerens arbete — en uppsättning åtgärder relaterade till testning.
Effektivitet (lat. effectivus) — förhållandet mellan det uppnådda resultatet och de använda resurserna (ISO 9000:2015).
Resultat — konsekvensen av en kedja (serie) av handlingar (slutresultat) eller händelser, uttryckt kvalitativt eller kvantitativt. Möjliga resultat inkluderar fördel, olägenhet, vinst, förlust, värde och seger.
Som med "problemet" är meningen liten: något, som uppnåddes som ett resultat av arbetet.
Resurs — en kvantitativt mätbar möjlighet att utföra någon aktivitet av en person eller personer; omständigheter som gör det möjligt att få önskat resultat genom vissa transformationer. Testaren är en person, och i enlighet med teorin om vitala resurser, har varje person fyra ekonomiska tillgångar:
penningmedel (inkomst) — en förnybar resurs;
energi (livskraft) — en delvis förnybar resurs;
tid — en fast resurs och principiellt icke-förnybar;
kunskap (information) — en förnybar resurs, en del av humankapitalet, som kan öka eller minska[1].

Jag vill nämna att definitionen av effektivitet i vårt fall inte är helt korrekt, eftersom ju mer kunskap vi använder, desto lägre blir effektiviteten. Därför skulle jag omdefiniera effektivitet som "förhållandet mellan det uppnådda resultatet och de använda resurserna". Då är allt korrekt: kunskap används inte i arbetet, men minskar kostnaderna för den enda principiellt icke-förnybara resursen hos testaren — hans tid.

Lösning

Så, vi letar efter globala problem för testare som försämrar effektiviteten i deras arbete.
Den mest betydelsefulla resursen som investeras i testares arbete är deras tid (övriga kan på ett eller annat sätt relateras till det), och för att vi ska kunna tala om korrekt beräkning av effektivitet, måste också resultatet relateras till tiden.
För detta ska vi titta på ett system vars livskraft testaren säkerställer genom sitt arbete. Ett sådant system är ett projekt som har en tester i sitt team. Livscykeln för projektet kan grovt representeras av följande algoritm:

1. Arbete med krav
2. Utformning av teknisk specifikation
3. Utveckling
4. Testning
5. Släpp till produktion
6. Support (återgå till punkt 1)

Dessutom kan hela projektet rekursivt delas upp i delprojekt (funktioner) med samma livscykel.
Ur projektets synvinkel är dess genomförande mer effektivt ju mindre tid som läggs på det.
Således kommer vi till en definition av den maximalt möjliga effektiviteten för testaren ur projektets perspektiv — det är ett tillstånd där tiden för testning är noll. En allmän utmaning för alla testare är att detta tillstånd är omöjligt att uppnå.

Vad ska vi göra åt detta?

Slutsatserna är ganska uppenbara och har länge använts av många:

1. Utveckling och testning bör börja och avslutas nästan samtidigt (detta brukar vanligtvis hanteras av avdelningen QA). Den ideala situationen är när all funktionalitet som utvecklas är täckt av automatiserade tester i regressionstestning (och helst även pre-commit-tester) med hjälp av någon form av CI.
2. Ju fler funktioner ett projekt har (ju mer komplext det är), desto mer tid måste läggas på att kontrollera att den nya funktionaliteten inte har brutit den gamla. Därför, ju mer komplext projektet är, desto mer automatisering krävs för regressionstestning.
3. Varje gång vi släpper en bugg i produktion och användaren hittar den, måste vi lägga tid på att gå igenom projektets livscykel från punkt 1 (arbete med krav, i detta fall användarnas krav). Eftersom orsakerna till att en bugg missades i allmänhet är okända, återstår bara en väg för optimering — varje bugg som upptäckts av användarna måste inkluderas i regressionstestningen för att säkerställa att den inte dyker upp igen.

Källa: habr.com