Kako provjeriti valjanost podataka, analitike i vizualizacija podataka

Testiranje aplikacija disciplina je sazrijevanja s alatima koji pomažu timovima za osiguranje kvalitete da razviju i automatiziraju funkcionalne testove, izvrše testove opterećenja i performansi, izvrše statičku analizu koda, omotaju API-je jedinstvenim testovima i provjere valjanosti aplikacija protiv poznatih sigurnosnih problema. Timovi koji vježbaju devops mogu provoditi kontinuirano testiranje tako što će uključiti sve ili podskup svojih automatiziranih testova u svoje CI / CD cjevovode i pomoću rezultata utvrditi treba li gradnju isporučiti u ciljno okruženje.

Ali sve ove mogućnosti testiranja mogu lako zanemariti jedan ključni skup testova koji je presudan za bilo koju obradu aplikacija ili predstavljanje podataka, analitiku ili vizualizacije podataka.

Jesu li podaci točni i jesu li analitički podaci valjani? Pokazuju li vizualizacije podataka rezultate koji imaju smisla stručnjacima za predmet? Nadalje, kako tim poboljšava cjevovode podataka i baze podataka, kako bi trebali osigurati da promjene ne naštete aplikaciji ili nadzornoj ploči niže u toku?

Prema mom iskustvu u razvoju aplikacija bogatih podacima i analitikom, ova vrsta testiranja i provjere valjanosti je često druga stvar u usporedbi s jedinstvenim, funkcionalnim, izvedbenim i sigurnosnim testiranjem. To je također teže izvršiti iz nekoliko razloga:

  • Provjera valjanosti podataka i analitike teška je za programere, testere i znanstvenike koji obično nisu stručnjaci za predmet, posebno o tome kako se nadzorne ploče i aplikacije koriste za razvoj uvida ili poticanje donošenja odluka.
  • Podaci su sami po sebi nesavršeni, s poznatim i često nepoznatim problemima s kvalitetom podataka.
  • Pokušaj hvatanja pravila provjere valjanosti nije trivijalan jer često postoje uobičajena pravila koja se primjenjuju na većinu podataka nakon kojih slijede pravila za različite vrste odstupanja. Pokušaj hvatanja i kodiranja ovih pravila može biti težak i složen prijedlog za aplikacije i vizualizacije podataka koji obrađuju velike količine složenih skupova podataka.
  • Aktivne organizacije vođene podacima učitavaju nove skupove podataka i razvijaju cjevovode podataka kako bi poboljšale analitiku i donošenje odluka.
  • Sustavi za obradu podataka često su složeni, s različitim alatima za integriranje, upravljanje, obradu, modeliranje i isporuku rezultata.

Timovi koji prvi puta prezentiraju loše podatke ili nevaljanu analitiku dionicima obično su prvi poziv za uzbunu da bi njihovi postupci i alati mogli biti potrebni za testiranje, dijagnosticiranje i proaktivno rješavanje ovih problema s podacima.

Razumijevanje loze podataka i kvalitete podataka

Problemi s podacima najbolje se rješavaju u njihovim izvorima i kroz različite transformacije podataka izvršene prilikom učitavanja i obrade podataka. Ako izvorni podaci imaju novih problema s kvalitetom podataka ili ako su u cjevovod podataka uneseni nedostaci, daleko je učinkovitije identificirati ih i riješiti rano u cjevovodu za obradu podataka.

Dvije prakse i srodni alati pomažu u rješavanju ovih problema. Oboje omogućavaju razvojnim timovima i timovima podataka prepoznavanje problema s podacima prije nego što dođu do vizualizacija podataka i aplikacija.

Prva praksa uključuje alate za kvalitetu podataka koji su često dodane mogućnosti za izdvajanje, transformiranje i učitavanje (ETL), kao i neke alate za pripremu podataka. Alati za kvalitetu podataka imaju više svrha, ali jedna stvar koju mogu učiniti jest prepoznati i ispraviti poznate probleme s podacima. Neke se ispravke mogu automatizirati, dok se druge mogu označiti kao iznimke i poslati upraviteljima podataka radi ručnog ispravljanja ili ažuriranja pravila čišćenja.

Informatica, Talend, IBM, Oracle, Microsoft i mnogi drugi nude alate za kvalitetu podataka koji se uključuju u njihove ETL platforme, dok alati za pripremu podataka iz Tableau, Alteryx, Paxata, Trifacta i drugi imaju mogućnosti kvalitete podataka.

Druga praksa je loza podataka. Iako kvaliteta podataka pomaže identificirati probleme s podacima, linija podataka skup je praksi i alata koji prate promjene podataka i temeljne implementacije. Oni pomažu korisnicima da razumiju gdje se u životnom ciklusu podataka provodi transformacija, izračun ili druga manipulacija podacima. Alati, izvješća i dokumentacija za liniju podataka mogu se koristiti za vraćanje u podatkovni cjevovod i pomoć u određivanju gdje je u protoku podataka uveden nedostatak ili drugi problem.

Korištenje zlatnih skupova podataka za provjeru vizualizacija podataka

Analitika, nadzorne ploče i vizualizacije podataka ne rade na statičkim izvorima podataka. Podaci se mijenjaju određenom brzinom, a istodobno programeri i znanstvenici mogu mijenjati temeljne protoke podataka, algoritme i vizualizacije. Kada gledate nadzornu ploču, teško je razdvojiti je li nepredviđeni problem s podacima uzrokovan programskom promjenom ili je povezan s podacima ili promjenom kvalitete podataka.

