Nahlédněte za oponu:
Můj názor na budoucnost Testingu
V online prostoru u komunit zabývajících se rekvalifikací do IT často vidím otázky na téma budoucnost IT s příchodem umělé inteligence (AI). Má vůbec význam jít do IT bez programování na pozici manuálního testera? Vždyť teď frčí automatizace! Všichni chtějí testery s automatizací. Ano, ale i tak se do IT dostávají absolventi kurzu na pozici manuálního testera.
Disclaimer
Tento článek není primárně určen pro neIT obecenstvo. Používám v něm technické výrazy bez vysvětlení a tak text nemusí být pochopitelný.
Podívám se na to z širšího pohledu. Budu hodně kritická a budu hodně paušalizovat. Proto, prosím, následující text berte s nadsázkou. Následující události jsem já nebo moji přátele v IT opravdu zažili. Všechny. Několika testerům na různých úrovních jsem dala článek přečíst před publikováním. Děkuji za jejich podněty, o které jsem článek obohatila. Některé z nich najdete v obrázcích jako jejich citace. Často tedy popisuji pohled vývojáře nebo testera, méně se na téma dívám z pohledu managementu či byznysu, i když i tento pohled se pokusím zahrnout.
Historie testování
Když testování začalo být cool, všichni tvrdili, že testují. Často to znamenalo, že na velký projekt nebo do většího týmu byl přiřazen 1 (slovy: jeden) tester, který to samozřejmě absolutně neměl šanci stíhat. Ale přeci testujeme!
Následně začalo být cool buzzword Quality Assurance (QA). Tak se všem v test týmu na vizitku napsalo QA. Je to přece super filozofie a my ji samozřejmě implementujeme. Jak jinak. Realita byla často taková, že se na projektu začalo alespoň obstojně testovat. Co přesně je QA věděl málokdo. Ještě méně lidí jej skutečně praktikovalo. Myslím, že dodnes to pořádně neumí a nedělá spousta lidí s QA v job title. Sorry jako. 🙂
S příchodem agile či DevOps (CI/CD), kde se bez automatizovaných testů nedá dosáhnout maximální efektivity, jsme se snažili o automatizaci. Často to vypadalo tak, že testeři do zblbnutí několikrát týdně testovali manuálně regresní testy. Jen malá oblast byla automatizovaná a na další automatizaci nezbýval čas. Občas za to byli managementem náležitě pokáráni. Jak je to možné, že neautomatizujete? Nebo jsme o automatizaci aspoň mluvili. Určitě s ní brzy začneme! Někde už se o ní mluví několik let, ale skutek utek.
Jak je vidět, v testingu jde všechno poměrně pomalu. Donedávna se stávalo, že se najal a náležitě zaplatil automation tester, aby následně prováděl převážně manuální činnosti. A opět, na automatizaci není čas. Často máme totiž v test týmech stále podstav. Někdy se potkáte s úžasným vzorečkem 1 Tester na 4 BE a 2 FE DEV. Tento poměr není zcela ustálený, protože je v podstatě nesmyslný. Je to závislé na mnoha faktorech včetně například seniority a produktivity zmíněných DEV, nemluvě o typu a velikosti projektu a další.
Moje zkušenost s testingem
Výše zmíněné zapříčinilo to, že během mé kariéry Java vývojářky jsem nasbírala spoustu zkušeností z oblasti testování. Proč? V době, kdy jsem začínala, testeři na projektu chyběli nebo jich bylo málo. Testovali jsme si po sobě my vývojáři. Někteří programátoři nemají testování rádi, nemají pro něj vlohy ani mindset. Často neznají ani základní test praktiky. Já to měla vždy opačně. Během studia na VŠ jsem měla skvělý předmět o testování s výbornou doktorandkou a tak jsem tuhle roli ráda přijala pro zpestření. Postupně se situace zlepšila. Testeři začali být k dispozici v každém týmu a já jsem s nimi vždy ráda spolupracovala. Někdy jsem se starala o automatizaci sama, jindy jsem jim s ní pomáhala.
Současný stav testingu
Ač se situace postupně zlepšuje, testing stále není tam, kde by měl být. Myslím, že stále nebyl plně pochopen jeho význam.
Nedávno jsem na LinkedInu narazila na obrázek od Teseny, jedné z nejznámějších českých firem v oblasti testování, s textem: Firmy, které správně testují SW ušetří až 80% nákladů na opravy.
Jedním ze základních principů testování je, že čím dřív chybu najdeš, tím míň tě stojí její oprava. Graf nákladů na opravu chyby se mi vryl do paměti už na VŠ. Nepodařilo se mi dohledat, kdy přesně byl tento princip popsán, nicméně v testerské bibli od Rona Pattona z roku 2000 už je. I po 23 letech je to stále princip, který musíme vizualizovat a připomínat. Smutné.
A abych nezapomněla, hádejte, kdo je teď s vidinou ekonomické krize propouštěn v IT mezi prvními?
Musíme automatizovat
Po tom, co i ty největší korporáty prošly agilními transformacemi, jsme se dostali do bodu, kde už to bez automatizace prostě nejde. Poslední dva až tři roky se tu automatizace konečně začala více řešit a taky reálně dělat. Jenže jsme to, dle mého názoru, vzali za špatný konec. Lépe řečeno za špatné konce, protože existuje několik, podle mě nesprávných přístupů. Je třeba si uvědomit, že automatizace existující aplikace se neuskuteční lusknutím prstu. Je to proces a podle rozsahu to může trvat celkem dlouho. Je potřeba vyhradit 100% kapacitu až několika lidí. Je třeba s tím v budgetu počítat, protože tento proces bude finančně nákladný. Doporučuji automatizovat po částech a mít co nejdříve viditelné výsledky.
Dalším překvapením na této cestě může být poznání, že neexistuje jen jeden způsob, jak automatizovat. Je to s podivem, ale ani zkušenosti se Seleniem se ještě nerozšířily tak, aby každý věděl, že automatizace testů se nerovná pouze testy UI.
Supermani
V IT se neustále pokoušíme najít supermany. Jedna osoba, která vládne celou širokou škálou dovedností. Z takových osob chceme mít složený ideálně celý tým. Chceme Fullstack vývojáře, protože je to další cool znějící pozice. Tak jako jinde ignorujeme, co to skutečně znamená. Chceme, aby tento „superman“ vytvořil celou aplikaci od začátku do konce – od analýzy, přes návrh aplikace, vývoj frontendu i backendu, řešení databází, až po zvládání DevOps. A samozřejmě by měl také zastat roli testera. Význam slova Fullstack se posunul jinam, než jak byl původně zamýšlen. S přáteli si z toho děláme srandu a náš oblíbený vtípek je, že hledají Full Full Fullstack vývojáře.
Nevím, jak Vy, ale já osobně jsem vždy byla příznivcem specializace a odborníků pro každou jednotlivou roli, které jsem právě vyjmenovala. U méně složitých „sranda“ aplikací a pro určité jazyky, chápu. A tím nechci nikoho dehonestovat. Pro obří aplikace třeba v Javě už moc ne.
Pravda je, že jen málo Fullstack jednorožců se může pyšnit expertní úrovní ve všech oblastech. Pod pojmem Fullstack častěji najdeme osoby, které jsou buď téměř průměrné ve všech rolích, nebo vynikají v jedné a ve zbytku zaostávají. Toto je samozřejmě generalizace a najdou se výjimky.
Proč ty supermany hledáme? Může za tím být management, který často s IT nemá takové zkušenosti. Dříve se do managementu v IT dostala spousta lidí, kteří byli dobří manažeři, ale rozumět IT se učili až za pochodu. Nemusí tedy přesně vědět, co znamená a obnáší práce jednotlivých rolí. Dále může sehrát svůj faktor i to, že situace (covid, válka, krize) je tlačí do toho, mít jeden headcount, a ne více.
Automation tester is the new superman!
V podstatě jde o supermana, který kombinuje role testovacího analytika, manuálního testera, testera mobilních aplikací, automation testera a nejlépe by měl mít zkušenosti s devops a performance testy. Měl by ovládat co nejvíc toolů, frameworků a jazyků. Fullstack tester. 🙂
Kolik stojí automation tester
Cena automation testera se odvíjí od jeho zkušeností, náplně práce, technologií a jazyků, které musí ovládat, včetně nástrojů pro testování. Bezpečně mohu říci, že automation tester bude stát více než manuální tester a ti nejlepší se mohou vyrovnat s nejlépe placenými vývojáři. Tady už ale předpokládám, že takový tester má znalosti architektury a je schopen zaškolit tým. Pokud si někdo myslí, že může někoho přeškolit na automatizované testování a ponechat mu stejný plat, pak se šeredně mýlí. Takový člověk dříve nebo později uteče do jiné firmy, která mu nabídne mnohem vyšší plat. Poptávka je teď vysoká.
Hledáme automation testery, ale spíš budeš manuál
Do rukou se mi dostávají různé poptávky po testerech. Často jsou ve stylu: „Hledáme 4 automation testery“. Po přečtení Job Description ale zjistím, že hledají supermana. Manuálního testera, který bude provádět manuální testování a zároveň automatizovat. Povím Vám tajemství. Tohle velice často nefunguje. Proč? Zkušenější automation testeři už se několikrát spálili. K té automatizaci se často ani nedostali. Jen klikali. Pořád. Psali test cases. Sice za to nejspíš dostanou dobrý plat, ale je nutné si uvědomit, že je to nenaplňuje. Pokud Vás programování chytlo, pak nechcete „jen klikat“. Nechcete psát dokumentaci. Chcete hlavně programovat. Takový tester Vám brzy zase uteče a já ho/ji v tomto rozhodnutí podporuji. Pokud nějaký skill nepoužíváte, trochu Vám zakrní. A taky Vám ujede vlak co se týče moderních trendů. Občas do toho rýpnu a zeptám se, proč se ta poptávka nerozdělí na čistě manuální testery a čistě automation. On je potřeba jeden do každého týmu. Zatím tam žádný není. Byť firmu a její projekty či aplikace neznám, spouští se červené světýlko, že to nejspíš dopadne tak, jako vždycky. Světýlko se rozsvítí vždy, když je zmíněno i manuální testování a to v poměru více než 70:30. Ano, manuální testování může být i částečnou náplní práce automation testera, jak zmíním níže, nemělo by ale zabírat více než ¼ jeho času.
Hledáme automation testery s prokazatelnou praxí
Obdobně jako Fullstacky teď hledáme i Automation testery. S prokazatelnou praxí s automatizací! Potutelně se usmívám, když vidím poptávku na 6 takových testerů, s minimální praxí dva roky a to ještě každý s mixem alespoň dvou různých nástrojů s různými jazyky pro automatizaci. 2 dny v týdnu v kanclu povinně. Good Luck! Nevím, jestli je horší hledat tohle nebo 6 senior java vývojářů najednou. Ta automatizace tady dřív fakt moc nebyla a když, tak hlavně Selenium. To v poptávce kupodivu nebylo zmíněno, ale předpokládám, že se započítává.
Všechny přeškolíme. Manuální testing is dead!
Pak tu máme další přístup a to ten, že když je ta automatizace tak nutná, tak všechny manuální testery přeškolíme na automation. Nemyslím si, že je to myšleno zle. Jen těm nahoře nedochází, že ne všichni mají buňky na programování. Kdyby je měli, nejspíš už to dělají. Sama si to zkouším na svých absolventech v navazujícím kurzu základy automatizace WS. No code automatizace, ale už je to prostě úplně jiné myšlení, které potřebuje spustit jiné mozkové závity. Tahle cesta může někomu pomoct a opravdu ho přeškolit na automaty, ale rozhodně nebude 100% úspěšná. Nenuťte někoho, kdo nechce, automatizovat. Pokud k tomu ale někdo má předpoklady a chce to dělat, je to jedna z možností.
Automatizovat budou programátoři!
Testeři předají svoje znalosti programátorům, kteří budou psát automaty. Uf. Geniální nápad. Akorát, že vůbec. Ve zkratce – jiný mindset, confirmation bias, testování je vědecká disciplína a tak ji jen tak easy peasy nepředáte, kde na to DEV vezme čas? Plus argumenty zmíněné v textu před i za tímto odstavcem. Na automatizaci se teď prý hlásí i ex vývojáři, kteří ale o testování nic moc neví. Ještě jednou – vědecká disciplína!
Jak to vidím já?
1) Vychovejme si automation testery
Místo požadavku na prokazatelnou praxi by se měli využívat absolventi dobrých kurzů automatizace. Je jich tu dostatek. K nim si najdu zkušeného experta (interně či externě), který bude stát minimálně tolik, jako senior Java vývojář. Tento expert bude směřovat a mentorovat tyto absolventy a dohlédne na to, aby nám automaty za chvíli nespadly na hlavu. Což se opravdu stávalo a stává, častěji, než si myslíte, když s něčím pracujete poprvé a neumíte to. Tento expert Vás vyjde daleko levněji než měsíce či roky strávené na automatizaci, kterou pak zahodíte a budete dělat znovu. Tentokrát pravděpodobně už s opravdovým expertem. Jinými slovy, zkušené automation testery si vychovám. A pak expert půjde o dům dál.
2. Využívejme správně manuální testery
Manuální testing není mrtvý, jak se může zdát z poptávky po testerech. Jsem trochu konsternovaná, když na jedné straně vidím neustálé snahy o šetření na nákladech v IT a na straně druhé téměř nulovou poptávku a nedostatečné využití levnější pracovní síly v podobě manuálních testerů. Prozradím vám další tajemství: automatizované testování pravděpodobně nikdy plně nenahradí člověka. Stále je potřeba provádět exploratory testing. Takže fyzicky klikat v aplikaci = manuální testování. Jak víme z konceptu Test pyramidy. Je třeba vymýšlet test cases, dělat test analýzu a spousta dalších činností, které nejsou psaní kódu automatizovaného testu.
Zeptala jsem se AI, zda „Manuální testing is dead!“. Odpověď: Je důležité poznamenat, že ačkoliv automatizované testování hraje stále větší roli v oblasti softwarového testování, manuální testování stále není „mrtvé“. Existují určité situace nebo typy testů, jako například uživatelské testy nebo explorativní testování, které mohou vyžadovat manuální testování. Navíc, i když je automatizace velmi užitečná pro opakované testy nebo regresní testy, některé nové funkce nebo scénáře mohou vyžadovat manuální testování, alespoň v počátečních fázích vývoje.
3. Posouvejme manuální testery
Pojďme posunout manuální testery tak, aby byli co nejvíce nápomocní automation testerům. Zase se trochu vrátím do historie. Proč si myslíte, že vznikl samostatný obor Testing a role Testera? Krom jiného to samozřejmě šetřilo čas programátorů, kteří se mohli více soustředit na kód. Dobrý Tester provede analýzu chyby a dodá podklady v bug reportu tak, aby opět šetřil čas programátora. A my tady teď chceme platit lidi se skillem programování i za to, že dělají klasickou činnost manuála? Není to postavené na hlavu? Já si myslím, že lze vhodně zaškolit manuální testery tak, aby pochopili o čem automatizace je, kdy a jak se dělá a aby byli schopní automaty chápat a obsluhovat. Aby byli schopní číst v kódu, dojít do místa, kde test spadl a provést analýzu. Dokonce můžeme ty, kteří budou ochotni se naučit alespoň elementárně psát kód nechat psát vnitřky testů. Jak to myslím? Nejvíc lidí zná Selenium, tak to vysvětlím na něm. Je vcelku jedno, jestli to bude v RobotFrameworku se Seleniem nebo v Playwright nebo v něčem jiném. Zkušení automation postaví architekturu a kostru testů s využitím best practices a návrhových vzorů. Vyškolení manuální testeři pak budou umět změnit test = přepsat jeden řádek testu, pokud se změní např. ID prvku v HTML. Z existujících testů budou umět napsat obdobný test. Do existujícího testu budou umět změnit vstupní nebo výstupní data, případně je rozšířit. Ty, které to nadchne podpoříme v tom, aby se z nich stali plnohodnotní automation testeři. Ti, kteří na to nebudou mít buňky necháme u manuálního testování, ale s velkou přidanou hodnotou a pomocí pro automatizaci. Myslím, že tahle varianta je daleko schůdnější, než trvat na přeškolení všech a teď hned. Bude to jednoduché? Ne. Zvládnout to všichni? Částečně ano, plně ne všichni.
4. Tenhle bod je spíš moje zbožné přání a zase se odkážu na test pyramidu. Snad místo hledání test automation supermanů budeme brát v potaz specializaci a nebudeme hledat Fullstacky v různých jazycích, nástrojích a úrovních automatizace v jedné osobě.
Jak ovlivní AI budoucnost testingu
Nejsem expertka na umělou inteligenci a tak nerada dělám predikce na toto téma. Veřejný prostor byl nejprve zcela zahlcený katastrofálními scénáři, že většinu IT pozic včetně programátorů brzy zanikne. „Manuální testeři už nejsou vůbec potřeba.“ „Programátoři jsou nyní bezcenní díky AI.“ Pravděpodobně to byl šok a strach. Naštěstí jsme se už uklidnili.
Současná debata se ale přiklání k názoru, že v následujících 5-10 letech nejspíš ne. Spousta činností bude i nadále vyžadovat lidský úsudek, analýzu, interakci nebo zkušenost. Je důležité si uvědomit, že AI se vyvíjí velmi rychle a je možné, že dojde k významným změnám i během několika let. Tvůrci AI se o to intenzivně snaží.
Já si myslím, že tak jako firmy ihned nepřešly na cloudová řešení, kdy zejména korporátům toto rozhodnutí trvalo velmi dlouho, tak i nyní očekávám obdobný, ale rychlejší, proces s AI. Nejprve je třeba vyřešit zejména otázky bezpečnostní i právní, stejně tak jako tomu bylo u přechodu na cloud. Nepatřím do vrcholového managementu a tak do problematiky plně nevidím. Dokážu si představit, že je to náročný proces, čím větší firma tím více robustní řešení. Menší firmy jsou flexibilnější, ale i tak je to operace, která se musí předem naplánovat, vyčlenit na ni finance a samozřejmě na to potřebujete i lidi. Proces je to rizikový a vy nemůžete ohrozit chod firmy.
AI může již nyní pomáhat testerům, které jsem zmínila v bodě 3 výše. Mohou si nechat vysvětlit kód, mohou požádat, ať v něm AI najde chybu. To mi přijde skvělé. Proto se s AI začněte kamarádit. Pozor, má to ještě spoustu nedostatků. Jako příklad uvedu, že mi nedávno ChatGPT-4 neodhalil použití mně místo mě. Je třeba být ve střehu.
Závěr
V tuto chvíli se nedá zcela přesně předpovědět, jak dlouho budou dveře do IT otevřené pro rekvalifikaci. Záleží na tom, kam se ubere cesta s umělou inteligencí a jak přesně se s jejím využitím bude práce v IT měnit.
Nároky na Testery se pomalu, ale jistě zvyšovali i před nástupem AI. Do budoucna se domnívám, že ubude čistě manuálních testerů a většina stávajících testerů se bude muset posunout blíže k test automatizaci. Neříkám, že budou testy plně programovat. Rozhodně se s nimi budou muset naučit zacházet a to minimálně v podobě čtení kódu. Takové impulzy se objevují už nyní. Zároveň si myslím, že je na čase se s AI začít kamarádit. Dle průzkumu v mé sociální bublině se to u mých IT kolegů ani jejich firem zatím ve velké míře neděje. Vyčkáváme.
Co se týče automatizace – i snaha se cení. Jsou zde firmy, které to umí a dělají dobře. Spousta lidí si při čtení tohoto článku možná říkala, že to co píšu, nikdy nepotkala. V tom případě gratuluji.
Vím, že začít s automatizací není jednoduché. Byť jsem zde často zmínila management jako možnou příčinu problému, na závěr se ho chci zastat. Musí plánovat dopředu, musí sehnat budget a ve finále musí sehnat i lidi. Často možná nemají dobré technické znalosti. Nemají to jednoduché.
Pokud se u Vás ve firmě automatizace řeší a Vy k ní máte jako Tester výhrady, opravdu doporučuji sebrat odvahu a komunikovat. Překvapí Vás, jak management umí naslouchat, pokud téma dovedete náležitě vysvětlit a vyargumentovat. Nepočítejte s tím, že nutně ten druhý musí mít všechny IT znalosti. Já sama jsem často vysvětlovala základní test principy.
To samé platí pro management. Běžte do test týmu a naslouchejte.
O mně
Lucie Tvrdíková
Jsem lektorkou IT kurzů. Již více než 6 let pomáhám career switchers s rekvalifikací na pozici IT Testera. Ve firmách se věnuji firemnímu vzdělávání a IT konzultacím. Na kurzech čerpám ze své praxe Java vývojářky a Scrum Masterky.
Další příspěvky
Nový kurz Proč se stále nedaří dostat do IT? Aneb co tě brzdí a jak to změnit? Společně odhalíme klíčové důvody, proč se ti nedaří prorazit a co je potřeba změnit.
Co se změnilo v sylabu k testerské certifikaci? Jak změny celkově hodnotím a co si myslím o cvičných testech?
Proč jsou peníze špatnou motivací pro vstup do IT? Přečtete si článek, ať zjistíte aktuální mzdy.
Nedaří se Vám dostat do světa IT? Zkuste následující tipy, jak se dostat do IT, které Vaše šance na úspěch zvýší.
Přečtěte si příběh z první ruky od absolventky Báry. Ve svém příběhu poskytuje náhled na to, jak dlouho trvá zaškolení juniorky v IT.