Samostojno gostovano testiranje vs oblak

Neuspešen regresijski test je redko le rdeč vnos na nadzorni plošči. Lahko pomeni, da zaslon za odpremo v skladišču ustvarja napačne nalepke, portal za stranke preneha sprejemati naročila, ali se Windows aplikacija sesuje med predajo izmene. Vprašanje self hosted testing vs cloud zato ne zadeva infrastrukture kot samostojnega namena. Gre za to, katerih podatkov se dotika testni proces, kdo ga nadzoruje, in kako zanesljivo deluje v resničnih poslovnih pogojih.

Platforme za testiranje v oblaku so lahko hitro pripravljene za uporabo. Za mnoge ekipe je to smiselno, zlasti ko testirajo javno dostopno spletno aplikacijo in kratkoročno potrebujejo dodatno izvajalno zmogljivost. Samostojno gostovana testna okolja pa zahtevajo premišljeno tehnično postavitev. Vendar vračajo nadzor nad testnimi podatki, omrežnimi potmi, pravicami dostopa, in delovanjem nazaj podjetju. Prava izbira ni odvisna od splošnega načela, temveč od aplikacije, tveganja, in razpoložljive operativne sposobnosti.

Self Hosted Testing vs Cloud: Za kaj resnično gre

Razprava se pogosto preveč zoži na začetne stroške. Rešitev v oblaku deluje ceneje, ker ni treba nabavljati strežnikov niti postavljati okolja. Lasten testni strežnik na prvi pogled deluje zahtevnejši, ker je treba načrtovati operacijski sistem, posodobitve, nadzor dostopa, spremljanje, in varnostne kopije.

Ta izračun je pomanjkljiv. Odločilni so tekoči stroški testne strategije: čakalne dobe pred izdajami, iskanje napak po nepopolnih testnih izvedbah, usklajevanje z varstvom podatkov in informacijsko varnostjo, ter posledice napačne uvedbe. Če ekipa redno preučuje občutljive poslovne aplikacije, je lahko dodatno organizacijsko breme zunanjih storitev večje od upravljanja jasno omejenega lastnega okolja.

Tudi "oblak" ni enoten model. Nekateri ponudniki shranjujejo le testne dnevnike, drugi obdelujejo posnetke zaslona, video posnetke, dostopne podatke, vsebino DOM, ali omrežni promet. Pri testiranju, podprtem z UI, lahko poleg tega slikovni in besedilni podatki pridejo do zunanjih modelov ali podizvajalcev za oceno. Kdor gleda samo lokacijo podatkovnega centra, pogosto spregleda pomembnejše vprašanje: kateri podatki dejansko zapustijo lastno nadzorno cono, in katera pogodbena in izbrisna pravila zanje veljajo?

Kdaj je testiranje v oblaku smiselna izbira

Testiranje v oblaku ni v osnovi varnostna težava, samostojno gostovanje pa ni samodejno boljša arhitektura. Za novo, javno dostopno spletno trgovino ali tržno platformo je lahko okolje v oblaku zelo primerno. Ekipa lahko hitro pokrije različice brskalnikov in naprav, ne da bi vzdrževala lastne izvajalne stroje. Pri nihajoči testni obremenitvi je elastično skaliranje prav tako resnična prednost.

Tudi majhne razvojne ekipe z malo, jasno anonimiziranimi testnimi podatki pogosto pridobijo z upravljano storitvijo. Svojega časa ne bi smele vlagati v upravljanje platforme, ko je ozko grlo pravzaprav v manjkajočih testnih primerih, nejasnih merilih sprejemljivosti, ali nestabilnih testnih podatkih. Lasten strežnik teh težav ne reši.

Oblak se posebej dobro prilega, kadar aplikacija ne potrebuje notranjega omrežnega dostopa, kadar v testnih tokovih ni osebnih ali poslovno kritičnih podatkov, in kadar je kratek čas priprave pomembnejši od globokega nadzora infrastrukture. Predpogoj je skrbna konfiguracija: ločeni testni računi, brez resničnih podatkov strank, omejeni žetoni, sledljivi roki hrambe, in jasen koncept pravic.

Kdaj postane samostojno gostovano testiranje smiselnejše

Drugače je pri aplikacijah, ki so dostopne le v omrežju podjetja ali prikazujejo operativne ključne procese. Programska oprema za skladišče ali proizvodnjo pogosto obdeluje premike artiklov, dostavne naslove, zaloge, serijske številke, in cenovno logiko. Testna izvedba lahko pri tem ustvari posnetke zaslona naročilnih mask, prenese dokumente, ali se prijavi z uporabniškimi vlogami. Taki podatki se ne bi smeli neopazno razpršiti po več zunanjih sistemih.

Samostojno gostovano testiranje omogoča postavitev izvajanja testov blizu aplikacije. Testni strežnik lahko teče v istem omrežnem segmentu ali v nadzorovani DMZ. Pravila požarnega zidu se nastavijo ciljno, notranjih aplikacij ni treba odpirati za zunanjo storitev, in dnevniki ostajajo pod lastnim upravljanjem. To je pogosto še posebej pomembno za namizne aplikacije Windows, saj so redko zasnovane za zunanje platforme za testiranje.

