📺 Záznam přednášky Dominika Fabiána z Ackee Meets: QA v době AI:
Evidence testovacích zařízení žila v tabulce, o které polovina firmy nevěděla, a druhá polovina ji nevyplňovala. Jako tester jsem nikdy žádnou aplikaci nenapsal – tak jsem si jednu postavil s AI, protože to vypadalo jako menší problém než chodit od stolu ke stolu.
📋 TL;DR
- Evidence zařízení v Google Sheets nefunguje, protože tabulku nikdo neotevře. Data pak nejsou špatná, ona tam prostě nejsou.
- Řešením byla interní aplikace: mobilní, u každého v telefonu, půjčení a vrácení na jeden klik.
- Zvažovali jsme tři způsoby distribuce – na všech testovacích zařízeních, na jednom sdíleném tabletu, nebo každý u sebe v mobilu. Vyhrála poslední varianta.
- Aplikaci psal QA tester bez zkušenosti s vývojem, celá vznikla vibe codingem. Prošla přitom čtyřmi jazykovými modely, dodělaná byla na firemním Claude.
- Stack: React Native na frontendu (pokryje iOS i Android najednou), Google Apps Script na backendu, protože sedí přímo na té tabulce.
- Prototyp běží v Expo Go, cílem je samostatná aplikace přes TestFlight.
- Aplikace nevyřeší lidský faktor. Když si někdo zařízení nezapíše, pořád je to na důvěře – nebo na zámku u skříňky.
📊 Kdo má co, a kdo si vzpomněl: tabulkový chaos v evidenci zařízení
Situaci asi znáte. Testovací hardware ve firmě (telefony, tablety, pár kusů, které si nikdo nepamatuje, odkud se vzaly) žije v tabulce v Google Sheets. Tabulka existuje, je pěkně nasloupečkovaná a teoreticky odpovídá na otázku „kdo má co“.
Prakticky odpovídá na otázku „kdo si naposledy vzpomněl, že má něco zapsat“.
Problém má dvě vrstvy. První je, že o té tabulce polovina lidí ani neví. Do sdílené evidence se zapisuje raritně, protože ji nikdo nemá otevřenou a nikdo o ni nezakopne. Druhá vrstva je horší: v tabulce je nedostatek informací o zařízeních, takže když nějaké konkrétní potřebujete, musíte ho dohledávat. V historii verzí tabulky, po Slack kanálech, nakonec fyzicky – chůzí od stolu ke stolu.
A pak přijde okamžik, kdy si chcete zařízení půjčit, v tabulce je napsaný někdo úplně jiný, a vy to zařízení máte přitom v ruce.
Přesně v téhle fázi jsme se rozhodli, že to chce něco jiného než další sloupec.
🧭 Co jsme od řešení chtěli: aby zápis lidi fakt dělali
Brainstorming nezačal otázkou „jaký nástroj použijeme“, ale otázkou „jak dosáhneme toho, že to tam lidi skutečně zapíšou“. To je jiné zadání a vede jinam.
Cíl byl trojí:
- tabulka bude vždycky aktuální,
- bude z ní na první pohled vidět, co je půjčené a co je volné,
- a zapsání si nesmí stát za nic – žádné hledání odkazu, žádné rolování, žádné „až potom“.
Poslední bod je ten, který rozhoduje. Evidence hardwaru nepadá na technologii, padá na tření. Každý krok navíc mezi „vzal jsem si telefon“ a „je to zapsané“ je krok, ve kterém to člověk vzdá.
📱 Proč interní aplikace a ne další tabulka
Odpověď zněla: uděláme si aplikaci.
Zní to jako overkill na problém, který má „jenom“ tabulka. Ale tři důvody dávají smysl:
Dostane se to nejlíp mezi lidi. Interní aplikaci si nainstalujete jednou a máte ji. Odkaz na tabulku se ztratí ve třetím vlákně odshora.
Rozhraní je přehledné a intuitivní. Většina věcí, které dnes lidi denně používají, má podobu aplikace. Nemusíte nikoho učit, co znamená ikona lupy.
Půjčení i vrácení je na jeden klik. Bez otevírání tabulky, bez hledání řádku, bez rizika, že přepíšete cizí buňku.
🚚 Distribuce: na všech zařízeních, na sdíleném tabletu, nebo v mobilu?
Další problém: jak aplikaci dostat mezi lidi. Měli jsme tři varianty a každá má jinou logiku.
Na všechna testovací zařízení v kanceláři. Aplikace je tam, kde je hardware. Jenže si ji musíte nainstalovat na desítky zařízení a udržovat aktualizovanou.
Na jeden sdílený tablet. Jedno místo, jedna instalace, jasné pravidlo. Zároveň nová fronta a nový bod selhání – když tablet někdo odnese nebo se vybije, evidence stojí.
Každý u sebe v mobilu. Vyhrála tahle varianta. Zařízení si vezmete, dojdete zpátky ke stolu a zaklikáte to na vlastním telefonu, který stejně držíte v ruce.
🤖 Jak ji ale vytvoříme? Vibe coding se čtyřmi modely
Zbývala drobnost. Já jako tester nevím, jak se vytvářejí aplikace.
Pomůže nám s tím samozřejmě AI. Představa vypadala krásně: pár promptů, pár kliknutí, hotová aplikace.
Skutečnost byla méně krásná. Celá aplikace vznikla vibe codingem a prošla přitom čtyřmi různými jazykovými modely, než se dostala do stavu, který se dal deployovat. Dodělaná nakonec byla na firemním Claude.
Interní nástroj s pěti obrazovkami a jedním datovým zdrojem je ideální první projekt. Nemá klienta, nemá SLA a když se rozbije, nikdo nepřijde o peníze – zato se na něm naučíte, kde AI pomáhá a kde vás pošle do kruhu.
To střídání modelů není známka toho, že AI nefunguje. Je to známka toho, že žádný model není konzistentní přes celý projekt. Něco zvládne jeden lépe, něco druhý, a když se zaseknete, přepnutí je levnější než hodina hádání se stejným modelem.
🧱 React Native a Google Apps Script: stack, který zvládne tester
Zůstala otázka technologií. Bude to jen iOS aplikace a Android vynecháme?
Frontend: React Native. Pokryje obě platformy najednou, iOS i Android, a dá se v něm rychle prototypovat. Pro interní nástroj, kde nejde o vyladěný nativní pocit, ale o to, aby to fungovalo všem, je to přímočará volba.
Backend: Google Apps Script. Tady je volba zajímavější, protože to není „správný“ backend. Je pomalejší a možností má omezeně. Zato je přímo napojený na tu chaotickou tabulku, ze které jsme vyšli. Nemusíte řešit databázi, migrace ani synchronizaci – zdroj pravdy zůstává tam, kde už byl, jen k němu přibylo použitelné rozhraní.
Dokud data žijí v tabulce a uživatelů jsou desítky, je propojení přes Apps Script nejkratší cesta k funkčnímu řešení. Jakmile by šlo o produkt s tisíci uživateli nebo o citlivá data, je to špatná odpověď a je potřeba pořádný backend.
📈 Jak aplikace vypadá: půjčení a vrácení na jeden klik
Po nějaké době vibe codingu vznikl první prototyp a první deploy. Vypadá takhle.
Na home screenu zadáte svoje jméno (to se pak propisuje do tabulky) a máte tři akce: půjčit zařízení, vrátit zařízení, změnit jméno. Nic víc tam nepotřebujete.
Obrazovka pro půjčení zařízení ukazuje všechno, co je volné, i to, co má půjčené někdo jiný. Hledat se dá dvěma způsoby: filtry podle platformy – Android, iOS, tablety – nebo vyhledáním podle názvu, když víte, co chcete.
Jedna vlastnost je tam schválně: cizí zápis můžete přepsat. Když je v evidenci napsaný kolega, ale zařízení máte reálně vy, opravíte to jedním klikem místo toho, abyste to řešili zprávou. Přesně tenhle případ byl původně největší zdroj frustrace.
Vrácení zařízení funguje stejně a se stejnými filtry. Rozdíl je v tom, co vidíte: tady jsou vaše zařízení, ne cizí.
To je celá aplikace. Žádné role, žádná administrace, žádný dashboard. Pro problém, který jsme řešili, je to dost.
🔒 Limity prototypu: Expo Go, aktualizace a lidský faktor
Poctivá část. Aplikace je zatím naprototypovaná v Expo Go, což je nejjednodušší způsob, jak React Native projekt dostat na telefon. Znamená to ale, že distribuce a aktualizace zatím nejsou vyřešené – cílový stav je samostatná aplikace přes TestFlight a podobné kanály.
A pak je tu věc, kterou žádná aplikace nevyřeší. Když si někdo zařízení vezme a nezapíše ho, evidence lže dál – jen v hezčím rozhraní.
„Tam bohužel musí do určité míry pořád zůstat na důvěře – nebo je potřeba hardwarové řešení, dávat na skříňky zámky a podobně. Úplně to obejít nejde.“
Z publika padly dva nápady, jak tření snížit ještě víc. Inventární štítky s načítacím kódem nebo NFC tagy – zařízení oštítkovaná jsou, čtečka zatím ne, takže se název zadává ručně. A notifikace na vrácení: doplnit k zápisu datum a nechat systém poslat připomínku e-mailem. V Apps Scriptu, který sedí přímo na tabulce, je to jedna z mála věcí, které jsou opravdu jednoduché.
❓ FAQ
Jak evidovat testovací zařízení ve firmě?
Sdílený pool telefonů a tabletů se rozpadá vždycky stejně: tabulka se přestane vyplňovat. Čistě softwarová odpověď na to neexistuje – aplikace umí snížit tření zápisu na minimum, ale zbytek stojí na důvěře. Tvrdší varianta je hardware: zámky na skříňkách a výdej proti zápisu.
Dá se zařízení evidovat čtením čárového kódu nebo NFC tagu?
Technicky ano a je to logický další krok. V popisovaném prototypu ale čtení kódů zatím není – zařízení jsou oštítkovaná, název se ale zadává ručně. Skenování přidává práci s kamerou a oprávněními, což se v první verzi nevyplatí řešit.
Jak posílat automatické připomínky z Google Apps Scriptu?
Stačí u zápisu evidovat datum a nechat backend poslat e-mailovou připomínku – Apps Script má odesílání e-mailů i časované spouštění přímo v sobě. Patří to k nejjednodušším rozšířením, která se do takové evidence dají doplnit.
Jak se řeší aktualizace aplikace na zařízeních?
Zatím nijak – prototyp běží v Expo Go, kde tohle není potřeba řešit. Cílem je samostatná aplikace distribuovaná přes TestFlight a obdobné kanály, kde už aktualizace řešit půjde.
Proč Google Apps Script, a ne pořádný backend?
Protože data už žila v tabulce. Apps Script je na ni napojený přímo, takže odpadá databáze i synchronizace. Je pomalejší, ale pro interní nástroj s desítkami uživatelů je to výhodný obchod.
Musí být člověk vývojář, aby si takovou aplikaci postavil?
Nemusí, ale pomáhá to. Tuhle napsal QA tester bez předchozí zkušenosti s vývojem aplikací – vibe coding s AI to umožnil, za cenu toho, že se projekt protočil čtyřmi modely, než dostal použitelnou podobu. Pro jednoduchý interní nástroj to takhle funguje; čím je aplikace složitější, tím víc se vyplatí mít poblíž někoho, kdo umí kód přečíst i bez AI.
🎯 Co si odnést
Evidence hardwaru nepadá na tabulce. Padá na tom, že zapsat se do ní stojí víc úsilí, než kolik je člověk v tu chvíli ochotný vydat. Když tohle přijmete jako zadání, řešením přestane být lepší tabulka a stane se jím rozhraní, které je rychlejší než výmluva.
Druhá věc: interní nástroj je ideální první projekt s AI. Nemá klienta, nemá termín a nikdo neumře, když se rozbije. Zato se na něm naučíte, co vibe coding zvládne a kde vás nechá na holičkách – v našem případě to znamenalo čtyři modely, React Native, Google Apps Script a prototyp v Expo Go, který dělá přesně to, co má.
A třetí: aplikace posune hranici, ale nezruší ji. Zbytek je pořád na lidech, případně na zámku.
Jestli vás zajímá, jak AI mění práci QA jako takovou, mrkněte na testování s AI agenty, Claude Code a Maestrem, nebo na přepis legacy aplikace za týden s Claude Code, kde je vidět, kam až se agentní vývoj dá dotáhnout.
Celý příběh i s dotazy z publika najdete v záznamu přednášky. Termíny dalších Ackee Meets sledujte na Eventbritu a přihlaste se k newsletteru – příští takový obsah vám přijde přímo do schránky.
