Uvod
Dobar dan, članovi Habr. Nedavno sam rešavao testni zadatak za poziciju QA Lead u jednoj fintech firmi. Prvi zadatak, sastaviti test plan sa potpunom kontrolnom listom i primerima test slučajeva za proveru električnog čajnika, rešava se trivijalno:
Teško je smisliti bolji test plan sa potpunom kontrolnom listom.
A druga deo se pokazao kao pitanje: "Postoje li neki problemi koji su zajednički svim testerima, a otežavaju efikasniji rad?"
Prvo što mi je palo na pamet: nabrojati sve uočljive probleme sa kojima sam se susretao prilikom testiranja, isključiti sitnice, a ostalo generalizovati. Međutim, brzo sam shvatio da induktivna metoda neće odgovoriti na pitanje koje se odnosi ne na "sve", već, u najboljem slučaju, samo na "većinu" testera. Zato sam odlučio da pristupim iz druge strane, deduktivne, i evo šta je ispalo.
Definicije
Prvo što obično radim kada rešavam novi zadatak jeste da pokušam da shvatim o čemu se zapravo radi, a za to je potrebno razumeti značenje reči kojima je postavljen. Ključne reči koje treba razjasniti su sledeće:
- težava
- tester
- rad testera
- efikasnost rada testera
Hajde da se obratimo Wikipediji i zdravom razumu:
(starogrčki πρόβλημα) u širokom smislu — složen teorijski ili praktični problem koji zahteva proučavanje, rešavanje; u nauci — kontradiktorna situacija koja se pojavljuje u obliku suprotnih stavova u objašnjenju nekih fenomena, objekata, procesa i zahteva adekvatnu teoriju za njegovo rešavanje; u životu se problem formuliše u jasnom obliku za ljude kao "znam šta, ne znam kako", tj. poznato je šta treba da se postigne, ali nije poznato kako to uraditi. Poteklo iz kasnolatinskog problēma, iz grčkog πρόβλημα „baciti unapred, postavljeno unapred“; od προβάλλω „baciti unapred, izložiti pred sobom; optužiti“.
Nema mnogo smisla, suštinski, "problem" = "bilo šta što treba razjasniti".
— specialist (we won't divide into types, as we are interested in all testers) participating in the testing of a component or system, whose activity results in:
— a set of activities related to testing.
(Latin. effectivus) — the ratio between the achieved result and the resources used (:2015).
— a consequence of a chain (series) of actions (outcome) or events, expressed qualitatively or quantitatively. Possible outcomes include advantage, inconvenience, benefit, loss, value, and victory.
Like with the 'problem', the meaning is little: something that was produced as a result of work.
— a quantitatively measurable capability to perform some activity of a person or people; conditions that allow obtaining a desired result through certain transformations. A tester is a person, and according to the theory of vital resources, each person possesses four economic assets:
monetary funds (income) — a renewable resource;
energy (vital force) — a partially renewable resource;
time — a fixed resource and fundamentally non-renewable;
knowledge (information) — a renewable resource, which is part of human capital that can both increase and decrease..
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 in work is not spent, but reduces the expenditures of the only fundamentally non-renewable resource of the tester — their time.
Solution
So, we are looking for global problems of testers that decrease the effectiveness of their work.
The most significant resource that is spent on a tester's work is their time (the others can somehow be related to it), and for us to talk about the correct calculation of effectiveness, we need to relate results to time.
Zato si poglejmo sistem, katerega vzdržnost zagotavlja testni inženir s svojim delom. Takšna sistem je projekt, v katerega ekipi pripada testni inženir. Življenjski cikel projekta lahko grobo predstavimo s takšnim algoritmom:
- Delo s zahtevami
- Oblikovanje tehnične specifikacije
- Razvoj
- Testiranje
- Izid v produkcijo
- Podpora (goto točka 1)
Celoten projekt se lahko rekurzivno razdeli na podprojekte (funkcionalnosti), ki delijo enak življenjski ciklus.
Z vidika projekta je učinkovitost njegove realizacije večja, kot manj časa je porabljenega zanj.
Tako pridemo do definicije maksimalne možne učinkovitosti testnega inženirja z vidika projekta — to je stanje projekta, ko je čas za testiranje enak nič. Skupna težava za vse testne inženirje pa je, da je dosego tega časa nemogoče.
Kaj narediti glede tega?
Zaključki so povsem očitni in že dolgo uporabljeni:
- Razvoj in testiranje bi se morala začeti in končati praktično hkrati (to obično upravlja oddelek ). Idealna možnost je, da je vsa razvita funkcionalnost ob trenutku pripravljenosti že pokrita z avtomatskimi testi, organiziranimi v regresijsko (in po možnosti pred-commit) testiranje s pomočjo nekega .
- Več kot je funkcionalnosti v projektu (kar ga bolj zaplete), več časa bo treba porabiti za preverjanje, da nova funkcionalnost ni pokvarila stare. Tako velja, da bolj kot je projekt zapleten — več avtomatizacije je potrebne za .
- Vsakič, ko spustimo napako v produkcijo in jo uporabnik odkrije, — moramo porabiti dodatni čas za prehod skozi življenjski cikel projekta, začenši s točko 1 (Delo s zahtevami, v tem primeru, uporabnikov). Ker so razlogi za spustitev napake v splošnem neznani, nam ostane le ena pot optimizacije — vsaka napaka, ki jo najdejo uporabniki, mora biti vključena v regresijsko testiranje, da smo prepričani, da se ne bo ponovno pojavila.
Izvor: habr.com
