Samozřejmě, občas si stačí aplikaci takzvaně “proklikat” (odborně se tomu říká exploratory testing) a nesrovnalosti se najdou hned. Skutečné záruky kvality se nicméně dosáhne pouze kombinací různých metodik testování, systematickým přístupem kombinujícím know how a zkušenost, pečlivostí a vůbec dobře odvedenou prací.

Široká veřejnost často automaticky počítá s bezchybnou aplikací, takže nemůžeme očekávat, že pozici testera pochopí. Ale aplikace se rozhodně bezchybná nerodí. QA tým je zodpovědný za finální produkt, ať už si to uvědomuje, nebo ne.

Aplikace ŠKODA OneApp, Vítěz v soutěži IT Projekt roku 2017

Co pro nás vůbec QA znamená? Chceme, aby byla aplikace dokonalá ve všech směrech a aby uživatelům přinášela opravdovou přidanou hodnotu, aby ji skutečně milovali. Důležitá je tedy funkčnost celé aplikace. Zjednodušeně; aby aplikace dělala to, co dělat má. A hlavně, aby to dělala bezproblémově. Kromě toho se také zaměřujeme na detaily; prvky posunuté o jeden pixel, barvy, které jemně neodpovídají grafickému návrhu a další maličkosti.

V eManu začíná testovací proces už v prvních fázích projektu. Tester, který má daný projekt přiřazený, je opravdu důležitým článkem týmu. Musí velice pečlivě a detailně znát daný projekt, většinou studiem různých druhů specifikací (wire-framy, grafické specifikace, funkční specifikace, use casy a i nějaké ty grafy v UML). Už znalost specifikace nám umožňuje nalézat první chyby, které mohou ušetřit mnoho spálených hodin v další fázích vývoje.

Ještě než se dostaneme k samotnému testování, je dobré se zamyslet nad celým systémem a sepsat si jednotlivé test casy (TCs). Zaměření TCs závisí na velikosti projektu, ale ve výsledku je důležité pokrýt základní funkce SW a různé edge casy. Například kvůli zastupitelnosti nebo rychlejšímu zapojení dalšího člena týmu do projektu. Jak jsme zmínili, hodně často sice testujeme explorativně, ale například i kvůli uživatelským testům je nutné nezapomínat TCs vůbec psát.

Pokud je projekt vhodný, počítáme s dlouhodobým vývojem nebo se dopředu počítá s častými updaty aplikace – časté sanity, smoke a regresní testy – přepíšeme TCs vhodné pro manuální testy na automatizované testy (v tuto chvíli probíhá testování Androidu, API a webu). Všechny tři zmíněné oblasti máme integrované v GitLabu.

• Android: Android Studio, Java a Kotlin
• API: jednotlivé testy píšeme v Ruby a pracujeme na vlastním testovacím prostředí, které pokryje naše požadavky
• WEB: Selenium + Capybara a Ruby

Další fází už je samotné testování. Samozřejmě, není to všechno takto jednoduché, ale pro představu to stačí. Aplikaci testujeme jak manuálně, tak pomocí automatizovaných testů. Právě proto, že automatizované testy mají z dlouhodobého hlediska nízkou schopnost odhalení nových chyb, testujeme i explorativně. To bývá právě ta nejzajímavější část testování, která zároveň odhalí nejvíce chyb (pokud ovšem nemáte automatizovanými testy pokrytou aplikaci na 100 %). U explorativního testování se tester musí znovu zamyslet nad všemi možnostmi a otestovat je, protože se může stát, že i kvůli změnám ve specifikaci se nám nepodařilo všechny změny převést do TCs. Samozřejmě nejde vždy 100 % aplikace pokrýt testy, pak si ale musíme dobře rozmyslet hraniční případy a ty důkladně pokrýt).

Náš QA Tester Martin Matuna testuje novou appku

Pokud nějakou chybu najdeme (případně defekt nebo selhání, záleží na konkrétním případě), tak ji musíme důkladně analyzovat a zapsat do Redminu, Jiry nebo i GitLabu. Záleží na projektu a případně zákazníkovi, kam je potřeba reportovat. Jak pro TCs, tak pro defekty máme šablony, které postupně vyvíjíme, vylepšujeme a které zachycují naši dlouholetou zkušenost. Chceme, aby mělo celé QA co nejpodrobnější výstup z testů a aby zapojení ostatních týmů bylo co nejjednodušší. Při reportování chyby je důležitým měřítkem i závažnost problémů. Je třeba jasné, že chyba, která se projevuje na jednom telefonu z tisíce má nižší prioritu než závažná bezpečnostní chyba při přihlašování pomocí hesla.

Samozřejmě tímto práce nekončí, o reportované chyby se musíme starat včetně retestů. V průběhu vývoje se testuje v cyklech, takže se kolečko opakuje několikrát. Ani po vydání aplikace práce nekončí, je nutné se starat o zákazníka a o případné chyby z produkce a zajistit jejich opravu, protože testování neodhalí vždy 100 % selhání, která se mohou dostat až k zákazníkovi.

Device room v eManu

Jak práce v QA týmu ovlivnila jeho členy?

Každého z nás práce jistým způsobem ovlivňuje, trpíme profesionální deformací. Namátkou můžeme vybrat pár činností, které někteří členové QA zkoušejí v reálném světě:

• pokoušíme se vybrat 0 Kč z bankomatu
• při platbě kartou přikládáme jiný RFID/NFC čip a čekáme, co to udělá
• ve výtahu volíme patro, na kterém se zrovna nacházíme
• na automatických pokladnách skenujeme QR kódy a taky zadáváme nákup v počtu nula rohlíků
• v metru otevíráme tlačítkem dveře až po zaznění hlášení, že se dveře zavírají, a sledujeme, zda se dveře otevřou

Ve zkratce, snažíme se všechno “rozbít” a podívat se, jak na to určitý systém zareaguje a jsme velmi rádi, když se to nedaří a vše funguje, jak má 😉

Kdo se hodí do QA týmu v eManu?

Ideální člen našeho týmu testerů chce, aby zákazník dostal bezchybný produkt. Je zvídavý, bez toho to nejde. Občas se snaží všechno rozbít především simulací neočekávaných stavů. Ne všechny bugy jsou totiž objevitelné pouhým pohledem. A taky je schopen posoudit, která chyba je zásadní a která je spíše drobnost. Baví ho dotahovat věci do konce a ještě dál. Bugreport nekončí nahlášením developerovi.

A proč se hodí být členem QA týmu v eManu?

Máš 70 % času svobodu v tom, jak si rozvrhneš práci. Nikdo ti neříká, co máš kterou hodinu který den udělat. Tvoje výstupy jsou navíc vidět, výsledná řešení používají miliony lidí. Taky dostáváš pravidelný feedback od kolegů a každý týden máš sezení se svým Team Leaderem, kde můžeš řešit úplně cokoli.

Nenudíš se, spolupracuješ s ostatními na velkých a různorodých projektech. A pokud chceš roztáhnout křídla, dostaneš prostor. Dostatečně rychle dostáváš větší zodpovědnost, seniornější členové tě podporují v rozvoji.