Programmēšana

Kā pārbaudīt datus, analīzi un datu vizualizācijas

Lietojumprogrammu testēšana ir nobriedusi disciplīna ar rīkiem, kas palīdz kvalitātes nodrošināšanas komandām izstrādāt un automatizēt funkcionālos testus, izpildīt slodzes un veiktspējas testus, veikt statisko kodu analīzi, aptvert API ar vienības testiem un apstiprināt lietojumprogrammas pret zināmām drošības problēmām. Komandas, kas praktizē devops, var īstenot nepārtrauktu testēšanu, iekļaujot visus savus automatizētos testus vai to apakškopu savos CI / CD cauruļvados, un rezultātus izmanto, lai noteiktu, vai būvējums būtu jānogādā mērķa vidē.

Bet visas šīs testēšanas iespējas var viegli ignorēt vienu svarīgu testu kopumu, kas ir kritisks jebkurai lietojumprogrammas apstrādei vai datu prezentēšanai, analītikai vai datu vizualizēšanai.

Vai dati ir precīzi un vai analīze ir derīga? Vai datu vizualizācijas rāda rezultātus, kas ir jēgas priekšmetu ekspertiem? Turklāt, kā komanda veic uzlabojumus datu cauruļvados un datu bāzēs, kā viņiem vajadzētu nodrošināt, lai izmaiņas nekaitētu pakārtotajai lietojumprogrammai vai informācijas panelim?

Pēc manas pieredzes, izstrādājot ar datiem un analītiku bagātinātas lietojumprogrammas, šāda veida testēšana un pārbaude bieži ir otra doma, salīdzinot ar vienības, funkcionālo, veiktspējas un drošības testēšanu. Pārbaudes kritēriju kopu ir arī grūtāk veikt vairāku iemeslu dēļ:

  • Izstrādātājiem, testētājiem un datu zinātniekiem, kuri parasti nav tēmas eksperti, ir grūti pārbaudīt datus un analīzi, jo īpaši par to, kā informācijas paneļus un lietojumprogrammas izmanto, lai izstrādātu ieskatu vai virzītu lēmumu pieņemšanu.
  • Dati paši par sevi ir nepilnīgi, ar zināmām un bieži nezināmām datu kvalitātes problēmām.
  • Mēģinājums iegūt validācijas kārtulas nav mazsvarīgs, jo bieži vien ir kopīgi noteikumi, kas attiecas uz lielāko daļu datu, kam seko noteikumi par dažāda veida neiecietību. Mēģinājums uztvert un kodēt šos noteikumus var būt sarežģīts un sarežģīts piedāvājums lietojumprogrammām un datu vizualizācijām, kas apstrādā lielu apjomu sarežģītu datu kopu.
  • Aktīvas ar datiem pamatotas organizācijas ielādē jaunas datu kopas un pilnveido datu cauruļvadus, lai uzlabotu analīzi un lēmumu pieņemšanu.
  • Datu apstrādes sistēmas bieži ir sarežģītas, un to integrēšanai, pārvaldībai, apstrādei, modelēšanai un rezultātu sniegšanai ir pieejami dažādi rīki.

Pirmo reizi komandas ieinteresētajām pusēm uzrāda sliktus datus vai nederīgu analīzi, parasti tas ir pirmais modināšanas zvans, kas varētu būt vajadzīgs viņu praksei un rīkiem, lai proaktīvi pārbaudītu, diagnosticētu un atrisinātu šīs datu problēmas.

Izpratne par datu izcelsmi un datu kvalitāti

Datu problēmas vislabāk risināt to avotos un izmantojot dažādas datu transformācijas, kas veiktas, ielādējot un apstrādājot datus. Ja avota datiem ir jaunas datu kvalitātes problēmas vai ja datu cauruļvadā ir trūkumi, daudz efektīvāk ir tos identificēt un novērst datu apstrādes procesa sākumā.

Divas prakses un saistītie rīki palīdz šajos jautājumos. Abi ļauj izstrādes un datu komandām identificēt datu problēmas, pirms tās sasniedz pakārtotās datu vizualizācijas un lietojumprogrammas.

