Štítek: testing

Je testování v agile úzkým hrdlem?

Posted on by tredgatecz

Je testování, Quality Assurance brzda vývoje v agilním prostředí? Dovolím si být trochu kontroverzní a řeknu, že ano. Proč tomu tak je a jak se této nálepky zbavit?

V dnešním konkurenčním prostředí je kvalita software zásadní pro získání a udržení spokojených zákazníků. Ačkoli agilní metodiky přinášejí mnoho výhod, jako je rychlejší dodání produktu a lepší přizpůsobení se změnám, mohou také představovat výzvy pro testování a QA. Jak se vypořádat s těmito výzvami?

V tomto článku se ponoříme do problematiky agilního testování a QA, prozkoumáme hlavní výzvy a představíme osvědčené metody, které vám pomohou posunout váš tým na novou úroveň efektivity a spokojenosti zákazníků.

Agilní vývoj

Než se ponoříme do problematiky testování v agile, pozastavím se nad tím, jak agilní vývoj funguje a jaké jsou jeho cíle.

Agile, ať už jako scrum, kanban, SAFe či jiné přístupy mají za cíle:

  • Zrychlit dodávání software
  • Spokojenost klienta
  • Rychlejší reakce na konkurenci
  • Kontinuální zlepšování a komunikace
  • Flexibilita

Těchto cílů se dosahuje pomocí iterativního vývoje.

Jeden cyklus běžně trvá od 1 dne zhruba po měsíc. Nejběžněji to ale u nás bývá 14 dnů.

Tlak na dodávání je obrovský. Čím rychlejší dodávka produktu, tím lépe.

Testování jako brzda

Co toto má společného s testováním?

Veškeré činnosti v rámci SDLC (Software Development Life Cycle) se tomuto tlaku přizpůsobují.

Úkoly bývají menší v porovnání s Waterfall, komunikace je preferována osobní namísto e-mailové, dokumentace je stručnější…

A testování? Běžně bývá stále stejné, jako ve waterfall.

Co to znamená? Testeři v agilních týmech často čekají na to, až jim vývojáři dodají vyřešený úkol.

Následně se začíná testovat, opravovat bugy, spouštět regresní testy.

Dochází ke kombinaci Agile a Waterfall:
Watergile

Vytváří se posloupnost. Jedna oblast čeká na druhou, dělají se postupně.

Tímto bohužel dochází ke kombinaci dvou světů agilního a waterfall.

Vzniká pojem, který rád popisuji jako Watergile.

Znamená to ale problém. Hlavní důvod je ten, že vývojáři často odevzdávají své úkoly těsně před plánovaným ukončení iterace.

Testeři následně mají málo času na otestování, nahlášení chyb, exekuci regresních testů.

Tento fenomén můžeme nazvat neagilní testování.

Jak to může na projektu vypadat? Na to se můžete podívat na obrázcích níže.

Začátek sprintu (1)
2 dny do konce
1 den do konce
BUG (1)
RELEASE

Dopady

Nemají do čeho píchnout.

Frustrace testerů, momentální nedostatek zdrojů, zpomalení dodávek a snížení kvality jsou častými dopady neagilního testování.

Demotivace je zapříčiněna tím, že na začátku iterace testeři/QA inženýři nemají “do čeho píchnout” a na konci iterace jsou přetížení.

To způsobuje frustraci, která může vést například ke konfliktům v týmu nebo dokonce k odchodu testera.

Tím, že tester nemá dostatek času dokončení testů vznikají 2 situace:

  • Nutnost přesčasů
  • Přesun úkolů do další iterace (spillover)

Ani jedna z nich pro tým není ideální.

Všechno toto následně vede k přímým dopadům na projekt a to jak nesplněním termínů, tak poklesem kvality.

Jak z toho ven?

Jednoduchá odpověď? Začít testovat agilně.

Co to vlastně znamená? Z mého pohledu je to zapojení testera nebo QA Engineera v celém sprintu, ne jen na konci. Jak toho ale docílit?

Ve hře je několik možností, jak testování můžete udělat více agilní.

Jsou to zejména oblasti:

  • Shift-left testování,
  • Automatizace testování,
  • Optimalizace procesů,
  • Rozšíření zodpovědností v týmu

Shift-left testování

