Jak pracuje QA inženýr?

Jak pracuje QA inženýr? Seznamte se s oborem Quality Assurance

Petr Fifka je Senior QA Engineer a zakladatel společnosti Tredgate. V prostředí IT má již více než 10 let zkušeností, které předává studentům ČVUT a nyní se o ně podělí také na kurzu robot_dreams.

Co je to vlastně Quality Assurance?

Quality Assurance je odvětví v Software Testing, které má za úkol pomáhat zajišťovat kvalitu software/hardware při jeho vývoji. V rámci činností, které provádíme, nejsou pouze exekuční, které můžeme definovat jako testování, ale také procesní. Naším hlavním úkolem jako QA Engineerů je dosáhnout co nejvyšší kvality produktu. Náplní práce je například pomoc s definováním procesů, které zajišťují kvalitu dodávek v celém rozsahu vývoje – od myšlenky přes analýzu až po finální dodávku. 

Na projektu někdy vzniká mylný dojem, že kvalita je devíza zejména testera. Opak je ale pravdou. Tester sice v týmu ověřuje, zda-li je kvalita dodávané aplikace v souladu s kritérii, ale dodání kvalitního produktu je zodpovědností všech členů týmu. QA je tu přesně od toho aby toto pomáhalo zajišťovat.

Jaké jsou základní principy testování softwaru?

Tato otázka se dá pojmout z několika různých pohledů. Když vezmeme například popis dle ISTQB, což je globální testerská certifikační skupina. Ta rozlišuje 7 fundamentálních principů pro testování:

1. Testování ukazuje přítomnost defektů

2. Vyčerpávající testování je nemožné

3. Včasné testování

4. Shlukování defektů

5. Pesticidní paradox

6. Testování je závislé na kontextu

7. Falešná představa o neexistenci omylů

Shrnout bych to mohl tak, že testování vždy závisí na kontextu. Jinak přistoupíme k testování e-shopu, jinak k testování firmware kardiostimulátoru. Další důležitá věc je to, že kromě absolutně triviálních aplikací nikdy není možné otestovat vše a najít všechny chyby, a to ani při vynaložení obrovských zdrojů. Testování nám totiž ukazuje, jestli jsou chyby přítomny. Nedokáže ale opak, že chyby přítomny nejsou. Obecně můžeme o testování říci, že čím dříve v rámci životního cyklu software (SDLC) testujeme, tím je levnější a efektivnější. 

Vezměme si 2 extrémy v rámci stejného zdroje chyby (díra v dokumentaci):

1. Chyba se nalezne v zadávací dokumentaci před začátkem vývoje: oprava je na několik minut, případně se vyřeší na schůzce se zadavateli.

2. Chybu nalezne uživatel v hotové aplikaci: jednak zde hrozí ztráta uživatele. Oprava je ale mnohem náročnější. Uživatel musí kontaktovat podporu, ta věc ověří a pošle na další úroveň podpory, která získá potřebná data pro opravu a musí danou situaci nasimulovat. Následně probíhá validace, jestli z pohledu produktu je toto skutečně chyba, navrhuje se řešení, vyvíjí se řešení, testuje se…

Také je dobré vědět, že testování by nemělo být řešeno stále stejně. Pokud budeme mít stále stejnou strategii a scénáře. Software si „vyvine imunitu“ proti těmto testům a my budeme nacházet méně a méně chyb. K testům bychom měli mít dynamický přístup také proto, že pokud nalezneme chybu, je dost pravděpodobné, že se okolo nachází další. Chyby totiž dělají lidé a často, například při nepochopení jedné části zadávací dokumentace nebo při stresových situacích v oblasti, kterou vytvářejí, udělají více chyb.

Jaký typ testování byste doporučil pro webové aplikace?

Toto je ohromně obtížná otázka, na kterou univerzálně nelze odpovědět. Záleží na mnoha faktorech, jako například:

• O jakou aplikaci se jedná
• Kolik zdrojů je na testování
• Jaká kvalita se očekává
• Jak moc rychle chceme aplikaci vyvinout
• A další

Nejlepší strategií je vždy přizpůsobit přístup k testování požadavkům týmu. Obecně můžeme říct, že je dobré se řídit principy testovací pyramidy, která ve zkratce říká, že by se mělo testovat v pořadí:

