úvod
Ahoj uživatelé Habru. Nedávno jsem dokončil testovací úkol pro pozici QA Lead ve fintech společnosti. První úkol, vytvoření testovacího plánu s kompletním kontrolním seznamem a příklady testovacích případů pro testování rychlovarné konvice, byl triviální:
Je těžké přijít s lepším testovacím plánem s kompletním kontrolním seznamem.
Druhá část se však ukázala být otázkou: „Existují nějaké problémy společné všem testerům, které jim brání v efektivnější práci?“
První věc, která mě napadla, bylo vyjmenovat všechny více či méně znatelné problémy, na které jsem se během testování narazil, vyřadit ty triviální a zbytek zobecnit. Rychle jsem si ale uvědomil, že induktivní metoda by odpověděla na otázku, která se nevztahuje na „všechny“, ale v nejlepším případě jen na „většinu“ testerů. Rozhodl jsem se k tomu tedy přistupovat z jiného, deduktivního úhlu pohledu, a toto jsem vymyslel.
Definice
První věc, kterou obvykle udělám při řešení nového problému, je snaha pochopit, o co jde, a k tomu potřebuji pochopit význam použitých slov. Klíčová slova, kterým je třeba porozumět, jsou:
- problém
- tester
- práce testera
- výkon testera
Obraťme se na Wikipedii a selský rozum:
(Starořecky: πρόβλημα) v širokém smyslu - složitá teoretická nebo praktická otázka, která vyžaduje studium a řešení; ve vědě - rozporuplná situace, která se projevuje ve formě protichůdných pozic při vysvětlování některých jevů, objektů, procesů a vyžaduje pro své řešení adekvátní teorii; v životě je problém formulován způsobem, který je lidem srozumitelný, „vím co, nevím jak“, tj. je známo, čeho je třeba dosáhnout, ale není známo, jak to udělat. Pochází z pozdně latinského problēma, z řeckého πρόβλημα „vržen vpřed, postaven před sebe“; z προβάλλω „vrhnout vpřed, postavit před sebe; obvinit“.
To moc nedává smysl, v podstatě „problém“ = „cokoli, s čím je třeba se vypořádat“.
— specialista (nebudeme rozlišovat mezi typy, protože nás zajímají všichni testeři), který se podílí na testování komponenty nebo systému, jehož výsledkem práce je:
— soubor činností souvisejících s testováním.
(latinsky: effectivus) - poměr mezi dosaženým výsledkem a vynaloženými zdroji (: 2015).
— důsledek (výsledek) řetězce (posloupnosti) činů nebo událostí, vyjádřený kvalitativně nebo kvantitativně. Mezi možné výsledky patří výhoda, nevýhoda, zisk, ztráta, hodnota a vítězství.
Stejně jako u „problému“ zde není velký význam: jde o něco, co vyplynulo z práce.
— kvantitativně měřená schopnost vykonávat jakoukoli činnost osobou nebo lidmi; podmínky, které umožňují dosáhnout požadovaného výsledku prostřednictvím určitých transformací. Tester je lidská bytost a podle teorie životních zdrojů má každý člověk čtyři ekonomická aktiva:
hotovost (příjem) je obnovitelný zdroj;
energie (vitální síla) je částečně obnovitelný zdroj;
čas je neměnný a v zásadě neobnovitelný zdroj;
znalosti (informace) jsou obnovitelným zdrojem; jsou součástí lidského kapitálu, která může jak růst, tak i být zničena.
Rád bych upozornil, že definice efektivity v našem případě není zcela přesná, protože čím více znalostí využíváme, tím nižší je efektivita. Proto bych efektivitu předefinoval jako „poměr mezi dosaženým výsledkem a vynaloženými zdroji“. Pak je vše správně: znalosti se při práci neplýtvají, ale snižují výdaje na jediný zásadně neobnovitelný zdroj testera – jeho čas.
rozhodnutí
Hledáme tedy globální problémy testerů, které snižují efektivitu jejich práce.
Nejvýznamnějším zdrojem vynaloženým na práci testera je jeho čas (další zdroje k němu lze tak či onak připsat), a abychom mohli hovořit o správném výpočtu efektivity, musí být výsledek také vztažen k času.
Abychom to mohli udělat, uvažujme systém, jehož životaschopnost je zajištěna prací testera. Takový systém je projekt, jehož tým zahrnuje testera. Životní cyklus projektu lze zhruba znázornit následujícím algoritmem:
- Práce s požadavky
- Tvorba technických specifikací
- Vývoj
- Testování
- Uvedení do produkce
- Podpora (přejděte na str. 1)
V tomto případě lze celý projekt rekurzivně rozdělit na dílčí projekty (funkce) se stejným životním cyklem.
Z pohledu projektu platí, že čím méně času se na projektu stráví, tím větší je jeho efektivita.
Dostáváme se tedy k definici maximální možné efektivity testeru z pohledu projektu: jedná se o stav projektu, kdy je čas testování nulový. A společným problémem všech testerů je nemožnost tohoto času dosáhnout.
Jak se s tím vypořádat?
Závěry jsou celkem zřejmé a mnozí je používají již dlouhou dobu:
- Vývoj a testování by měly začít a skončit téměř současně (obvykle to provádí oddělení Ideální možností je, když je veškerá vyvíjená funkcionalita v době, kdy je hotová, již pokryta automatizovanými testy, organizovanými do regresního (a pokud možno i pre-commit) testování s využitím nějakého druhu .
- Čím více funkcí projekt má (čím je složitější), tím více času bude nutné věnovat kontrole, zda nová funkcionalita nenaruší tu starou. Čím je tedy projekt složitější, tím více automatizace je potřeba. .
- Pokaždé, když necháme chybu projít do produkčního prostředí a uživatel ji najde, musíme strávit další čas procházením životního cyklu projektu, počínaje krokem 1 (práce s požadavky, v tomto případě s uživatelskými požadavky). Vzhledem k tomu, že důvody pro vynechání chyby jsou obecně neznámé, máme pouze jednu možnost optimalizace: každá chyba nalezená uživateli by měla být zahrnuta do regresního testování, aby se zajistilo, že se znovu neobjeví.
Zdroj: www.habr.com