Pirmā prakse ietver datu kvalitātes rīkus, kas bieži vien ir papildierīces, lai iegūtu, pārveidotu un ielādētu (ETL), kā arī dažus datu sagatavošanas rīkus. Datu kvalitātes rīki kalpo vairākiem mērķiem, taču viena lieta, ko viņi var darīt, ir identificēt un novērst zināmās datu problēmas. Dažus labojumus var automatizēt, bet citus var atzīmēt kā izņēmumus un nosūtīt datu pārvaldniekiem, lai tos labotu manuāli vai atjauninātu tīrīšanas kārtulas.

Informatica, Talend, IBM, Oracle, Microsoft un daudzi citi piedāvā datu kvalitātes rīkus, kas tiek pievienoti viņu ETL platformām, savukārt datu sagatavošanas rīkiem no Tableau, Alteryx, Paxata, Trifacta un citiem ir datu kvalitātes iespējas.

Otra prakse ir datu cilts. Lai gan datu kvalitāte palīdz identificēt datu problēmas, datu cilts ir prakses un rīku kopums, kas izseko datu izmaiņas un pamatā esošās ieviešanas. Tie palīdz lietotājiem saprast, kur datu dzīves ciklā tiek veikta transformācija, aprēķins vai cita datu manipulācija. Pēc tam datu līnijas rīkus, pārskatus un dokumentāciju var izmantot, lai izsekotu datu cauruļvadā un palīdzētu precīzi noteikt, kur datu plūsmā tika ieviests defekts vai cita problēma.

Zelta datu kopu izmantošana, lai apstiprinātu datu vizualizācijas

Analytics, informācijas paneļi un datu vizualizācijas nedarbojas uz statiskiem datu avotiem. Dati zināmā ātrumā mainās, un tajā pašā laikā izstrādātāji un datu zinātnieki var modificēt pamatā esošās datu plūsmas, algoritmus un vizualizācijas. Apskatot informācijas paneli, ir grūti nošķirt, vai neparedzēta datu problēma ir saistīta ar programmatiskām izmaiņām vai arī tā ir saistīta ar datiem vai datu kvalitātes izmaiņām.

Viens no izmaiņu izolēšanas veidiem ir zināma atdalīšana zeltainidatu kopa, lai palīdzētu apstiprināt datu plūsmas, lietojumprogrammu un datu vizualizācijas izmaiņas. Izmantojot zelta datu kopu, testēšanas grupa var definēt vienības, funkcionālos un veiktspējas testus, lai apstiprinātu un salīdzinātu rezultātus. Testētāji var izpildīt A / B testus, kur A ir rezultāts pirms ieviešanas izmaiņu ieviešanas un B ir rezultāts pēc izmaiņu veikšanas. Pārbaudei vajadzētu parādīt atšķirības izlaide tikai paredzamajās jomās, kur tika mainītas datu plūsmas, modeļi, analīze, biznesa loģika vai vizualizācijas.

Lai gan tas ir samērā vienkāršs jēdziens, to īstenot nav mazsvarīgi.

Pirmkārt, komandām ir jāizveido zelta datu kopas un jāizlemj, kāds datu apjoms un daudzveidība ir visaptveroša pārbaudāmā paraugu kopa. Var būt nepieciešamas arī vairākas datu kopas, lai palīdzētu apstiprināt dažādus datu segmentus, robežnosacījumus vai analītiskos modeļus. Viens rīks, kas komandām var palīdzēt pārvaldīt testa datus, ir Delphix testa datu pārvaldībai; arī citi pārdevēji piedāvā šo iespēju.

Otrkārt, kad būs izveidotas zelta datu kopas, testēšanas komandām var būt nepieciešamas papildu vides vai rīki, lai pārslēgtu pamatā esošos datu avotus savā vidē. Piemēram, testētāji var vēlēties pārbaudīt, izmantojot zelta datu kopas, un pēc tam otro reizi palaist datus, kas ir ražošanas datu kopija. Komandas, kas darbojas mākoņu vidēs un izmanto infrastruktūras koda rīkus, piemēram, Leļļu, Šefpavārs un Ansible, var konstruēt un nojaukt vairākas testēšanas vides šiem dažādiem mērķiem.