Posouvání testování doleva je myšlenka, která říká, že by se testovat mělo co nejdříve ve vývojovém procesu.

Znamená to dřívější testování jak z dynamického, tak statického testování.

Tester se aktivně účastní všech ceremonií v týmu, vývojové úkoly se rozpadají na co nejmenší části, aby byly dříve dokončeny vývojáři a tedy i dříve testovatelné.

Já tuto myšlenku rozvíjím ještě dále, protože kroky popsané výše jsou dle mého názoru nedostatečné.

Jak tedy můžeme testování posunout doleva ještě více?

Pair-testing

Je možná větší spolupráce v týmu, například mezi vývojářem nebo testerem.

Vývojář může již při vývoji s testerem provádět takzvaný pair-testing. Vývojář a tester při vytváření nové funkcionality sedí spolu. Tester dává vývojáři okamžitou zpětnou vazbu.

Cíl je dávat zpětnou vazbu co nejdříve.

Tímto způsobem se sníží riziko výskytu chyb, tester se seznámí se zadáním.

Dokonce i opravy jsou rychlejší, protože vývojář nemusí investovat čas do zpětného seznámení se s kódem.

Další, co může pomoci je testování na lokálním prostředí.

Lokální prostředí

Často je pro testování vyžadováno stabilní prostředí.

To znamená, že vývojáři do něj neinstalují rozdělanou práci.

Z toho následně vyplývá, že tester musí čekat, až vývojář svůj kód dokončí.

Na projektech se mi vyplatilo umožnit testovat i na lokálních nebo DEV prostředích.

Vývojář nám může nahrát rozdělanou práci a my mu následně můžeme dát zpětnou vazbu dříve.

Automatizace testování

To, že je automatizace testování důležitá, dnes již téměř nikdo nepopírá.

Z mé zkušenosti se ale často agilní týmy perou s tím, že na automatizaci není čas.

Tester musí v tomto případě vše testovat ručně.

A to chce čas… spoustu času.

Typický vývoj end to end automatizace manuálních testů trvá dlouho a je těžko udržitelný zejména v rychle se měnícím prostředí.

Řešení mohou být atomické testy, které se zaměřují na jednotlivé elementy a jejich funkčnost, než na celý business proces.

Optimalizace procesů

I když by v agilním vývoji měla vznikat jednoduchá dokumentace, u testování je často nadále vyžadováno vytvářet detailní test plány, test analýzu, testy.

To zabírá čas, který poté může chybět někde jinde.

Také vývojový proces je občas neefektivní. Dělají se velké úkoly, které zaberou někdy i mnoho dnů na dokončení.

Rozdrobení úkolů na menší části totiž není jednoduché a spoustě lidem se do toho nechce.

Končí to pak přesně tou situací, kdy tester čeká celý sprint na to, až bude moci něco testovat.

Náprava je v tom, že se procesy zefektivní. Ubere se administrativy, schůzek a dalších činností, které berou náš drahocenný čas

Rozšíření zodpovědností v týmu

Tester/QA Engineer je v týmu proto, aby zajišťoval kvalitu.

Pokud se objeví problém, je na testerovi aby ho odhalil.

V extrémních situacích vývojáři nezkusí ani spustit svůj kód.

Pokud je zodpovědnost kvality pouze na QA týmu, poté opět vznikají situace, které mohou způsobovat neefektivnost.

Za kvalitu by měl být zodpovědný celý vývojový tým nejen QA/tester:

  • Vývojář si testuje svůj kód.
  • Analytik udělá revizi dokumentace.
  • Product owner ověří, že jeho myšlenka dává smysl, atd.

Co z toho plyne?

Odpověď na počáteční otázku: „Je QA úzké hrdlo v Agile?“ často zní ano.

Není to nic výjimečného. Setkal jsem se s tím na projektech mnohokrát.

V tomto článku jsem se pokusil vyjmenovat způsoby, jak tuto situaci napravit.

Není však možné věci generalizovat. V některých týmech mé doporučení zafungují, v některých nikoliv.

Pokud však trpíte fenoménem neagilního testování. Doufám, že vás tento článek alespoň trochu inspiroval.

Cílem nás všech by totiž mělo být nejen dodávání kvalitního software rychle, ale také naše osobní spokojenost na projektu.

