Integračné testovanie potvrdzuje, že náhrada za SaaS správne spolupracuje s okolitými systémami. Jednotlivá funkcia môže prejsť vlastnými testami, no širší pracovný postup môže napriek tomu zlyhať, pretože údaje, oprávnenia, časovanie alebo chybové správanie sa na rozhraní líšia. Test preto pokrýva samotné prepojenie a pozorovateľný výsledok, ktorý musí vyvolať.
Čo pokrýva integračné testovanie
Rozsah začína každou API integráciou, naplánovaným prenosom, prepojením identity a nadväzujúcim reportom. Užitočný test odosiela reprezentatívne vstupy cez reálne rozhranie a kontroluje výsledný stav na oboch stranách. Preveruje tiež, ako systémy reagujú, keď je požiadavka neúplná, opakovaná, oneskorená alebo zamietnutá.
| Oblasť testovania | Príklad kontroly | Dôkaz |
|---|---|---|
| Mapovanie údajov | Požadované polia si zachovávajú svoj význam | Porovnané zdrojové a cieľové záznamy |
| Autentifikácia | Platné prístupové údaje získajú zamýšľaný prístup | Zaznamenaný výsledok prístupu |
| Riešenie chýb | Zamietnuté požiadavky zostávajú viditeľné a obnoviteľné | Chybový log a výsledok obnovy |
| Časovanie | Udalosti prichádzajú v požadovanom poradí | Transakčná stopa s časovou pečiatkou |
| End-to-end proces | Obchodná úloha sa dokončí naprieč systémami | Schválený scenár pracovného postupu |
Testy by mali presne určiť, ktorý systém vlastní očakávaný výsledok. Bez tohto pravidla je síce možné nesúlad spozorovať, ale chýba jasný základ na rozhodnutie, ktorá hodnota je správna.
Prečo sa rozhrania SaaS testujú ťažko
Dodávateľ môže poskytovať produkčné API bez reprezentatívnej neprodukčnej služby. Testovacie účty môžu mať odlišné údaje, oprávnenia, limity alebo funkcie. Niektoré rozhrania nedokážu simulovať zlyhania alebo poskytovať rovnaké časovanie udalostí ako produkcia. Tieto obmedzenia nezbavujú potreby testovania, ale menia povahu dostupných dôkazov.
Testovacie prostredie môže hostiť náhradu a kontrolované verzie jej závislostí. Tam, kde reálne rozhranie dodávateľa nie je k dispozícii, môžu očakávané správanie pokryť zaznamenané odpovede alebo testovacie dvojníky (test doubles). Tieto náhrady sa však musia priebežne overovať voči skutočnému rozhraniu, pretože sa môžu odchýliť od reálneho správania dodávateľa.
Budovanie testovacej sady
Sada integračných testov kopíruje rozsah náhrady:
- Zostavte zoznam prepojení: zahrňte API, súbory, identifikačné služby, naplánované úlohy a manuálne importy.
- Definujte požadované výsledky: prepojte každé rozhranie s obchodným pracovným postupom alebo kontrolným mechanizmom.
- Pripravte reprezentatívne údaje: pokryte bežné záznamy, hraničné prípady, oprávnenia a zlyhania.
- Otestujte oba smery: overte požiadavky, odpovede, spätné volania (callbacks) a prípadné zosúladenie.
- Zaznamenajte schválenie: uchovajte výsledok, vlastníka a nevyriešené výnimky pre rozhodnutie o ostrom prechode.
Ako testovanie podporuje ostrý prechod
Integračné testovanie poskytuje dôkaz o tom, či sa prepojená práca môže presunúť na nové riešenie. Finálna sada testov by sa mala spustiť po pripravení konfigurácie, prístupových údajov a cieľových koncových bodov, a následne znova, keď ich zmení postupnosť ostrého prechodu.
Skúsenosť opísaná v článku o testovaní naprieč nástrojmi SaaS bez testovacieho režimu vysvetľuje, prečo môže integračné riziko zostať skryté až do produkcie. Plán náhrady toto obmedzenie explicitne priznáva, definuje, čo sa dá otestovať vopred, a priraďuje kroky monitorovania a obnovy pre to, čo je možné potvrdiť až počas samotného prepnutia.
