Miro, nechci začínat banální otázkou, ale protože se bude celý rozhovor kolem QA točit, pojďme si říct, co QA znamená pro tebe.

Spousta lidí si myslí, že QA, což je zkratka pro Quality Assurance, rovná se testování. Ale to není pravda. QA je mnohem širší oblast, a testování je jen její dílčí část. Moje odpověď by tedy zněla: QA je strategie. Je to proces, jehož cílem je zajistit kvalitu v každé, a na to slovo dávám důraz, fázi vývoje.

Možná tedy ještě pojďme na úvod vyjasnit termíny QA Tester a QA Engineer. Jaký je mezi nimi rozdíl?

Označení QA Tester je za mě vlastně zkomolenina, kterou bych ze slovníku rád smazal a nahradil ji pozicí Tester. A teď pojďme vyjasnit rozdíl mezi Tester a QA Engineer: Tester má za úkol testovat podle připravených scénářů, tedy se podílí pouze na korektivní části celého procesu, kdežto QA Engineer řeší právě onu zmíněnou preventivní strategii. 

Nemáš pocit, že je QA oproti programování trochu opomíjené? 

Klient často nerozumí výhodám, které QA do procesu vývoje přináší. Vývojáři je ale zpravidla chápou a hodně tomu pomáhá, když s nimi spolupracujeme už na samém začátku projektu. Obě strany pak snáz vnímají vztah jako přínosný – a oběma jde o dobrý výsledek. Od vícero developerů jsem slyšel, že u opravování chyb se mohou naučit i víc, než u psaní samotné funkcionality.

Obecně zastávám názor, že QA by měl dělat každý v týmu, tedy designéři, vývojáři, ale i projektoví manažeři. Kvalita by zkrátka měla přicházet od každého, kdo se na projektu podílí, na QA Engineery by se nemělo spoléhat. My jsme pouze specialisté, kteří onu kvalitu hlídají.

A proč je tedy QA vůbec potřeba?

Protože je vývoj efektivnější a levnější. Opravovat chyby až na produkci je nejdražší, protože se developer musí zpětně zorientovat v kódu, což opět vede k riziku zanesení dalších chyb. Součástí naší práce je identifikovat potenciální problémy a poukazovat na rizika. Zjednodušeně řečeno: díky QA nemusí bug vůbec vzniknout. A právě proto by se QA do projektu mělo zapojit v samém začátku, kdy se definují featury, kdy se tvoří design… Už v této fázi nám hlavou běží, co a jak budeme testovat, čímž nás napadají otázky, které mohou pomoci celému procesu, a tedy projektu.

„Díky QA je vývoj efektivnější a levnější.“

Ale není to jen o zkušenostech z testování. QA Engineer by měl také z určité části reprezentovat koncového zákazníka, takže je na nás i například upozorňování, že je aplikace neintuitivní nebo jí chybí nějaká funkcionalita. Abych uvedl nějaký konkrétní příklad: QA Engineer například odchytí, že barvy nejsou zvolené správně, protože se aplikace stane nepoužitelnou pro barvoslepé.

Většinu aplikací vyvíjíme agilně, kdy je proces rozdělený do několika jednotek až desítek sprintů. QA Engineer se tedy zapojuje hned v samém začátku?

Ve Futured to tak je. Celý tým, který bude na projektu pracovat, se formuje hned v počátku, což nám dává šanci úzce a efektivně spolupracovat. 

Ty máš z předchozích firem zkušenost hlavně s vývojem webových aplikací, ve Futured s týmem se zaměřujete primárně na mobilní aplikace. Jaké rozdíly vnímáš?

Nejsou nijak velké. Procesy se dají snadno přenášet, ale v každé firmě se musí maličko upravovat. Když to úplně zjednoduším, rozdíl vnímám hlavně v tom, na co je třeba se soustředit. U webů je to třeba rozlišení obrazovky/monitoru nebo různé prohlížeče. U mobilních aplikací zase více řešíme verze operačních systémů. Zásadněji vnímám rozdíl mezi produktovým a projektovým vývojem.

Pojďme se u toho zastavit…

Pokud má firma vlastní produkt, snaží se ho pokrýt automatizovanými testy, které, jak už název napovídá, automatizují interakce s aplikací a porovnávají aktuální stav s očekávaným. Takové testy se píší kontinuálně přímo pro danou aplikaci, aby se tyto interakce nemusely následně dělat manuálně. 