Cíl nás všech je spokojený efektivní tým.

Zdroje a inspirace

Grafika

Za ikony děkujeme webu https://www.flaticon.com/

A to konkrétně autorům: Freepik, Surang, Eucalyp, FlatIcons

9 důvodů proč selhává Automatizace testování

Posted on by tredgatecz

Dříve nebo později se většina projektů rozhodne implementovat automatizace testování. Bohužel jsem ale neslyšel moc úspěšných příběhů.

Do automatizací se tým vrhne s velkým očekáváním a motivací.

Velice rychle ale přichází střet s realitou, demotivovanost, neúspěch.

V tomto článku bych se rád podíval na důvody neúspěchů a jak se jim vyhnout.

Nerealistická očekávání

V posledních letech probíhá pravidelná masáž medii, jak bude člověk nahrazen roboty a automaty. Toto se potom promítá i do očekávání na projektech od automatizace. Mnohokrát jsem se setkal s přístupem:

Chceme zavést automatizaci testování a postupně ve střednědobém výhledu zrušit manuální testování.

Je toto správný přístup, který se setká s úspěchem? Z mých zkušeností nikoliv.

Zásadní potíž je v tom, že dle mého názoru dnes nelze plně nahradit manuálního testera.

Skript nepřemýšlí, dělá jen to, co se mu naprogramuje, alespoň prozatím.

Testerovi vizuální kontrola stránky zabere několik minut. Ve skriptu to mohou být stovky řádků kódu.

Vývoj takového testu může zabrat celé dny, někdy i týdny.

Skripty s příliš mnoha kroky jsou nestabilní, trvá je dlouho vyvinout.

Pokud je zvolen tento přístup, dost možná se testování stane úzkým hrdlem ve vývoji software. Což je naprostý opak toho, co se očekává.

Druhou možností je přístup:

Začneme automatizovat a uvidíme co se z toho vyvine

Začít vytvářet nový produkt (ano, automatizace testování lze brát jako produkt) bez definice cílů je nesmysl. Testeři často skáčou do automatizace bez toho, aniž by je nadefinovali.

Celá aktivita je odsouzena k zániku

Výsledkem může být anarchie a zmatek. Nikdo neví co dělá, proč to dělá a celá aktivita je odsouzena k zániku.

Jak z tohoto ven?

Stačí velice málo. Sednout si, zamyslet se nad tím, co může automatizace přinést, nejlépe s někým, kdo má s automatizací zkušenosti a nadefinovat krátkodobé, udržitelné cíle.

Jak takový cíl může vypadat?

Automatizace regresních testů, repetitivních činností, jako je například příprava testovacích dat, vytvoření sanity checků.

Konkrétněji například:

Pokrytí prioritních regresních scénářů do 3 měsíců, automatizované spouštění v Jenkinsu.

Automatizace testování většinou nepřinese ušetření. Zlepšuje zejména efektivitu, rychlost testing dodávání.

Dlouhá doba vývoje

Stává se, že se tým nadšeně pustí do práce. I když ale pracuje naplno, dlouho není vidět žádný výsledek.

Nejdříve se připravuje framework, nastavují se nástroje. Měsíc je pryč.

Následně se začnou psát testy a připravovat devops prostředí.

Zjistí se, že testy nejsou stabilní. Musí se předělat aplikace, doplnit ID.

Najednou je půl roku po spuštění vývoje a výsledky nikde.

Může se stát, že management tuto aktivitu omezí nebo dokonce zastaví. Proč také investovat peníze někam, kde nevidím ani po půl roce žádný výsledek.

Jak z toho ven?

Mám rád metodu doručování quick wins. Jsou to malé dodávky, které ale již přináší benefit v extrémně krátkém čase. Příklady:

  • Zautomatizování malé, ale kritické oblasti, například test přihlašovací funkce
  • Spouštění testů každý den z lokálu a reporting management
  • Rozsekání větších testů na menší celky a dodávání postupně

Mám jednoduché pravidlo. Pracovat jen na tom, co zrovna potřebuji. Žádný vývoj do šuplíku.

Syndrom věčně červeného, zeleného testu

Rád bych popsal 2 extrémy, které vedou většinou k restartu celé automatizace nebo dokonce jejímu zrušení v týmu. Jedná se o 2 póly, které jsou rozdílné, ale mají spoustu společných vlastností.