Za regulirane panoge, večje zahteve strank, ali notranje varnostne smernice je to arhitekturo pogosto lažje preveriti. To ne pomeni, da vsaka presoja samodejno uspe. Tudi lasten strežnik potrebuje upravljanje popravkov, šifriranje, pravice po vlogah, varnostne kopije, in dokumentirane operativne postopke. Razlika je v tem, da podjetje te odločitve sprejema samo in jih lahko dokaže.

Pri softify.pro je zato COCO zasnovan kot namenski, samostojno gostovan strežnik UI: testne izvedbe za spletne in Windows aplikacije se izvajajo lokalno, dokazi se beležijo, rezultati pa se ocenjujejo v razumljivem jeziku. To ne nadomešča strokovne odobritve. Zagotavlja pa, da lahko testni promet, posnetki zaslona, in ocene ostanejo tam, kjer podjetje ohranja suverenost nad podatki.

Pravilna primerjava stroškov: delovanje proti trenju

Smiselna primerjava obsega več kot ceno licence proti ceni strojne opreme. V oblaku nastajajo ponavljajoči se stroški glede na uporabnika, testno minuto, vzporedno izvajanje, ali porabo UI. Ti stroški so sprva predvidljivi, vendar lahko z naraščajočo pokritostjo testov znatno narastejo. Temu se pridružijo morebitni izdatki za pogodbe enterprise, sporazume o obdelavi podatkov, in varnostne preglede.

Pri samostojnem gostovanju nastajajo naložbe v infrastrukturo in postavitev. To lahko vključuje virtualne stroje, shrambo, omrežni dostop, spremljanje, in čas tehnično odgovorne ekipe. Ti stroški ostajajo tudi takrat, ko teče malo testov. Za projekt z redkimi izdajami je to dober argument proti predimenzionirani lastni rešitvi.

Pri rednem regresijskem testiranju se slika spremeni. Če je treba vsak teden preverjati iste poslovno kritične delovne tokove, so predvidljive notranje zmogljivosti pogosto bolj ekonomične kot spremenljivi stroški platforme in ročne zanke odobritve. Pristop postane še posebej dragocen, ko se testni primeri uporabljajo leta in se razvijajo skupaj s poslovno aplikacijo. Vzdrževalnost je takrat pomembnejša od hitrega, a težko obvladljivega začetka.

Kakovost ni odvisna od modela gostovanja

Pogosta zmota pravi: testi v oblaku naj bi bili samodejno sodobnejši, samostojno gostovani testi samodejno stabilnejši. Nobeno od tega ne drži. Kakovost testov izhaja iz smiselnih scenarijev, odpornih testnih podatkov, stabilnih identifikatorjev v vmesniku, in jasnih pričakovanj glede rezultata.

Test ne bi smel le preveriti, ali je gumb mogoče klikniti. Za obdelavo naročil lahko na primer ustvari naročilo, preveri razpoložljivo količino, ustvari dobavnico, in zagotovi, da lahko postopek odobri prava vloga. Pri namiznem programu lahko preveri uvoz datoteke, obravnavo napak, in izpis dokumenta. Šele takšni tokovi od konca do konca pokažejo, ali je sprememba poškodovala resnični proces.

UI lahko pri tem pomaga prepoznati spremembe vmesnika, razumljivo dokumentirati korake, in določiti prioritete anomalij. Vendar se ne bi smel spremeniti v črno skrinjico. Ekipe potrebujejo posnetke zaslona ali druge dokaze, sledljive testne korake, in določene pragove za to, kdaj se rezultat šteje za uspešnega, negotovega, ali neuspešnega. Prav pri vizualnih preverjanjih je prag zaupanja smiseln, da majhna, pričakovana odstopanja postavitve ne blokirajo vsake izdaje.

Operativna vprašanja pred odločitvijo

Preden se ekipa odloči, bi morala konkretno zabeležiti pot testne izvedbe. Kje teče test? V katere sisteme se prijavlja? Katere podatke vidi? Kje se shranjujejo posnetki zaslona, dnevniki, in poročila? Kdo sme brati, brisati, ali izvažati rezultate? Ta vprašanja so bolj praktična od pavšalne odločitve za ali proti oblaku.

Enako pomembna je odgovornost po zagonu. Kdo posodablja brskalnike in testne agente? Kdo reagira, ko poteče certifikat? Kako se rotirajo dostopni podatki? In kako se zagotovi, da test po nesreči ne sproži resnične knjižbe odpreme ali obvestila stranki? Dobra avtomatizacija testov potrebuje ločena okolja in zaščitne mehanizme, ne le dobrih skript.

Hibridni model je lahko smiseln. Javni vmesniki in široko razporejena preverjanja brskalnikov tečejo v oblaku, medtem ko notranji strokovni procesi ostajajo na lastnem testnem strežniku. To zmanjša operativno breme, ne da bi občutljive tokove pavšalno predali navzven. Predpogoj je jasna meja med obema področjema, ne nepregledno mešano delovanje.

Najboljša odločitev je tista, ki ustreza dejanskemu tveganju in lastni operativni realnosti. Če preglednica proces še vedno zanesljivo nosi, iz nje ni treba narediti velikega sistema. Če pa testni podatki in notranje aplikacije spadajo v poslovno jedro, nadzor ni razkošje, temveč stvarna zahteva za zanesljivo programsko opremo.