V agenturním světě se automatizované testy používají spíše výjimečně, protože v nich klienti nevidí přínos. A já tomu do jisté míry rozumím, chtějí zkrátka hotovou aplikaci. A ano, je pravda, že připravit sadu automatizovaných testů může trvat dlouho, a tedy stát klienta více peněz… Nicméně u dlouhodobých a komplexnějších projektů je to dobrá investice, protože se při dalším a dalším vývoji nemusí daná funkcionalita opakovaně testovat.

Umí vlastně naši QA Engineeři programovat? A je to vůbec cílem?

Ono záleží na tom, co si představíš pod pojmem programování. Pro některé lidi je programování i schopnost napsat zmíněný automatizovaný test, a to by každý QA Engineer umět měl. Pokud tím myslíš schopnost programovat aplikaci, není to rozhodně podmínka. Ale osvojit si alespoň základy programování je určitě výhoda, například si díky tomu můžeš přečíst kód, což je vlastně statické testování.

Jaké typy testů ve Futured používáme? 

QA Engineeři v zásadě postupují ve třech krocích: Nejprve uděláme analýzu. Na jejím základě připravíme plán a prioritizaci testů. Podle této strategie následně testujeme. 

Obecně pracujeme s několika typy testů, z nichž každý má svůj čas a místo. Můžu zmínit ty nejzákladnější.

Sanity test je základní ověření, že má vůbec smysl nový kód testovat více do hloubky. Systémové testy nám pomáhají, zjednodušeně řečeno, testovat, že systém dělá to, co dělat má. Integrační testy pak ověřují, že dvě aplikace (například front-end a back-end) vyvíjené nezávislé na sobě spolu dokáží komunikovat. API testy zase testují back-end.

Během vývoje pak píšeme regresní testy. Ty se nejčastěji provádí před samotným releasem nebo (alespoň část z nich) po velké úpravě kódu. Pomáhají nám zvalidovat, že nová funkcionalita nerozbila něco, co už bylo dříve vyvinuto a otestováno.

Jaký nástroj v QA týmu nejvíce používáte?

Hodně využíváme Mobile Toolkit, což je nástroj, jehož autorem je předchozí QA Lead Adam. Významně nám ulehčuje práci. Dokáže například interagovat s připojeným telefonem a vytvořit screenshot obrazovky, nahrávat videa, nastavovat dark mode a daleko víc. To vše pouhým vypsáním konkrétního příkazu v konzoli. 

Dále můžu zmínit třeba Postman, který se používá na testování API.

Dá se vlastně říct, zda je náročnější testovat Android, nebo iOS? 

Po stránce funkcionalit moc velký rozdíl nevnímám. Nicméně Android má hodně nástaveb a běží na telefonech spousty různých výrobců, což samozřejmě znamená větší riziko bugů. Člověk musí být víc ve střehu. A samozřejmě může být zprvu náročnější testovat iOS, pokud dotyčný sám používá Android, a naopak.

„Produkt nelze otestovat na 100 %. Nejdůležitější je prioritizovat.“

Jak vnímáš kvalitně otestovaný produkt? 

Záleží na komplexitě produktu, ale obecně platí, že nelze produkt otestovat na 100 %, to bys ho musela podrobovat testům donekonečna. Nejdůležitější je prioritizovat. Kvalitně otestovaný produkt by vždy měl začít testy, které se zaměřují na nejpoužívanější funkcionalitu aplikace, pokračovat s těmi méně používanými a marginální nechat na konec. Pokud aplikace ještě nemá žádné zákazníky, musíme předpokládat a identifikovat klíčové featury.

Co vnímáš jako největší úskalí QA? A co si myslíš, že je na něm naopak lákavé?

Mě na QA baví komplexita oboru. Můžeš se donekonečna učit. Ale uvědomuju si, že je to zároveň právě ono úskalí, protože pokud se člověk nevzdělává dostatečně rychle, ztrácí hodnotu. Výhodou agenturní práce je i to, že si vyzkoušíš různé obory, jednou pracuješ v oblasti kreativity transportu, jindy v gastro segmentu, pak řešíš trendy v oblasti bankovnictví. 

Pokud nás čte někdo, koho QA láká, jak začít? Zmiňoval jsi, že alfou a omegou dobrého QA jsou zkušenosti. Ty ti na začátku chybí.

Zkušenosti jsou důležité, ale můžeš je získávat v zásadě docela rychle. Už jakmile objevíš první bug, dává ti to povědomí o tom, co za problém může příště nastat. Obecně může být jednodušší začít jako Tester a postupně se vypracovat, případně být rovnou Junior QA Engineer, pokud prostředí umožňuje se od někoho učit. To byla třeba moje cesta. 