Jedná se o takzvaný syndrom věčně červeného/zeleného testu. O co se jedná?

Syndrom věčně červeného testu

Je stav, kdy automatizace ve většině případů končí neúspěchem.

Tento neúspěch je způsoben například chybami ve skriptech.

Může se jednat o timeout, nestabilní identifikátory nebo také špatně napsané testy.

Pokud se dlouhodobě nedaří stabilizovat běh testů, aby dávaly vypovídající hodnotu, pak dochází k:

  • Frustraci vývojářů automatů
  • Nedůvěra v týmu k automatům, nechuť spouštět
  • Nedůvěru managementu “Seš si jistý, že pád automatů není chyba ve skriptu?”
  • Vypínání problematických testů
  • Omezení aktivit automatizace
  • Zastavení projektu automatizace testů

Co bývá příčinou věčně červeného testu?

  • Nestabilní identifikátory, aplikace nepřipravená pro testování
  • Bad practises v kódu – spaghetti styl, ignorace objektového přístupu, nepřepoužitelný kód, duplikace kódu…
  • Špatně napsané testy – v rozporu s očekávaným chováním v aplikaci
  • Nestabilita testovacího prostředí
  • Neudržování testů

Syndrom věčně zeleného testu

Je pravý opak červeného.

Test ignoruje chybu

Běh testů je úspěšně dokončený, i když je v aplikaci chyba.

Na první pohled to nevypadá, ale tato situace je mnohem víc nebezpečná, než syndrom věčně červeného testu.

Co se může stát?

Test může přehlédnout chybu!

A ta se poté může dostat do produkčního prostředí. Dopady pak mohou být katastrofální.

Syndrom věčně zeleného testu vzniká často z červeného testu.

Jak?

Jednoduše, pokud mi padá aplikace na nepředvídatelném chování aplikace nebo prostředí, mám tendenci tuto „chybu“ opravit tím, že do svého testu přidám podmínku, která situaci vyřeší.

To je ale špatně!

Test by v sobě pokud možno neměl mít podmínku a měl by být deterministický (jednoznačný).

Mám jednoduché pravidlo při psaní testů:

Testovací skript nesmí mít žádné podmínky!

Automatizují se výhradně GUI testy

Automatizují se zejména end to end GUI testy. Integrační testy jsou ve velkém ignorovány.

Ano, toto je častý případ.

GUI test je zajímavější, je vidět, že něco kliká.

Je to ale to, co by se mělo automatizovat jako první?

Podle mě ne.

Pokud se budeme držet principů Test pyramidy, je přeci jasné, že musí dostat přednost integrace.

Věřím, že automatizace například API testů dokáže přinést benefit v testování rychleji a efektivněji, než GUI automatizace.

Nekompetentnost

Nadšený manuální tester se rozhodne, že začne psát automatizované testy.

Zdá se to jako logický postup.

Tak jednoduché to ale není

Často se stane, že tester je na automatizaci sám bez zkušeností a znalostí.

Toto byl bohužel i můj příklad.

Je to jeden z mnoha receptů na automatizační apokalypsu.

Pravděpodobně vznikne spaghetti kód, který je po nějaké době nutné přepsat. V horším případě celý smazat a napsat znovu.
To spotřebovává nejen zdroje, ale i trpělivost a důvěru managementu.

Před začátkem automatizace testování doporučuji projít alespoň základním kurzem na nástroj, který se bude používat.

Také je dobré se naučit základy programování.

Následně je dobré mít jako mentora zkušenějšího engineera nebo alespoň vývojáře.

náhrada manuálních testů 1:1

Automatický skript = regresní end to end test?

Může to být chyba a ubírat na efektivnosti automatizací.

Čím jsou skripty obtížnější a delší, tím jsou méně stabilní a udržitelné.

Psát testy 1:1 k manuálním regresním testů není dobrý nápad.

Automatické testování je obecně velice efektivní v případě jednoduchých, deterministických testů.

Zajímavou možností jsou například atomické automatizované testy (AAT). Zajímavý článek naleznete zde.

Automatizovatelnost aplikace

Ne všechny aplikace jsou vhodné pro automatizaci testování.

Jak se pozná vhodnost, zda-li je aplikace automatizovatelná?