Jedan od načina za izoliranje promjena je odvajanje poznatog zlatnog skupa podataka koji pomaže u provjeri valjanosti promjena u protoku podataka, primjeni i vizualizaciji podataka. Koristeći zlatni skup podataka, tim za testiranje može definirati jedinstvene, funkcionalne i testove performansi za provjeru valjanosti i usporedbu rezultata. Ispitivači mogu izvoditi A / B testove, gdje je A izlaz prije uvođenja promjena implementacije, a B rezultat nakon izvršenih promjena. Test bi trebao pokazati razlike u izlaznim rezultatima u očekivanim područjima u kojima su promijenjeni protoci podataka, modeli, analitika, poslovna logika ili vizualizacije.

Iako je ovo relativno jednostavan koncept, nije ga trivijalno provesti.

Prvo, timovi moraju stvoriti zlatne skupove podataka i odlučiti koji volumen i raznolikost podataka čine sveobuhvatan uzorak za testiranje. Također može zahtijevati više skupova podataka koji pomažu u provjeri valjanosti različitih segmenata podataka, rubnih uvjeta ili analitičkih modela. Jedan od alata koji može pomoći timovima u upravljanju test podacima je Delphix za upravljanje test podacima; i drugi dobavljači također nude ovu mogućnost.

Drugo, jednom kada se stvore zlatni skupovi podataka, timovi za testiranje mogu zahtijevati dodatna okruženja ili alate za prebacivanje temeljnih izvora podataka u svoja okruženja. Na primjer, testeri će možda htjeti testirati zlatne skupove podataka, a zatim drugi put pokrenuti podatke koji su replika proizvodnih podataka. Timovi koji djeluju u oblaku i koriste alate za infrastrukturu kao kod poput Puppet, Chef i Ansible mogu konstruirati i srušiti više okruženja za testiranje u te različite svrhe.

Na kraju, ispitni timovi trebaju alate za provođenje A / B testiranja podataka i rezultata. Mnogi timovi koje znam rade to ručno pisanjem SQL upita i usporedbom rezultata. Ako su skupovi podataka i testovi jednostavni, ovaj pristup može biti dovoljan. Ali ako treba testirati više točaka u protoku podataka, vjerojatno će vam trebati namjenski alati za centraliziranje probnih upita, automatizaciju i korištenje izvješća za provjeru valjanosti promjena. Jedan alat, QuerySurge, posebno je dizajniran za provođenje A / B testiranja prema protocima podataka, bazama podataka i nekim alatima poslovne inteligencije.

Učinkovit rad s predmetnim stručnjacima

U jednom trenutku morate uključiti stručnjake za predmetnu temu da bi koristili nove i ažurirane vizualizacije podataka i pružali povratne informacije. Moraju pomoći u odgovoru na pitanja je li analitika valjana i korisna za razvijanje uvida ili pomoć u donošenju odluka na temelju podataka.

Problem s kojim se susreću mnogi timovi jest dobivanje dovoljno vremena od stručnjaka za predmet za sudjelovanje u ovom testiranju. To može biti značajan izazov kada se često pokušavaju testirati i primijeniti promjene.

Da biste učinkovito iskoristili svoje vrijeme, preporučujem tri odvojene aktivnosti:

  • Provedite što je moguće više kvalitete podataka, podrijetla podataka i A / B testiranja na zlatnim skupovima podataka. Prije nego što uključite stručnjake za predmet, uložite razumne napore kako biste provjerili jesu li neobrađeni i izračunati podaci točni. To treba učiniti s povjerenjem kako biste stručnjacima za predmet mogli objasniti i idealno ilustrirati da su temeljni podaci, transformacije i izračuni točni - pa možete biti sigurni da ne trebaju uložiti značajno vrijeme da bi ih ručno testirali.
  • Dizajnirajte vizualizaciju podataka kako biste pomogli stručnjacima da pregledaju i provjere podatke i analitiku. Neke vizualizacije mogu biti izlazi iz A / B testova, dok bi druge trebale biti vizualizacije koje izlažu podatke niske razine. Prilikom primjene promjena podataka, algoritma, modela ili vizualizacije većih razmjera, često pomaže imati ove vizualizacije podataka s kontrolom kvalitete kako bi pomogli stručnjacima u izvođenju brzih provjera valjanosti.
  • Želite da predmetni stručnjaci izvrše testiranje prihvaćanja korisnika (UAT) na završnim aplikacijama i vizualizacijama podataka. Dok dosegnu ovaj korak, trebali bi imati puno povjerenje da su podaci i analitika valjani.

Ovaj posljednji korak potreban je kako bi se utvrdilo jesu li vizualizacije učinkovite u istraživanju podataka i odgovorima na pitanja: Je li vizualizacija jednostavna za upotrebu? Jesu li dostupne ispravne dimenzije za uvrtanje u podatke? Pomaže li vizualizacija odgovor na pitanja na koja je zamišljena?

U ovom trenutku procesa testirate korisničko iskustvo i osiguravate optimizaciju nadzornih ploča i aplikacija. Ovaj kritični korak može se učiniti mnogo učinkovitije kada postoji razumijevanje i povjerenje u temeljne podatke i analitiku.