Samostojno gostovano testiranje programske opreme z UI v obratovanju

Neuspešen regresijski test je redko le rdeč vnos na seznamu. Lahko pomeni, da skladiščni delavec ne more natisniti dobavnice, administrativni sodelavec je obtičal v sistemu za upravljanje naročil, ali pa je posodobitev pokvarila funkcijo, ki je leta zanesljivo delovala. Prav tam nastopi samostojno gostovano testiranje programske opreme z UI: avtomatizira ponavljajoče se preglede, ne da bi po nepotrebnem izpostavljalo občutljive testne podatke, posnetke zaslona ali notranje procese aplikacije zunanjim platformam.

Za ekipe s spletnimi aplikacijami in namiznim programjem Windows je to več kot vprašanje zasebnosti podatkov. Gre za nadzor nad testnim okoljem, sledljive dnevnike napak in testno operacijo, ki se prilega lastnemu izdajnemu procesu. UI lahko razbremeni, vendar ne nadomesti niti čistih testnih primerov niti strokovne odgovornosti.

Kdaj je smiselno samostojno gostovano testiranje programske opreme z UI

Klasična avtomatizacija testov je zelo učinkovita, vendar zahteva vzdrževanje. Selektorji se spreminjajo, vmesniki se razvijajo, testni podatki morajo biti na voljo, sporočila o napakah pa je treba razvrstiti. Zato mnoge ekipe avtomatizirajo le majhen del svojih kritičnih procesov — ali pa se pred izdajo še vedno pretežno zanašajo na ročno testiranje.

Sistemi, podprti z UI, lahko to vrzel zožijo. Berejo vmesnike bolj kontekstualno, izvajajo vnaprej določene procese, prepoznavajo vidna odstopanja in povzemajo rezultate v razumljivem jeziku. To postane še posebej dragoceno pri aplikacijah, ki ne sestojijo le iz klicev API, temveč iz pravih uporabniških vmesnikov: prijav, vnosnih mask, odobritev, tiskalnih pogovornih oken in oken Windows.

Samostojno gostovanje je smiselno, kadar testna izvajanja zadevajo zaupne informacije. To se ne nanaša le na osebne podatke. Sem sodijo tudi interne cene, imena strank, premiki artiklov, posnetki zaslona administrativnih vmesnikov, dostopni podatki za testne račune ali informacije o še neobjavljenih funkcijah. Kdor uporablja zunanje storitve UI, naj skrbno preveri, kateri podatki zapuščajo lastno omrežje, kako dolgo se hranijo in kdo ima dostop do njih.

Obstajajo pa tudi primeri, ko gostovana platforma zadostuje. Za javno marketinško stran brez resničnih podatkov o strankah, z malo izdajami in obvladljivo globino testiranja, jo je mogoče postaviti hitreje. Prava odločitev je odvisna od zahtev po zaščiti, pokrajine aplikacij, obstoječih kompetenc in pogostosti sprememb — ne od splošnega načela oblaka ali UI.

Kaj ostane v lastnem okolju

V samostojno gostovanem testnem okolju izvajanje testov poteka na infrastrukturi, ki jo nadzoruje podjetje: v lastnem podatkovnem centru, v zasebnem oblačnem okolju ali na namenskem strežniku v okviru dogovorjenega operativnega modela. Lokacija strežnika ni edini odločilni dejavnik. Pomemben je celoten pretok podatkov.

Pregledno zgrajen sistem obdeluje testne korake, seje brskalnika ali namizja, posnetke zaslona, dnevnike in testna poročila znotraj tega nadzorovanega okolja. Testne račune je mogoče ustvariti z minimalnimi pravicami. Dostopne podatke je mogoče upravljati ločeno. Omrežni dostop je mogoče omejiti na dejansko potrebne sisteme. Pri posebej občutljivih aplikacijah je lahko namenski testni najemnik bolj smiseln kot testiranje z resničnimi podatki, podobnimi produkcijskim.

To samodejno ne ščiti pred napakami. Lokalno delujoča rešitev zahteva posodobitve, koncepte pravic, varnostne kopije in jasne odgovornosti. Kdor enkrat namesti strežnik in nato nanj pozabi, nima varne testne infrastrukture, temveč dodatno operativno breme. Prednost je v tem, da ta naloga ostane predvidljiva in preverljiva.

Testni podatki si zaslužijo enako zaščito kot aplikacija

Razprave o varnosti se pogosto osredotočajo na izvorno kodo. V praksi testni artefakti razkrijejo vsaj toliko. Posnetek zaslona lahko pokaže podatke o strankah, notranje izraze in podrobnosti procesov. Video testnega izvajanja lahko razkrije strukturo sistema zaledne pisarne. Datoteka dnevnika lahko vsebuje URL-je, sporočila o napakah ali tehnične številke različic.

Zato je treba določiti obdobja hrambe. Vsakega uspešnega izvajanja ni treba trajno shraniti. Obratno pa je lahko določena zgodovina zelo koristna pri preverjanju napak in izdajah. Pravice dostopa do poročil spadajo v isti koncept pravic kot dostop do same aplikacije.

Ne bi smel vsak pregled voditi UI

Najmočnejša testna okolja kombinirajo različne metode. Prijavo z zaklepanjem računa po več neuspešnih poskusih je mogoče natančno in hitro testirati z determinističnimi avtomatiziranimi testi. Tudi vmesniki, izračuni, pravila baze podatkov in pravice imajo korist od jasnih pričakovanj: vnos A mora dati rezultat B.