Jeden z klíčů webové automatizace je determiničnost jejího procesu. Pokud nedokážu určit, jak se aplikace v různých situacích bude chovat, zadělávám si na problém.

Další jsou identifikátory HTML elementů.

Pokud nemáte jednoznačný identifikátor, nejméně ten, který se používá pro vývoj, testy nebudou stabilní a opět nastoupí problémy.

Stabilita, odezva prostředí. Padající nestabilní prostředí způsobí pády skriptů, které ve většině případů nemáte jak ovlivnit.

Před spuštění automatizování je nejdříve nutné vyřešit i tuto stabilitu.

Spouštění z lokálního PC

Stává se, že automatizace testování je spouštěna ručně z lokálního počítače.

Jasně, při vývoji testů je to efektivní možnost, jak si skripty otestovat.

Dlouhodobě tento přístup způsobí, že se nevyčerpá potenciál automatizace.

Problémů s přístupem ručního spouštění je spousta.

  • Závislost na člověku, který testy spouští.
  • Škálovatelnost
  • Čas spouštění
  • Riziko ztráty dat
  • …

Nejlepší způsob je testy napojit na DevOps a spouštět testy na pravidelné bázi.

Například každé ráno před startem pracovních hodin.

Špatný výběr nástroje

V neposlední řadě může automatizování testování zhatit špatná volba nástroje.

Tak jako u dalších oblastích testování je potřeba správně vybrat dle kontextu.

Pokud vyberete nástroj, který je určený pro jednoduché aplikace, do bankovního prostředí.

Může být sice velice jednoduše použitelný, bude mít rychlou implementaci.

Nebude ale zcela jistě mít dobře řešitelnou přepoužitelnost a udržitelnost.

Druhý extrém je použití vlastnoručně vyvinutého frameworku, například v Java na jednoduchou Android aplikaci.

Implementace bude dlouhá a drahá. Tady klidně postačí jednoduchý nástroj.

Shrnutí

Co z toho všeho plyne?

Automatizace testování je samotná část v SDLC (Software Development Life Cycle), a tak je k ní potřeba také přistupovat.

Projekt určitě nenajme místo vývojáře analytika nebo místo testera projektového manažera.

Pro vývoj se používají nástroje, které jsou vhodné pro daný produkt.

Vývojáři nenahrazují architekty.

A tak dále…

Když to jde u jiných částí vývoje, proč by to nemělo jít v automatizaci testování?

Jak se hlásit o práci v IT bez zkušeností

Posted on by tredgatecz

Často potkávám šikovného člověka, který chce začít kariéru v IT. Prošel si několika akademiemi, naučil se programovat nebo má ISTQB certifikaci.

Dokonce se stává, že je víc kvalifikovaný, než většina juniorů s rokem praxe. S tímto „portfoliem“ pak vyráží vstříc nové práci.

Ale!

Brzy naráží na problém.

Nedostane se přes zaslání nabídky na pohovor. Nedostává odpovědi na přihlášky o práci nebo je zpráva zamítavá:

„Děkujeme za zaslání vašeho životopisu, ale bohužel hledáme někoho, kdo má alespoň nějaké zkušenosti. Zkuste se ozvat, až budete mít nejméně půl roku praxe.“

Počáteční nadšení se velice rychle mění ve zklamání a frustraci.

„Jak mám získat půl roku zkušeností, když mě nikde bez zkušenosti nepřijmou?“

Začarovaný kruk?

Jak se vůbec dostat na pohovor?

Co dát do prázdné kapitoly v životopise?

Potřebuješ náboráře zaujmout jinak. Jak na to?

Buď proaktivní

Téměř každá společnost hledá proaktivního, samostatného zaměstnance. Výhodou pro budoucí pohovor bude to, když budeš aktivní od začátku.

Vezmeš věci do svých rukou a dáš vědět, že ti na nové práci skutečně záleží.

Jak taková proaktivita může vypadat? Už jen napsání průvodního dopisu je známkou toho, že žádost o práci bereš vážně.

Máš telefonní číslo na recruitera? Zavolej mu!

Nemáš? Zavolej na recepci společnosti a nech se s ním spojit.

Hovor je daleko efektivnější, než psaná forma. Tvé šance dostat se na pohovor se osobním kontaktem nesmírně zvyšují.