Visbeidzot, testēšanas komandām ir nepieciešami rīki, lai ieviestu datu un rezultātu A / B testēšanu. Daudzas man pazīstamas komandas to dara manuāli, rakstot SQL vaicājumus un pēc tam salīdzinot rezultātus. Ja datu kopas un testi ir vienkārši, šī pieeja var būt pietiekama. Bet, ja jāpārbauda vairāki datu plūsmas punkti, visticamāk, jums būs nepieciešami īpaši rīki, lai centralizētu testa vaicājumus, tos automatizētu un izmantotu pārskatus, lai apstiprinātu izmaiņas. Viens rīks, QuerySurge, ir īpaši paredzēts A / B testēšanas ieviešanai pret datu plūsmām, datu bāzēm un dažiem biznesa inteliģences rīkiem.

Efektīvs darbs ar priekšmetu ekspertiem

Kādā brīdī jums jāiesaista priekšmetu eksperti, lai izmantotu jaunas un atjauninātas datu vizualizācijas un sniegtu atsauksmes. Viņiem jāpalīdz atbildēt uz jautājumiem par to, vai analīze ir derīga un noderīga, lai izstrādātu ieskatu vai palīdzētu ar datiem pamatotā lēmumu pieņemšanā.

Problēma, ar kuru saskaras daudzas komandas, ir pietiekami daudz laika no priekšmetu ekspertiem, lai piedalītos šajā testēšanā. Mēģinot bieži pārbaudīt un izvietot izmaiņas, tas var būt ievērojams izaicinājums.

Lai efektīvi izmantotu viņu laiku, es iesaku trīs atsevišķas darbības:

  • Īstenojiet pēc iespējas vairāk datu kvalitātes, datu līnijas un A / B testēšanas zelta datu kopās. Pirms iesaistāt priekšmetu ekspertus, veiciet saprātīgas pūles, lai apstiprinātu, ka neapstrādāti un aprēķināti dati ir pareizi. Tas jādara ar pārliecību, lai jūs varētu ekspertiem izskaidrot un ideāli ilustrēt, ka pamatā esošie dati, pārveidojumi un aprēķini ir precīzi - tāpēc varat būt pārliecināts, ka viņiem nav nepieciešams ieguldīt ievērojamu laiku, lai tos manuāli pārbaudītu.
  • Noformējiet datu vizualizācijas, lai palīdzētu ekspertiem pārskatīt un apstiprināt datus un analīzi. Dažas vizualizācijas var būt A / B testu rezultāti, bet citām vajadzētu būt vizualizācijām, kas atklāj zema līmeņa datus. Ieviešot lielāka mēroga datu, algoritmu, modeļu vai vizualizācijas izmaiņas, bieži vien palīdz ieviest šīs kvalitātes kontroles datu vizualizācijas, lai palīdzētu ekspertiem ātri veikt validāciju.
  • Jūs vēlaties, lai priekšmetu eksperti veiktu lietotāju pieņemšanas testēšanu (UAT) pabeigtajām lietojumprogrammām un datu vizualizācijām. Līdz brīdim, kad viņi sasniedz šo soli, viņiem jābūt pilnīgi pārliecinātiem, ka dati un analīze ir derīga.

Šis pēdējais solis ir nepieciešams, lai noteiktu, vai vizualizācijas ir efektīvas datu izpētē un atbildēs uz jautājumiem: vai vizualizāciju ir viegli izmantot? Vai ir pieejami pareizie izmēri, lai izpētītu datus? Vai vizualizācija veiksmīgi palīdz atbildēt uz jautājumiem, uz kuriem tā tika izstrādāta, lai atbildētu?

Šajā procesa laikā jūs pārbaudāt lietotāja pieredzi un pārliecinieties, ka informācijas paneļi un lietojumprogrammas ir optimizētas. Šo kritisko soli var veikt daudz efektīvāk, ja ir izpratne un uzticēšanās pamatā esošajiem datiem un analītikai.

$config[zx-auto] not found$config[zx-overlay] not found