Introduktion
Goddag, Habr-venner. Jeg arbejdede for nylig på en testopgave til en QA Lead stilling for et fintech-firma. Den første opgave var at lave en testplan med en komplet tjekliste og eksempler på test cases for at teste en el-kedel, og dette er en triviel opgave at løse:
Det er svært at komme op med en bedre testplan med en komplet tjekliste.
Men den anden del viste sig at være spørgsmålet: "Er der nogle problemer, der er fælles for alle testere, som hindrer dem i at arbejde mere effektivt?"
Det første, jeg kom på, var at liste alle mere eller mindre mærkbare problemer, jeg stødt på under testningen, sortere småtingene fra og sammenfatte resten. Men jeg indså hurtigt, at den induktive metode ville besvare et spørgsmål, der ikke gælder for "alle", men højst for "de fleste" testere. Derfor besluttede jeg at tage en anden tilgang, den deduktive, og her er hvad jeg kom frem til.
Definitioner
Det første, jeg plejer at gøre, når jeg står overfor en ny opgave, er at forsøge at forstå, hvad den overhovedet handler om, og for det skal jeg forstå betydningen af de ord, den er formuleret med. De nøgleord, jeg skal forstå, er følgende:
- problemet
- tester
- testerens arbejde
- testerens arbejdseffektivitet
Lad os se på Wikipedia og sund fornuft:
(fra gammel græ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 modstridende positioner i forklaringen af bestemte fænomener, objekter, processer og kræver en passende teori for at løse den; i livet formuleres et problem i en forståelig for mennesket form som "jeg ved hvad, men ved ikke hvordan", det vil sige, det er klart, hvad der skal opnås, men det er uklart, hvordan det skal gøres. Det stammer fra sen-latin problēma, fra græsk πρόβλημα "kastet frem, sat foran"; fra προβάλλω "kaste frem, stille foran; beskylde".
Der er ikke meget mening, i bund og grund er "problem" = "hvad som helst, som man skal finde ud af".
— specialist (we won’t differentiate the types, as we are interested in all testers), participating in the testing of a component or system, the result of which is:
— a set of activities related to testing.
(from Latin effectivus) — the ratio between the achieved result and the resources used (:2015).
— the consequence of a chain (series) of actions (outcome) or events, expressed qualitatively or quantitatively. Possible results include advantage, inconvenience, benefit, loss, value, and victory.
As with the “problem,” there is little meaning: something that came out as a result of the work.
— quantitatively measurable capability of a person or people to perform some activity; conditions that allow one to achieve the desired outcome through certain transformations. A tester is a person, and according to the theory of vital resources, every person possesses four economic assets:
financial resources (income) — a renewable resource;
energy (life force) — a partially renewable resource;
time — a fixed and fundamentally non-renewable resource;
knowledge (information) — a renewable resource, this is part of human capital that can both accumulate and decay..
I want to note that the definition of effectiveness in our case is not entirely correct, as the more knowledge we use, the lower the effectiveness becomes. Therefore, I would redefine effectiveness as “the ratio between the achieved result and the resources spent.” Then everything is correct: knowledge at work does not deplete, but it reduces the only fundamentally non-renewable resource of the tester — their time.
Løsning
So, we are looking for global problems facing testers that worsen their work effectiveness.
The most significant resource spent on a tester's work is their time (the others can be brought back to it in one way or another), and in order for us to talk about a correct calculation of effectiveness, the result must also be related to time.
Lad os se på et system, hvis levedygtighed testeren sikrer gennem sit arbejde. Et sådant system er et projekt, hvor en tester er en del af teamet. Projektets livscyklus kan groft beskrives i følgende algoritme:
- Arbejdet med kravene
- Udformning af tekniske specifikationer
- Udvikling
- Testning
- Udgivelse i produktion
- Support (gå til p.1)
Hele projektet kan rekursivt opdeles i delprojekter (funktioner), som har den samme livscyklus.
Set fra projektets synspunkt, jo mindre tid der bruges på det, desto mere effektivt er dets gennemførelse.
Hermed kommer vi til definitionen af den maksimalt mulige effektivitet for testeren set fra projektets perspektiv — dette er den tilstand, hvor tiden brugt på testning er lig med nul. En generel udfordring for alle testere er, at det er umuligt at opnå denne tid.
Hvad kan vi gøre ved det?
Konklusionerne er ret åbenlyse og anvendes ofte af mange:
- Udvikling og testning skal starte og slutte næsten samtidigt (dette håndteres normalt af QA-afdelingen ). Den ideelle løsning er, når al den функционалitet, der udvikles, allerede er dækket af automatiserede tests, organiseret i regressions- (og om muligt også pre-commit) testning ved hjælp af en eller anden .
- Jo flere funktioner der er i projektet (jo mere komplekst det er), jo mere tid skal der bruges på at kontrollere, at den nye funktionalitet ikke har brudt den gamle. Heraf følger, at jo mere komplekst projektet er, desto mere automatisering kræves der til .
- Hver gang vi lader en fejl slippe igennem til produktion, og brugeren opdager den, må vi bruge ekstra tid på at gå igennem projektets livscyklus fra punkt 1 (Arbejdet med kravene, i dette tilfælde brugernes). Da årsagerne til at fejlen blev overset normalt er ukendte, har vi kun én vej til optimering — hver fejl, der findes af brugerne, skal inkluderes i regressionstestningen, for at vi kan være sikre på, at den ikke vises igen.
Kilde: habr.com