„Dobrý QA Engineer musí mít skvělé analytické myšlení.“

A může QA Engineera dělat úplně každý?

Ne. Dobrý QA Engineer musí mít skvělé analytické myšlení. Třeba mě na pohovorech nejvíc zajímá, jak člověk nad určitým problémem přemýšlí. Když si povídám s juniorem, nezajímá mě, jak by otestoval aplikaci, ale ptám se ho, jak by otestoval třeba propisku nebo papír. Nad něčím takovým člověk normálně nepřemýšlí… Jsou to zároveň otázky, na které nejsou správné odpovědi, ale hodně člověka odkopou. Za mě platí, že je lepší najmout juniornějšího člověka, který má analytické myšlení a chuť se učit a zlepšovat, než zkušenějšího QA Engineera, kterému tyhle vlastnosti chybí.

Jaké QA trendy sleduješ?

Best practices jsou již víceméně definované, jen občas přijde nějaká „revoluce”, způsob, jak něco dělat jinak. Spíš sleduju vývoj technologií, operačních systémů a aktualizace frameworků.

Kam konkrétně si chodíš pro inspiraci? 

Hlavně na LinkedIn, kde sleduju velká jména QA světa, konkrétně Filipa Hrice, Radka Kitnera nebo Simona Stewarta. Sleduju taky stránky Tesena, [pro:]TEST!, Ministry of Testing, Cypress.io nebo třeba KRONE. A pravidelně navštěvuji weby o konkrétním automation frameworku CodeceptJS, Selenium a Cypress.

Důležitým zdrojem inspirace jsou po mě meet-upy.

Tip: Přečtěte si Mirův článek, ve kterém se zamýšlí, zda má vůbec ještě smysl chodit na odborné konference. A přidává seznam 7 věcí, které byste před koupí vstupenky měli zvážit.

Máš nějakou osobnost, ke které v oboru opravdu vzhlížíš?

Mně se vždycky osvědčilo najít si vzor v práci spíš než mít internetovou personu, se kterou se nikdy nesetkám. Nechci znít pateticky, ale vzorem jsou mi kolegové. Přestože jsem v rámci pomyslné hierarchie z pozice Leada výš, mám v týmu lidi, od kterých se mám co (na)učit. 

Když jsme u týmu, jaké jsou s ním tvoje plány? 

Rád bych rozvíjel základy automatizace, a to u aplikací i webů. Rád bych také vedl tým k tomu, aby sami sebe víc vedli v profesním růstu. Mým přáním je, abych byl v roli Leada pro tým spíše mentor/kouč, který je zastupuje v klíčových celofiremních otázkách. 

Hodně se zajímáš o rozvoj celé QA komunity. Založil si vlastní meet-up No Bugs Allowed, angažoval jsi se v Czechitas… Co pro tebe komunita znamená?

Naplňuje mě, když můžu předávat zkušenosti. Vědět, že mého názoru si někdo cení mi zkrátka dělá radost. A vlastní meet-up jsem založil z možná trochu sobeckých důvodů… Chtěl jsem vytvořit vlastní komunitu, která je do QA zapálená a se kterou můžeme sdílet úspěchy i nezdary. 

Až nedávno jsem se o tobě dozvěděla, že jsi se po škole odstěhoval z malé vesničky u Břeclavi do Brightonu, co jsi tam dělal a co ti to dalo?

Není za tím nic poetického. Po škole jsem měl špatné období a potřeboval jsem vypadnout. Byl jsem tehdy plachý introvert, neuměl jsem pořádně anglicky. Odstěhoval jsem se z mama hotelu a najednou jsem se o sebe musel postarat. Pracoval jsem tehdy v restauraci a hodně jsem vyrostl. Naučil jsem se třeba otevřeně komunikovat nebo vytvářet hlubší vztahy. Věřím, že bez téhle zkušenosti bych se do Brna nepřestěhoval a QA Lead by se ze mě nikdy nestal.  Teď už jsi sedm let v Brně, kam dál?

Musím říct, že jsem v Brně vážně spokojený. Jiné kultury už jsem si otestoval až dost.

––

PS: Miro pravidelně přispívá do našich měsíčních #AppNews, ve kterých sdílíme zkušenosti a sledujeme trendy a novinky, abyste vy nemuseli.  ⁠  ⁠

––

Rosteme a neustále hledáme nové kolegy. Podívejte se na seznam otevřených pozic a ozvěte se Simoně, abyste se pobavili o možnostech spolupráce: [email protected] & +420 735 040 126