UI je še posebej koristna, kadar sta v ospredju uporabniški vmesnik, delovni proces in perspektiva uporabnika. Na primer, testna naloga lahko preveri, ali dispečer ustvari naročilo, dodeli pot, ustvari dokument in pravilno prejme status nazaj. UI se lahko premika po aplikaciji, zajema dokumente in razumljivo dokumentira, na kateri točki se je proces prekinil. Za trajnostno testno operacijo naj sodelujejo štiri ravni:

Enotni in integracijski testi zavarujejo poslovno logiko, vmesnike in obdelavo podatkov zgodaj v razvojnem procesu.
Testi UI preverjajo ponovljive poti klikov in konkretna pričakovanja v spletnih ali namiznih aplikacijah.
Z UI podprti pregledi delovnih procesov ocenjujejo resnične operativne poti in vidne rezultate z vidika uporabnika.
Raziskovalni domenski testi razkrijejo posebne primere, ki jih še nihče ni opisal kot fiksno pravilo.

UI ne bi smel odločati, ali je logika oblikovanja cen poslovno pravilna, če so pravila nejasno dokumentirana. Prav tako ne more smiselno izvesti natančnega navodila. „Preveri odpremo“ ni robusten opis testa. „Ustvari naročilo s tremi postavkami, ustvari odpremno nalepko in preveri, ali se status spremeni v odpremljeno“ je preverljivo navodilo.

Od demonstracije do robustnega testnega delovanja

Najpogostejša napaka pri testiranju z UI je prezgodnji začetek s prevelikim obsegom. Impresivna demonstracija z eno samo prijavo pove malo o tem, ali bo sistem čez šest mesecev zavaroval izdaje. Veliko bolj smiseln je ožji začetek z dvema do petimi delovnimi procesi, katerih odpoved povzroči dejanske stroške ali ustvari ponavljajoč se ročni napor testiranja. V skladiščnem ali logističnem sistemu bi to lahko bili prevzem blaga, prenos zalog, komisioniranje naročil in ustvarjanje dobavnice. V administrativni programski opremi pa prej prijava, sprememba pravic, vnos naročila in odobritev računa. Dobri kandidati so pogosti procesi s stabilnimi pravili in jasno vidnimi rezultati.

Nato vsak delovni proces potrebuje določeno izhodišče. Kateri podatki morajo biti prisotni? Kateri testni račun se uporablja? Ali sme test pošiljati e-pošto, tiskati nalepke ali dostopati do vmesnikov? Kaj se ponastavi po izvajanju? Brez teh pravil avtomatizacija hitro ustvari nered v testnih podatkih ali blokira druge ekipe.

Tudi ocenjevanje rezultatov naj bo stopnjevano. Manjkajoč gumb je običajno jasna napaka. Nekoliko drugačna formulacija v besedilu namiga ne mora samodejno blokirati izdaje. Tu pomagajo pragovi zaupanja in jasna ločitev med avtomatiziranim obvestilom, ročnim pregledom in dejanskimi blokirnimi merili. Testno poročilo naj ne poroča le „neuspešno“, temveč naj vsebuje izveden korak, vidno stanje, časovni žig in ustrezne dokaze.

Vloga posnetkov zaslona, videoposnetkov in poročil v navadnem besedilu

Test, ki izpiše le tehnično sporočilo o napaki, prenese delo na razvojno ekipo. Poslovni oddelki pogosto ne morejo veliko izkoristiti takih informacij. Dobri dokazi kombinirajo tehnično natančnost s kontekstom: kaj bi se moralo zgoditi? Kaj se je dejansko zgodilo? Kje je to vidno? Katera različica je bila testirana?

Posnetki zaslona in posnetki bistveno skrajšajo usklajevanje. Vodji QA ni treba najprej poskušati reproducirati napake, lastnik izdelka pa takoj vidi, ali je prekinitev poslovno relevantna. Hkrati je treba take artefakte shranjevati selektivno. Uspešni testi običajno zahtevajo manj dokazov kot neuspešne ali kritične izdaje.

Poročilo v navadnem besedilu ne nadomešča dnevnikov. Je most med delovanjem, poslovnim oddelkom in razvojem. Zlasti pri srednje velikih ekipah, kjer so iste osebe odgovorne za procese in sprejemajo odločitve, ta most preprečuje nepotrebno prevajalsko delo.

Delovanje, vzdrževanje in realistična pričakovanja

Samostojno gostovana avtomatizacija testov ni izdelek, ki teče brez pozornosti po namestitvi. Aplikacije se spreminjajo. Brskalniki se posodabljajo. Testni podatki izgubljajo veljavnost. Nove ravni pravic, captche, večfaktorska avtentikacija ali spremenjena tiskalna pogovorna okna vplivajo na testna izvajanja.

To ni argument proti avtomatizaciji. Je argument za jasen urnik vzdrževanja. S testnimi primeri je treba ravnati kot s produkcijsko kodo: verzionirano, pregledano in zavestno prilagojeno ob spremembah. Če delovni proces trikrat zapored odpove zaradi namerne spremembe UI, UI ni problem. Takrat manjka povezava med razvojem, načrtovanjem izdaj in vzdrževanjem testov.

S COCO se softify.pro za ta namen zanaša na namenski, samostojno gostovan strežnik UI, ki testira spletne in Windows aplikacije, beleži dokaze in jasno razvršča rezultate. Vendar ključna točka ostaja integracija v vsakodnevne delovne procese: kateri procesi so zavarovani, kdo pregleduje odstopanja in kdaj sme izdaja nadaljevati?

Najboljši prvi korak torej ni kupiti ali konfigurirati čim več testov. Izberite delovni proces, kjer bi spregledana napaka jutri dejansko povzročila delo v skladišču, servisu ali računovodstvu. Ko je ta delovni proces testiran zanesljivo, sledljivo in pod lastnim nadzorom podatkov, UI preneha biti tehnologija zaradi tehnologije in postane opazna razbremenitev.