1. Unit testování (provádí vývojáři)

2. Integrační testování

3. Systémové testování

4. Akceptační a UAT testování

Co se týče přístupu, doporučuji se řídit základními principy testování:

• Testovat v závislosti na kontextu
• Testovat staticky (revize dokumentace, dalších podkladů)
• Uváženě kombinovat jednotlivé testovací mechaniky
• Najít vyváženost mezi manuálními a automatickými testy

Co je to testování bílé skříňky a jak se liší od testování černé skříňky?

White-box testování neboli testování bílé skříňky je testování, kde máme k dispozici „střeva“ aplikace, vidíme dovnitř do procesů.

Black-box testování (testování černé skříňky) je naproti tomu přesný opak. Testujeme jen to, co vidí koncový uživatel. Dovnitř programu nevidíme.

Jaký je význam testování jednotek v procesu vývoje softwaru?

Unit (jednotkové) testování provádí zejména vývojáři aplikace a je to testování přímo v kódu. Jsou extrémně důležité, protože dokáží odhalit chyby, které by jinak při jiném přístupu byly těžce analyzovatelné. Také jejich exekuce nevyžaduje mnoho výpočetního výkonu a většinou bývají velmi rychlé. Účinné jsou však pouze v kombinaci s dalšími funkčními a nefunkčními přístupy k testování.

Jaký postup byste doporučil pro testování výkonu aplikace?

Sám nejsem expert na tento typ (performance, výkonnostní testování). Obecně však můžu říci, že je nutné být kompetentní k této problematice, projít například tréninkem a mentorováním ze strany zkušeného performance testera.

Jaké jsou nejčastější chyby v testování softwaru?

Na toto nemohu dát přesnou odpověď, žádnou takovou statistikou nedisponuji. Typů chyb je ohromné množství a ani si netroufám odhadovat, jaké jsou nejčastější. Obecně chyby můžeme rozdělit například do oblastí:

• Chyby v myšlence projektu
• Chyby v dokumentaci
• Funkční chyby 
• Nefunčkní chyby (výkon, přístupnost…)
• Konfigurační chyby

Pravděpodobnost, že některá nastane, je ale podobná. Samozřejmě, pokud je špatně myšlenka nebo dokumentace, je poté velice pravděpodobné, že se budou objevovat další funkční chyby.

Co je to automatizované testování a jak se liší od manuálního testování?

Na toto je velice jednoduchá odpověď. Automatizované testování provádí počítač, manuální člověk.

Jaké nástroje používáte pro testování softwaru?

Běžně pracuji s:

• Automatizačním frameworkem (Selenium, Cypress, Playwright)
• Test Management Tool (Jira, Zephyr, TestRail, Testlink)
• Nástroji pro zachytávání obrazu na webu (Plugin do Chrome Awesome Screenshot)
• Pro mobilní vývoj: Android Studio, adb, XCode
• Oracle SQL Developer pro testování databáze
• Postman pro API testování
• Swagger, Confluence pro dokumentaci
• Visual Studio Code, Intellij Idea pro vývoj automatizovaného kódu
• Devops nástroje: Jenkins, Github Actions
• Verzování v rámci Git, Github

Jaká je největší výzva v testování softwaru?

Tak jako hrát šachy nebo poker, je docela jednoduché se naučit testovat. Ovládnutí testování tak, abychom dodávali co nejlepší výsledky efektivně, je mnohem náročnější. 

Velkých výzev pro testování software vidím několik.

Retence (odchodovost) testerů je oproti jiným odvětvím IT velká. To způsobuje nedostatek seniorních inženýrů. Proč toto nastává? Často je totiž testování bráno jako taková pomyslná brána do IT. Člověk si jako tester odslouží rok, dva a následně pokračuje na jinou IT roli. Software testování se také moc často nevyučuje na českých školách (vím snad jen o VŠE). To má za důsledek to, že není mnoho absolventů, kteří se do QA/testování dostávají.