Já osobně například zažil to, že člověk, který chtěl práci ve firmě, osobně přišel na sídlo společnosti. Dostalo mě to do kolen.

Můžeš dokonce zajít tak daleko, že pokud máš vyhlédnutou firmu, která ale nemá v tu chvíli otevřenou tvou vysněnou pozici, zavoláš do ní s žádostí o práci. Máš určitou pravděpodobnost, že společnost pro tebe pozici otevře.

Buď otevřený

Nemáš zkušenosti? Tak to hlavně neschovávej. Nemá to žádný smysl a pokud tě neprokoukne náborář, tak manager v technickém kole určitě ano.

Zaměř se spíše na to, jaký máš potenciál, kterým pomůžeš budoucímu zaměstnavateli.

Je dobré si uvědomit, že pokud tě firma najme jako juniora, investuje následně do tebe velké úsilí, čas i prostředky.

Proto ukaž, co firmě přineseš. Máš ve vlastnostech pečlivost nebo se rychle učíš? Určitě to zmiň buď v životopise nebo při hovoru s náborářem.

Neříkej co neumíš, zaměř se na to čeho chceš dosáhnout

Běžná chyba u juniora je, že se moc soustředí na to, co neumí.

To je hrozná škoda. Ani seniorní expert neumí všechno. Prezentuj to, co umíš nebo čeho chceš dosáhnou, v čem se chceš rozvíjet. Toto můžeš komunikovat již ve zmiňovaném „průvoďáku“.

Připrav CV roli na míru

Že je životopis statický dokument? Hloupost!

Větší šanci na úspěch (pozvánka na pohovor) máš v případě, pokud ho připravíš na míru dané pozici.

Je v popisu poptávané role něco, co v něm nemáš a zároveň by si to mohl nabídnout? Napiš to tam!

Projdi si také webovky a sociální sítě firmy. Zjistíš, jaká je její kultura a jak vypadá ideální kandidát. Pomůže ti to ve výběru firmy, a také zjištěné skutečnosti promítneš do životopisu.

Co ale nikdy, nikdy, NIKDY nedělej je lhaní! Pokud životopis upravuješ, buď si vždy absolutně jistý/á, že uvádíš pravdivé skutečnosti. Pamatuj, pracovní trh je malý a takové věci ti mohou dát nálepku lháře. A té se pak velice obtížně zbavuje.

Nálepky lháře se těžko zbavuje

Ukaž co umíš

Vytvoř si vlastní projekt, kde ukážeš co umíš a nahraj ho například na Github. Zdá se to jako hloupost, ale je to skutečně silný nástroj, jak zaujmout a ukázat se.

Ještě lépe uděláš, pokud svůj projekt vytvoříš pro firmu, do které se hlásíš. Hlásíš se na Testera? Vytvoř testy pro webovky společnosti. Pokud najdeš defekt, tím lépe!

Zkus oslovit agentury

Další možností, jak se uplatnit bez zkušeností je oslovením agentur. Pomohou ti s hledáním práce, a také s přípravou a s optimalizací životopisu.

Některé agentury dokonce nabízí možnosti interních kurzů, které tě na novou roli lépe připraví.

Vzdělávej se

Co není ve zkušenostech, může být ve vzdělání. Existují tisíce online kurzů, návodů nebo článků podporující vzdělání v IT.

Dnešní svět se mění každý den a je důležité s ním držet krok.

Náborář opravdu ocení, pokud se aktivně učíš a držíš krok s dobou.

Pokud dokončíš nějaký kurz, získáš certifikát, určitě je vhodné tuto skutečnost uvést do životopisu. Zvýšíš tím šance k pozvání na pohovor.

Zúčastni se akademie, boot campů

Účast v akademii či bootcampu ti pomůže získat zkušenosti a znalosti z oboru. Získáš nejen zkušenosti, ale dlouhodobé kurzy bývají většinou řízeny tak, aby vzdělání bylo co nejefektivnější. Během týdnů nebo měsíců projdeš komplexním vzděláváním, dostaneš zpětnou vazbu a v neposlední řadě certifikát, který ti může pomoci s hledáním nové práce.

Pojď vyzkoušet například naši akademii, kde tě připravíme na roli testera a navíc ti pomůžeme najít práci.

