Úvod
Dobrý den, Habráci. Nedávno jsem řešil testovací úkol na pozici QA Lead pro jednu fintech společnost. První úkol, sestavit testovací plán se kompletním kontrolním seznamem a příklady testovacích případů pro ověření elektrického varného konvice, je triviální.
Těžko vymyslet lepší testovací plán s kompletním kontrolním seznamem.
Druhá část však byla otázkou: „Existují nějaké problémy, které jsou společné pro všechny testery a brání jim pracovat efektivněji?“
První, co mě napadlo: vypsat všechny více či méně znatelné problémy, se kterými jsem se setkal při testování, odpustit drobnosti a zbytek shrnout. Ale brzy jsem si uvědomil, že induktivní metoda odpoví na otázku, která se vztahuje spíše ne k „všem“, ale maximálně k „většině“ testerů. Tak jsem se rozhodl přistoupit k problému deduktivně, a tady je, co vzniklo.
Definice
První, co obvykle dělám, když řeším nový úkol, je pokusit se pochopit, o čem vůbec je, a k tomu musím pochopit smysl slov, kterými je formulován. Klíčová slova, na která se musím zaměřit, jsou následující:
- problém
- tester
- práce testera
- efektivita práce testera
Odkryjme Wikipedii a zdravý rozum:
(starověká řečtina πρόβλημα) v širším smyslu – složitá teoretická nebo praktická otázka, která vyžaduje studium, vyřešení; ve vědě – rozporuplná situace, která se objevuje v podobě protichůdných pozic v vysvětlení jakýchkoli jevů, objektů, procesů a vyžaduje adekvátní teorii pro její řešení; v životě se problém formuluje srozumitelně pro lidi jako „vím co, nevím jak“, to znamená, že je známo, co je potřeba získat, ale neví se, jak to udělat. Pochází z pozdní latiny problēma, z řeckého πρόβλημα „hodit vpřed, vystavit dopředu“; od προβάλλω „házet vpřed, vystavovat před sebou; obviňovat“.
Smyslu mnoho není, v podstatě „problém“ = „cokoliv, s čím je třeba se vypořádat“.
— specialista (nebudeme je dělit podle typů, protože nás zajímají všichni testeri) účastnící se testování komponenty nebo systému, jehož činností je:
— soubor opatření vztahujících se k testování.
(lat. effectivus) — poměr mezi dosaženým výsledkem a použitými zdroji (:2015).
— důsledek řetězce (série) činností (výsledek) nebo událostí, vyjádřených kvalitativně nebo kvantitativně. Možné výsledky zahrnují výhodu, nepohodlí, zisk, ztrátu, hodnotu a vítězství.
Jak je tomu u "problému", málo přidává na významu: něco, co vzniklo na konci práce.
— kvantitativně měřitelná schopnost vykonávat nějakou činnost člověka nebo lidí; podmínky, které umožňují pomocí určitých proměn získat požadovaný výsledek. Tester je člověk, a podle teorie vitálních zdrojů je každý člověk vlastníkem čtyř ekonomických aktiv:
peněžních prostředků (příjem) — obnovitelný zdroj;
energie (životní síla) — částečně obnovitelný zdroj;
času — fixní a principiálně neobnovitelný zdroj;
znalostí (informací) — obnovitelný zdroj, což je část lidského kapitálu, která může jak růst, tak klesat..
Chci poznamenat, že definice účinnosti v našem případě není zcela přesná, protože čím více znalostí používáme, tím nižší je efektivita. Proto bych redefinoval efektivitu 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 nemrhají, ale snižují výdaje jediného principiálně neobnovitelného zdroje testera — jeho času.
Řešení
Tak hledáme globální problémy testerů, které zhoršují efektivitu jejich práce.
Nejdůležitějším zdrojem, který se při práci testera vynakládá, je jeho čas (ostatní zdroje jsou na něj v tomto ohledu nějakým způsobem přivoditelné), a abychom mohli mluvit o správném výpočtu efektivity, je také potřeba přizpůsobit výsledek času.
Pro tento účel se podívejme na systém, jehož životaschopnost zajišťuje tester svou prací. Takovým systémem je projekt, do jehož týmu patří tester. Životní cyklus projektu lze zhruba představit následujícím způsobem:
- Práce s požadavky
- Vytvoření technické specifikace
- Vývoj
- Testování
- Vydání do výroby
- Podpora (viz bod 1)
Celý projekt lze přitom rekurzivně rozdělit na podsystémy (funkce) se stejným životním cyklem.
Z pohledu projektu je efektivita jeho realizace tím větší, čím méně času na něj bylo vynaloženo.
Takže docházíme k definici maximální možné efektivity testera z pohledu projektu — je to takový stav projektu, kdy čas na testování je nulový. A celkovým problémem pro všechny testery je nemožnost tohoto času dosáhnout.
Co s tím?
Závěry jsou zcela zřejmé a mnozí je již dlouho používají:
- Vývoj a testování by měly začínat a končit prakticky současně (tím se obvykle zabývá oddělení ). Ideální variantou je, když je veškerá vyvíjená funkčnost k okamžiku připravenosti již pokryta automatizovanými testy, organizovanými v regresním (a pokud možno i pre-commit) testování pomocí nějakého .
- Čím více funkcí projekt obsahuje (čím je složitější), tím více času bude třeba věnovat kontrole, že nová funkčnost neporušila tu starou. Odtud platí, že čím složitější projekt je, tím více vyžaduje automatizace .
- Každýkrát, když propustíme chybu do produkce a uživatel ji najde, musíme vynaložit další čas na procházení životním cyklem projektu od bodu 1 (Práce s požadavky, v tomto případě uživatelů). Jelikož příčiny propustění chyby jsou v obecném případě neznámé, zbývá nám pouze jedna cesta k optimalizaci — každá chyba nalezená uživateli by měla být zahrnuta do regresního testování, abychom si byli jisti, že se už více neobjeví.
Zdroj: habr.com
