Ako prevziať automatizované testy od dodávateľa a vedieť, že fungujú
Dodávateľ ukáže úspešný beh automatizovaných testov a odovzdá repozitár s kódom. Vedúci vývoja, produktový vlastník alebo vedúci testovania však potrebuje vedieť aj to, čo testy overujú, či ich jeho tím dokáže spustiť a ako rozpozná problém. Pri prevzatí preto odporúčame spojiť kontrolu dohodnutého rozsahu s praktickou skúškou používania. Výsledkom má byť podklad na rozhodnutie, či dodávka spĺňa dohodnuté podmienky a čo ešte potrebuje dopracovať.
Prečo úspešná ukážka nestačí
Úspešný výsledok môže pôsobiť presvedčivo, hoci test iba otvoril stránku, vyplnil formulár a stlačil tlačidlo. Ak nikde neporovná očakávaný výsledok so skutočným, takáto ukážka neposkytuje dôkaz o správnosti dokončenej objednávky. Rovnako z nej nevyplýva, že rovnakú sadu spustíte s vlastnými prístupmi.
Navrhujeme preto prevzatie pripraviť ako pracovné stretnutie nad konkrétnou verziou dodávky. Dopredu určte scenáre, prostredie a dôkazy, ktoré budete kontrolovať. Dodávateľ potom vie, čo má pripraviť, a klient posudzuje rovnaké podmienky, aké boli dohodnuté počas realizácie.
Dohodnite pokrytie tak, aby sa dalo overiť
Zoznam „prihlásenie, košík, objednávka“ je dobrý začiatok rozhovoru, ale slabý podklad na prevzatie. Pri každej oblasti zapíšte používateľskú situáciu, vstupné podmienky a očakávaný výsledok. Pri prihlásení napríklad rozlíšte platné údaje, nesprávne heslo a účet bez požadovaného oprávnenia, pokiaľ patria do zadania.
Ku každej dohodnutej situácii priraďte identifikátor testu alebo skupiny testov. Pri kontrole sa tak dá prejsť od požiadavky k spustiteľnému scenáru a následne k jeho výsledku. Počet testovacích súborov je doplnková informácia; jeden súbor môže obsahovať viac kontrol aj viac variantov rovnakého prípadu.
| Čo si dohodnúť | Príklad podkladu na prevzatie |
|---|---|
| Očakávané správanie | Objednávka obsahuje zvolený počet kusov a správny stav |
| Rozsah prostredí | Menované prehliadače a určené testovacie prostredie |
| Dáta a prístupy | Testovací účet, príprava položiek a postup obnovy dát |
| Výnimky | Nepokryté platby alebo iná integrácia s uvedeným dôvodom |
| Výsledok behu | Odkaz na report s verziou testov a aplikácie |
Ak sa rozsah počas práce zmení, upravte aj tento zoznam. Preskočený scenár označte a vysvetlite jeho dopad. Súčasťou prevzatia môže byť dohodnutá výnimka, ale čitateľ výsledku potrebuje vedieť, ktoré riziko zostáva bez overenia.
Skontrolujte, čo test naozaj porovnáva
Kontrola, ktorá porovná skutočnosť s očakávaním a pri nesúlade označí problém, sa v testovacom kóde nazýva assertion. Pri webovom teste môže overovať text potvrdenia, počet položiek alebo stav uloženého záznamu. Požiadajte dodávateľa, aby na vybranom scenári ukázal súvislosť medzi požiadavkou, konkrétnou kontrolou a hlásením pri jej zlyhaní.
Napríklad Playwright ponúka cez expect kontroly textu, viditeľnosti či hodnôt. Vybrané kontroly webových prvkov opakuje do splnenia podmienky alebo uplynutia časového limitu. Toto čakanie na výsledok odlišujte od opätovného spustenia celého testu. Dokumentácia assertions v Playwright.
Samotná viditeľnosť potvrdenia ešte nemusí zodpovedať celej požiadavke. Ak zadanie zahŕňa uloženie objednávky so správnymi položkami, navrhujeme overiť aj príslušné údaje cez dohodnuté rozhranie. Technické riešenie môže byť rôzne; podstatné je, aby sa kontrolovala vlastnosť, kvôli ktorej test vznikol.
Nech testy spustí aj tím klienta
Pri skúške použite pracovné prostredie klienta a dohodnutý postup, ktorý bude tím používať po odovzdaní. Ak zahŕňa spúšťanie z repozitára, poverený kolega si stiahne dohodnutú verziu kódu, pripraví závislosti podľa návodu, nastaví prístupy a spustí zvolenú sadu. Dodávateľ môže vysvetľovať nejasnosti; chýbajúce kroky priebežne doplňte do dokumentácie.
Ak sa testy majú spúšťať cez webové rozhranie alebo plánovač, nech tím vyskúša túto cestu vrátane dohodnutého nastavenia prostredia, dát a prístupu k výsledkom. Aj pri takomto spúšťaní overte potrebné oprávnenia a dostupnosť návodu.
Overte aj opakovaný beh po obnove dát. Test, ktorý potrebuje ručne pripravený účet alebo záznam, môže byť použiteľný, ak je táto podmienka dohodnutá a zdokumentovaná. Problémom pri prevzatí je neznáma závislosť, ktorú vie zabezpečiť iba autor.
Ak je súčasťou dodávky spúšťanie v automatizovanom procese zostavenia a nasadenia, teda v CI/CD, vyskúšajte aj tento spôsob. Samostatný beh z notebooku túto časť zadania nenahrádza. Pri každom dohodnutom spôsobe skontrolujte dostupnosť reportu a to, či príslušný systém viditeľne oznámi neúspešný výsledok.
Modelový príklad: overenie zlyhania objednávky
Nasledujúca situácia je modelová, nejde o výsledok konkrétneho klienta. Tím preberá webový test objednávky dvoch kusov testovacieho produktu. Dohodnuté kontroly overujú počet kusov a stav prijatej objednávky. Platby, expedícia a správy skutočným zákazníkom sú mimo tejto skúšky a v prostredí sú bezpečne oddelené.
Najprv nechajte scenár prejsť so správnymi dátami. Následne sa s vývojárom dohodnite na dočasnej úprave odpovede iba pre tento scenár v izolovanom testovacom prostredí: odpoveď bude obsahovať jeden kus namiesto dvoch. Očakávanie v teste zostane nezmenené. Overte, že test zlyhá na kontrole počtu kusov a report ukáže rozdiel medzi očakávaním a skutočnosťou.
Takáto skúška preveruje reakciu konkrétnej kontroly na chybný výsledok. Pretože používa upravenú odpoveď, sama nepotvrdzuje správnosť spolupráce všetkých reálnych služieb. Tú overujte osobitným dohodnutým scenárom. Ak vhodnú zmenu nemožno bezpečne izolovať, zvoľte s dodávateľom inú kontrolu alebo samostatnú testovaciu inštanciu.
Po skúške odstráňte dočasnú úpravu, obnovte dáta a zopakujte pôvodný scenár. Do záznamu z prevzatia uložte oba výsledky aj opis zmeny. Úpravy robte iba v dohodnutom testovacom prostredí s neprodukčnými dátami.
Zlyhanie musí dať tímu použiteľný podklad
Pri neúspešnom behu overte, či kolega bez pomoci autora nájde názov scenára, zlyhanú kontrolu, očakávaný a skutočný výsledok, čas behu a verziu aplikácie. Podrobný záznam priebehu testu, teda log, má pomôcť určiť ďalší krok vyšetrovania. Report nemusí sám rozhodnúť, či ide o chybu produktu, testu alebo prostredia.
Pri riešení v Playwright môže diagnostiku dopĺňať zaznamenaný priebeh, označovaný ako trace. Trace Viewer umožňuje prehliadať zaznamenané akcie, chyby a sieťové požiadavky; nahrávanie treba nastaviť. Konkrétne výstupy preto dohodnite podľa dodávaného riešenia. Dokumentácia Trace Viewer.
Skontrolujte aj výsledky po opakovaní. Playwright rozlišuje test úspešný na prvý pokus, test úspešný až po opakovaní ako flaky a test, ktorý zlyhal aj po opakovaniach. Dokumentácia opakovaných behov. Pri prevzatí zobrazte pôvodné zlyhania a dohodnite riešenie nestability, aj keď posledný pokus prešiel.
Súčasťou skúšky má byť aj otvorenie výstupov bežným oprávneným členom tímu. Dohodnite ich umiestnenie, dobu uchovania a prístup. Použite testovacie údaje a skontrolujte, že výstupy neobsahujú prihlasovacie tajomstvá.
Dokumentácia, podľa ktorej sa dá pracovať
Odovzdajte návod spolu s kódom a overte ho počas samostatného spustenia. Mal by pokrývať potrebné verzie nástrojov, inštaláciu, konfiguráciu, prípravu dát, spustenie celej sady aj vybraného scenára a otvorenie výsledkov podľa dohodnutého spôsobu používania. Hodnoty hesiel doň nepatria; popíšte spôsob ich bezpečného získania.
Technický kolega by mal vedieť nájsť aj miesto na doplnenie kontroly alebo úpravu očakávania po dohodnutej zmene aplikácie. Pomôže krátky opis členenia kódu a závislostí. Dokumentáciu posudzujte podľa toho, či umožní vykonať bežnú úlohu, nie podľa počtu strán.
Prevzatie dodávky a následná údržba
Pri prevzatí zaznamenajte konkrétnu verziu kódu, prostredie, skontrolované scenáre, dôkazy a otvorené výhrady. Ku každej výhrade určte dopad, zodpovednú osobu a ďalší termín rozhodnutia. Ak chýba dohodnutá podstatná kontrola alebo klient nedokáže sadu spustiť dohodnutým spôsobom, pomenujte to ako nedokončenú časť dodávky.
Budúce zmeny aplikácie, dát a závislostí potrebujú samostatnú dohodu o údržbe. Rozlíšte dopracovanie nesplneného zadania od nových požiadaviek po prevzatí a dohodnite spôsob ich evidencie. Priebežné rozdelenie zodpovednosti podrobnejšie rozoberá článok kto vlastní automatizované testy.
Kontrolný zoznam a prvý krok
Na stretnutie si pripravte tento stručný zoznam:
- Každá dohodnutá situácia má dohľadateľný test a očakávaný výsledok.
- Vybrané kontroly zodpovedajú skutočnému cieľu scenára.
- Tím klienta spustil dohodnutú sadu podľa odovzdaného návodu.
- Podmienky prípravy a obnovy dát sú známe.
- Bezpečne vyvolané zlyhanie sa prejavilo v príslušnej kontrole aj reporte.
- Opakovania a preskočené testy sú viditeľné a vysvetlené.
- Výstupy vie otvoriť a prvotne vyhodnotiť oprávnený člen tímu.
- Otvorené výhrady a hranice následnej údržby sú zapísané.
Takéto prevzatie dáva tímu overiteľný základ na používanie dodávky: pozná rozsah kontrol, vie spustiť testy a má podklady na riešenie zlyhaní. Ako prvý krok vyberte jeden dôležitý scenár a s dodávateľom dohodnite jeho úspešný aj zámerne neúspešný priebeh. Na tomto príklade si overíte, či sú podmienky prevzatia dostatočne konkrétne.