Projít pohovorem není nic jednoduchého. Ještě složitější je ale se na něj dostat. Jak tomu pomoci bych na závěr shrnul do několika bodů:

  • Proaktivitou a osobním jednáním nic nezkazíš.
  • Nemlž, vždy komunikuj otevřeně.
  • Sdílej to, čeho chceš dosáhnout.
  • Životopis upravuj dle potřeby, ale nelži v něm.
  • Neboj se ukázat co umíš například na Githubu.
  • Pokud se bojíš více komunikovat, tak by řešením mohla být agentura.
  • Nikdy se nepřestávej učit.
  • V neposlední řadě se můžeš zúčastnit nějakého dlouhodobějšího kurzu.

Věřím, že ti tyto rady pomohou nastartovat tvou novou kariéru v IT!

10 důvodů proč začít v testingu

Posted on by tredgatecz

Spousta lidí přemýšlí o startu v IT, ale neví kde začít. Ať už jde o absolventa školy či člověka, který přemýšlí o změně kariéry. Často pokládané otázky jsou:

  • Jak začít? 
  • Jak se mám do IT dostat?
  • Potřebuji školu či jiné dovednosti?

Pokud si tyto nebo podobné otázky pokládáš, pak je možná pro tebe testování to pravé.

A co to vlastně je?

Testing je nezbytná část vývoje Software i Hardware. V dnešním ultra rychlém světě je stále důležitější. Při dodávání nového produktu je potřeba reagovat co nejdříve, pokud možno okamžitě. Zbrklost, změny, stres, to jsou příčiny chyb.

Já osobně mám pocit, že postupem času je kolem mě stále více a více nefunkčních, chybových věcí. Koncový uživatel je až na samém konci. Hlavní cíl je dodat novou věc, i když je nekvalitní nebo nehotová.

A proto tu je testing. Testování pomáhá tyto chyby odhalovat a směrovat aplikaci či jiný produkt ke kvalitnějšímu provozu.

V tomto článku proberu, co je mých 10 bodů, proč vstoupit zrovna do testování.

1. Brána do IT

Neznám ani jediného testera, který by toto tvrzení měl rád. Trochu to snižuje hodnotu a profesionalitu našeho oboru.

Bohužel i bohudík je to pravda. Testování je často vstupní branou do IT. Proč? Nepotřebuješ totiž žádné dlouhé kurzy či školy. V některých případech je možné do testování vstoupit úplně bez zkušeností.

2. Jednoduchý start

Pro start v testingu není nutné mít vysokoškolské vzdělání ba ani umět programovat. Když to vezmu velmi s nadhledem, tak pro uchazeče o testování stačí umět pracovat s počítačem. 

Pokud chceš mít při pohovoru šanci na úspěch, musíš se alespoň trochu orientovat v používaných nástrojích, vědět jak probíhá vývoj SW i umět používat aplikace, které běží v pozadí za tím, co normální uživatel vidí.

Toto naštěstí dokáží pokrýt mnohé akademie, které se zaměřují na předání znalostí nutných pro start. Jednou z nich je i Testovací Akademie, kterou pořádáme.

3. Plat

Je všeobecně známo, že IT nabízí nadstandardní platy. To platí i o testerech. Juniorní tester s minimem zkušeností si vydělá i 35.000 Kč, což je v Březnu 2022 téměř na úrovni průměrné mzdy v ČR, která je 37.047 Kč

Seniorní tester, s 6 lety praxe si může říct o 100 tisíc a víc.

Proč tomu tak je? Odpověď je jednoduchá. IT je obor, který se velice dynamicky a rychle rozvíjí a dlouhodobě v něm je nedostatek pracovní síly. To znamená, že firmy jsou nuceny bojovat o každého zaměstnance. Důsledek je takový, že platy v IT jsou takové, jaké jsou. Testing je v tomto ještě trochu vyjímečnější. Díky větší retenci (odchodovosti) jsou některé pozice velice nadstandardně ohodnoceny.

4. Výzva

Testování na první pohled vypadá lehce. Člověk přijde k aplikaci, nakliká něco dle skriptu a hotovo. Ono tomu tak ale úplně není. Rád říkám, že testing je jako Šachy, je snadné začít je hrát, ale stát se mistrem zabere ohromné množství času. 