Více konkrétní výzvou pro testery je nutnost ovládat nejen hard-skills, ale také soft-skills. Velmi důležitá část testerské role je totiž komunikace, a to jak s technickými (vývojář, analytik), tak business rolemi (klient, projektový manažer). Nadání máme většinou na jednu z těchto oblastí a tu druhou se musíme doučit. 

Jednou z dalších výzev je také nedostatek času na testování. Svět se stále zrychluje, jsou zde požadavky na čím rychlejší vývoj. To vytváří tlak na všechny role ve vývoji. Pro nás testery to znamená nutnou adaptaci. Často se totiž stáváme takzvaným úzkým hrdlem. Zvláště u dlouhodobých projektů vzniká nutnost testovat nejen nové dodávky, ale také ty již dodané, abychom zabezpečili to, že se novou funkcionalitou nerozbije ta stará. Existují samozřejmě kroky, jak této výzvě čelit. Například právě automatizace testování, směřování doleva (testujeme dříve v procesu), změna procesů, přenesení části zodpovědnosti na jiné členy týmu atp.

Jaký je význam testování bezpečnosti v procesu vývoje softwaru?

Bezpečnostní (security) testování je extrémně důležité pro každou aplikaci. Snaží se pomocí různých metodik zjistit, jestli je aplikace odolná vůči různým formám útoku zvenčí. Samotné security testování je extrémně specializované a náročné. Existují samozřejmě nástroje, které nám s ním pomáhají. Obecně ale můžu říci, že pokud se někdo rozhodne dělat security testování, jedná se defacto o jiný obor v IT. Často se také najímají etičtí hackeři, kteří bezpečnost aplikace prověřují pomocí metod podobným skutečným útokům.

Jak se mění role QA v agilním vývoji?

V agilním týmu se role i požadavky na testera/QA Engineera často mění. Agilní týmy se často soustředí na dodávání malých částí aplikace/produktu v rychlých iteracích. Tester tedy často nemá dostatek času na plnohodnotné manuální testování a stává se úzkým hrdlem. Díky tomu, že týmy bývají relativně malé, není zde prostor na přílišnou specializaci testera na oblasti jako jsou: integrace, automatizace, security, nefunkční testování atp.

Z mých zkušeností se vyžaduje širší spektrum dovedností od testera. Často musí zvládnout všechny aspekty QA, stává se tzv. Full stack testerem. Alternativou je někdy také rozdělení rolí testera mezi více rolí v týmu. Setkal jsem se například s tím, že automatizace byla vytvářena vývojáři. Z toho všeho vyplývá, že pro nováčky je situace v agilních týmech složitá, protože v agilních týmech je často jen jeden tester a nemá potom jiného kolegu, na kterého se může obracet, který ho mentoruje, pomáhá se složitými úkoly.

Jakým způsobem byste zlepšil kvalitu testování v týmu?

To je otázka, na kterou kdybych měl univerzální odpověď, tak je ze mě boháč. Bohužel se na toto nedá odpovědět univerzálně. Každý tým má jiné výzvy, problémy, procesy. To, co funguje v jednom týmu, může v druhém způsobit škody.

Proto, když pomáhám jinému týmu zlepšit kvalitu, postupuji následovně:

• Nejdřív se seznámím s produktem a s procesy v týmu
• Následně zjišťuji, jaká je situace
• Analyzuji problém a diskutuji s členy týmu možnosti zlepšení
• Zavádíme změny a měříme jejich dopad

Skoro každý tým má něco společného. Nemá rád velké nepromyšlené změny. Pokud tedy chceme něco zlepšit, musí to především vycházet z týmových potřeb a nedělat takzvaný big boom.

Jaký postup byste doporučil pro správu chyb v procesu testování softwaru?

Toto za nás řeší Test Management nástroje, jako jsou pluginy do Jira (Zephyr, Xray), nebo samostatné nástroje, jako je TestRail. Tyto nástroje jsou většinou přednastaveny tak, aby vyhovovaly většině týmů. 

Z mých zkušeností můžu zmínit několik best practises, které mohou řídit životní cyklus chyb efektivně:

• Zodpovědnost za zavření bugu má vždy tester
• Tester má možnost přímého kontaktu vývojáře, ne jen prostředníka
• Prioritizace chyb je známá celému týmu a je konzistentní