Jak převzít automatizované testy od dodavatele a vědět, že fungují
Dodavatel ukáže úspěšný běh automatizovaných testů a předá repozitář s kódem. Vedoucí vývoje, produktový vlastník nebo vedoucí testování však potřebuje vědět také to, co testy ověřují, zda je jeho tým dokáže spustit a jak rozpozná problém. Při převzetí proto doporučujeme spojit kontrolu dohodnutého rozsahu s praktickou zkouškou používání. Výsledkem má být podklad pro rozhodnutí, zda dodávka splňuje dohodnuté podmínky a co ještě potřebuje dopracovat.
Proč úspěšná ukázka nestačí
Úspěšný výsledek může působit přesvědčivě, přestože test pouze otevřel stránku, vyplnil formulář a stiskl tlačítko. Pokud nikde neporovná očekávaný výsledek se skutečným, taková ukázka neposkytuje důkaz o správnosti dokončené objednávky. Stejně tak z ní nevyplývá, že stejnou sadu spustíte s vlastními přístupy.
Navrhujeme proto připravit převzetí jako pracovní schůzku nad konkrétní verzí dodávky. Předem určete scénáře, prostředí a důkazy, které budete kontrolovat. Dodavatel pak ví, co má připravit, a klient posuzuje stejné podmínky, jaké byly dohodnuty během realizace.
Dohodněte pokrytí tak, aby se dalo ověřit
Seznam „přihlášení, košík, objednávka“ je dobrý začátek rozhovoru, ale slabý podklad pro převzetí. U každé oblasti zapište uživatelskou situaci, vstupní podmínky a očekávaný výsledek. U přihlášení například rozlište platné údaje, nesprávné heslo a účet bez požadovaného oprávnění, pokud patří do zadání.
Ke každé dohodnuté situaci přiřaďte identifikátor testu nebo skupiny testů. Při kontrole se tak dá přejít od požadavku ke spustitelnému scénáři a následně k jeho výsledku. Počet testovacích souborů je doplňková informace; jeden soubor může obsahovat více kontrol i více variant stejného případu.
| Co si dohodnout | Příklad podkladu pro převzetí |
|---|---|
| Očekávané chování | Objednávka obsahuje zvolený počet kusů a správný stav |
| Rozsah prostředí | Jmenované prohlížeče a určené testovací prostředí |
| Data a přístupy | Testovací účet, příprava položek a postup obnovy dat |
| Výjimky | Nepokryté platby nebo jiná integrace s uvedeným důvodem |
| Výsledek běhu | Odkaz na report s verzí testů a aplikace |
Pokud se rozsah během práce změní, upravte i tento seznam. Přeskočený scénář označte a vysvětlete jeho dopad. Součástí převzetí může být dohodnutá výjimka, ale čtenář výsledku potřebuje vědět, které riziko zůstává bez ověření.
Zkontrolujte, co test opravdu porovnává
Kontrola, která porovná skutečnost s očekáváním a při nesouladu označí problém, se v testovacím kódu nazývá assertion. U webového testu může ověřovat text potvrzení, počet položek nebo stav uloženého záznamu. Požádejte dodavatele, aby na vybraném scénáři ukázal souvislost mezi požadavkem, konkrétní kontrolou a hlášením při jejím selhání.
Například Playwright nabízí prostřednictvím expect kontroly textu, viditelnosti či hodnot. Vybrané kontroly webových prvků opakuje do splnění podmínky nebo uplynutí časového limitu. Toto čekání na výsledek odlišujte od opětovného spuštění celého testu. Dokumentace assertions v Playwright.
Samotná viditelnost potvrzení ještě nemusí odpovídat celému požadavku. Pokud zadání zahrnuje uložení objednávky se správnými položkami, navrhujeme ověřit také příslušné údaje přes dohodnuté rozhraní. Technické řešení může být různé; podstatné je, aby se kontrolovala vlastnost, kvůli které test vznikl.
Ať testy spustí také tým klienta
Při zkoušce použijte pracovní prostředí klienta a dohodnutý postup, který bude tým používat po předání. Pokud zahrnuje spouštění z repozitáře, pověřený kolega si stáhne dohodnutou verzi kódu, připraví závislosti podle návodu, nastaví přístupy a spustí zvolenou sadu. Dodavatel může vysvětlovat nejasnosti; chybějící kroky průběžně doplňte do dokumentace.
Pokud se testy mají spouštět přes webové rozhraní nebo plánovač, ať tým vyzkouší tuto cestu včetně dohodnutého nastavení prostředí, dat a přístupu k výsledkům. I při takovém spouštění ověřte potřebná oprávnění a dostupnost návodu.
Ověřte také opakovaný běh po obnově dat. Test, který potřebuje ručně připravený účet nebo záznam, může být použitelný, pokud je tato podmínka dohodnutá a zdokumentovaná. Problémem při převzetí je neznámá závislost, kterou dokáže zajistit pouze autor.
Pokud je součástí dodávky spouštění v automatizovaném procesu sestavení a nasazení, tedy v CI/CD, vyzkoušejte také tento způsob. Samostatný běh z notebooku tuto část zadání nenahrazuje. U každého dohodnutého způsobu zkontrolujte dostupnost reportu a to, zda příslušný systém viditelně oznámí neúspěšný výsledek.
Modelový příklad: ověření selhání objednávky
Následující situace je modelová, nejde o výsledek konkrétního klienta. Tým přebírá webový test objednávky dvou kusů testovacího produktu. Dohodnuté kontroly ověřují počet kusů a stav přijaté objednávky. Platby, expedice a zprávy skutečným zákazníkům jsou mimo tuto zkoušku a v prostředí jsou bezpečně oddělené.
Nejprve nechte scénář projít se správnými daty. Následně se s vývojářem dohodněte na dočasné úpravě odpovědi pouze pro tento scénář v izolovaném testovacím prostředí: odpověď bude obsahovat jeden kus místo dvou. Očekávání v testu zůstane nezměněné. Ověřte, že test selže na kontrole počtu kusů a report ukáže rozdíl mezi očekáváním a skutečností.
Taková zkouška prověřuje reakci konkrétní kontroly na chybný výsledek. Protože používá upravenou odpověď, sama nepotvrzuje správnost spolupráce všech reálných služeb. Tu ověřujte samostatným dohodnutým scénářem. Pokud vhodnou změnu nelze bezpečně izolovat, zvolte s dodavatelem jinou kontrolu nebo samostatnou testovací instanci.
Po zkoušce odstraňte dočasnou úpravu, obnovte data a zopakujte původní scénář. Do záznamu z převzetí uložte oba výsledky i popis změny. Úpravy provádějte pouze v dohodnutém testovacím prostředí s neprodukčními daty.
Selhání musí dát týmu použitelný podklad
Při neúspěšném běhu ověřte, zda kolega bez pomoci autora najde název scénáře, kontrolu, která selhala, očekávaný a skutečný výsledek, čas běhu a verzi aplikace. Podrobný záznam průběhu testu, tedy log, má pomoci určit další krok šetření. Report nemusí sám rozhodnout, zda jde o chybu produktu, testu nebo prostředí.
U řešení v Playwright může diagnostiku doplňovat zaznamenaný průběh označovaný jako trace. Trace Viewer umožňuje procházet zaznamenané akce, chyby a síťové požadavky; nahrávání je potřeba nastavit. Konkrétní výstupy proto dohodněte podle dodávaného řešení. Dokumentace Trace Viewer.
Zkontrolujte také výsledky po opakování. Playwright rozlišuje test úspěšný na první pokus, test úspěšný až po opakování jako flaky a test, který selhal i po opakováních. Dokumentace opakovaných běhů. Při převzetí zobrazte původní selhání a dohodněte řešení nestability, i když poslední pokus prošel.
Součástí zkoušky má být také otevření výstupů běžným oprávněným členem týmu. Dohodněte jejich umístění, dobu uchování a přístup. Použijte testovací údaje a zkontrolujte, že výstupy neobsahují přihlašovací tajemství.
Dokumentace, podle které se dá pracovat
Předejte návod spolu s kódem a ověřte ho při samostatném spuštění. Měl by pokrývat potřebné verze nástrojů, instalaci, konfiguraci, přípravu dat, spuštění celé sady i vybraného scénáře a otevření výsledků podle dohodnutého způsobu používání. Hodnoty hesel do něj nepatří; popište způsob jejich bezpečného získání.
Technický kolega by měl dokázat najít také místo pro doplnění kontroly nebo úpravu očekávání po dohodnuté změně aplikace. Pomůže krátký popis členění kódu a závislostí. Dokumentaci posuzujte podle toho, zda umožní provést běžný úkol, nikoli podle počtu stran.
Převzetí dodávky a následná údržba
Při převzetí zaznamenejte konkrétní verzi kódu, prostředí, zkontrolované scénáře, důkazy a otevřené výhrady. Ke každé výhradě určete dopad, zodpovědnou osobu a další termín rozhodnutí. Pokud chybí dohodnutá podstatná kontrola nebo klient nedokáže sadu spustit dohodnutým způsobem, pojmenujte to jako nedokončenou část dodávky.
Budoucí změny aplikace, dat a závislostí potřebují samostatnou dohodu o údržbě. Rozlište dopracování nesplněného zadání od nových požadavků po převzetí a dohodněte způsob jejich evidence. Průběžné rozdělení odpovědnosti podrobněji rozebírá článek kdo vlastní automatizované testy.
Kontrolní seznam a první krok
Na schůzku si připravte tento stručný seznam:
- Každá dohodnutá situace má dohledatelný test a očekávaný výsledek.
- Vybrané kontroly odpovídají skutečnému cíli scénáře.
- Tým klienta spustil dohodnutou sadu podle předaného návodu.
- Podmínky přípravy a obnovy dat jsou známé.
- Bezpečně vyvolané selhání se projevilo v příslušné kontrole i reportu.
- Opakování a přeskočené testy jsou viditelné a vysvětlené.
- Výstupy dokáže otevřít a předběžně vyhodnotit oprávněný člen týmu.
- Otevřené výhrady a hranice následné údržby jsou zapsané.
Takové převzetí dává týmu ověřitelný základ pro používání dodávky: zná rozsah kontrol, dokáže spustit testy a má podklady pro řešení selhání. Jako první krok vyberte jeden důležitý scénář a s dodavatelem dohodněte jeho úspěšný i záměrně neúspěšný průběh. Na tomto příkladu si ověříte, zda jsou podmínky převzetí dostatečně konkrétní.