Každý den v testování přináší nové výzvy. Ať už to jsou zajímavé úkoly, situace nebo také použití nových nástrojů. 

Jak dosáhnout co nejvyšší kvality aplikace nelze jednoduše popsat. Časem zjistíš, že dříve efektivní techniky začínají být netečné. Proto je potřeba stále vymýšlet a hledat nové způsoby, jak produkt testovat.

5. Rozmanitost

Testing je činnost, která je hodně rozmanitá. Jeden den tester analyzuje nový projekt, druhý testuje, třetí vytváří automatizované testy. Množství činností a cest k tomu jak dosáhnout co nejvyšší kvality aplikace je spousta. Je na tobě, jakou cestu k testování zvolíš. Je jich spousta a určitě se nebudeš nudit.

6. Je nás málo

Proč? Je to způsobeno několika faktory. Tím hlavním je to, že v IT je nedostatek lidí. Díky průmyslu 4.0 je transformace podniků rychlejší, než stačí trh a školy reagovat. Proto je málo nejen testerů, ale i jiných technických pozic v IT jako jsou programátoři nebo analytici.

Další důvod, proč je na trhu nedostatek testerů, zvláště seniornějších je vysoká odchodovost. Tester je univerzální „bojovník“. Musí umět jak technickou část, musí umět komunikovat, tak řešit business situace. Následně už stačí jen ta správná příležitost a z testera je například business analytik.

7. Soft i hard skills

Ač to dle názvu „Testování“ vypadá, testování není pouze o tom, že tester ověřuje funkčnost aplikací. Exekuce (ověřování funkčnosti) je velká část naší práce, jsou zde ale i další úkoly a odpovědnosti. Tester může na chyby upozorňovat již když se přemýšlí o nové funkčnosti. Ověřuje se i dokumentace, která vzniká ještě před začátkem vývoje. Pro naši práci potřebujeme znát produkt do detailu. Dokumentace ale často bývá povrchní či neúplná. To znamená, že si požadované informace musíme zjišťovat od analytika, klienta či vývojáře. Existuje také mnoho situací, kde může tester sdílet svůj názor nebo zkušenosti.

Toto všechno má za následek to, že tester k své práci potřebuje nejen technickou znalost (hard skills), ale také komunikační, měkké dovednosti (soft skills).

8. Rozvoj

Další z důvodu, proč si myslím, že je kariérní dráha testera zajímavá, jsou možnosti rozvoje. Svět softwaru je sám o sobě neskutečně rozmanitý. IT je v dnešní době již téměř všude. “Ajťák” má možnost se uplatnit od retailu až po automotive či bankovnictví. Může se rozhodnout jestli bude pracovat spíše s programy a aplikacemi nebo hardwarem.

To samé platí i o testerech. Nemusíme se však orientovat čistě na odvětví. Junior tester velice rychle narazí na křižovatku kam se vydat. Bude se ubírat spíše technickým směrem například do testování backend systémů? Nebo spíše zvolí cestu k zákazníkovi a komunikaci? Možná je ta správná cesta test management. Nebo rovnou může změnit celý obor a jít pracovat například jako projektový manažer.

Cest rozvoje je spousta a to dělá práci testera ještě víc zajímavou.

9. Komunita

Tak jako vývojáři, tak i testeři mají svou komunitu, kde si sdílí jejich znalosti a dovednosti. V Čechách je to například komunita [pro:]TEST!

Testeři se potkávají na diskusních fórech, meetupech nebo konferencích. Kdykoliv je možné poznat nové lidi nebo si například říct o pomoc či názor.

10. Homeoffice

V dnešní době již možnost pracovat vzdáleně není až tak vyjímečná. Je ale dobré zmínit, že práce testera je možná plně z domova či jakéhokoliv místa na planetě. Já si často prodlužuji dovolenou tím, že pracuji například z pláže.

Práce testera je v hodně ohledech zajímavá. Je však vhodná úplně pro každého? Jsou tu jen samá pozitiva? To určitě ne. Jsou tu i stinné stránky, ale o těch snad někdy příště.

Já svou testerskou kariéru miluji, jsem s mým oborem naprosto spokojený a práce mě naplňuje.

Zaujala tě práce testera? Chceš se stát jedním z nás? Tak to potom koukni na naši testerskou akademii!