Programų testavimas yra bręsta disciplina su įrankiais, kurie padeda kokybės užtikrinimo komandoms kurti ir automatizuoti funkcinius testus, vykdyti apkrovos ir našumo testus, atlikti statinio kodo analizę, apvynioti API su vieneto testais ir patvirtinti programas atsižvelgiant į žinomas saugumo problemas. Komandos, praktikuojančios „devops“, gali vykdyti nuolatinius bandymus, įtraukdamos visus ar dalį automatinių bandymų į savo CI / CD vamzdynus, ir naudodamiesi rezultatais nustato, ar statinį reikia pristatyti į tikslinę aplinką.
Tačiau visos šios testavimo galimybės gali lengvai nepaisyti vieno svarbiausio testų rinkinio, kuris yra labai svarbus bet kuriai programai apdorojant ar pateikiant duomenis, analizę ar duomenų vizualizaciją.
Ar duomenys tikslūs ir ar analizė galioja? Ar duomenų vizualizacijose rodomi dalyko ekspertų prasmės rezultatai? Be to, kai komanda patobulina duomenų perdavimo linijas ir duomenų bazes, kaip jie turėtų užtikrinti, kad pakeitimai nepakenktų tolesnei programai ar informacijos suvestinei?
Iš mano patirties kuriant daug duomenų ir analizės programų, tokio tipo bandymai ir patvirtinimas dažnai yra antra mintis, palyginti su įrenginio, funkciniais, našumo ir saugumo testais. Tai taip pat yra sudėtingesnis bandymo kriterijų rinkinys dėl kelių priežasčių:
- Duomenis ir analizę sunku patvirtinti kūrėjams, testuotojams ir duomenų mokslininkams, kurie paprastai nėra dalyko ekspertai, ypač apie tai, kaip informacijos suvestinės ir programos naudojamos įžvalgoms kurti ar sprendimų priėmimui skatinti.
- Duomenys savaime yra netobuli, su žinomomis ir dažnai nežinomomis duomenų kokybės problemomis.
- Bandymas užfiksuoti patvirtinimo taisykles nėra trivialus, nes dažniausiai yra bendros taisyklės, kurios taikomos daugumai duomenų, o po to - skirtingų tipų pašalinių nuostatų taisyklės. Bandymas užfiksuoti ir užkoduoti šias taisykles gali būti sudėtingas ir sudėtingas pasiūlymas programoms ir duomenų vizualizacijoms, apdorojančioms didelius sudėtingų duomenų rinkinių kiekius.
- Aktyvios duomenų valdomos organizacijos krauna naujus duomenų rinkinius ir tobulina duomenų perdavimo linijas, kad pagerintų analizę ir sprendimų priėmimą.
- Duomenų apdorojimo sistemos dažnai yra sudėtingos, jose yra skirtingos integravimo, valdymo, apdorojimo, modeliavimo ir rezultatų pateikimo priemonės.
Pirmą kartą komandos pateikia suinteresuotosioms šalims netinkamus duomenis ar netinkamą analizę. Tai dažniausiai yra pirmasis žadintuvas, kurio gali prireikti jų praktikai ir įrankiams, norint išbandyti, diagnozuoti ir aktyviai išspręsti šias duomenų problemas.
Suprasti duomenų kilmę ir duomenų kokybę
Duomenų problemos geriausiai sprendžiamos jų šaltiniuose ir atliekant įvairias duomenų transformacijas, atliekamas įkeliant ir apdorojant duomenis. Jei šaltinio duomenims kyla naujų duomenų kokybės problemų arba jei duomenų perdavimo linijoje yra trūkumų, tai žymiai efektyviau juos nustatyti ir išspręsti ankstyvame duomenų apdorojimo etape.
Šiomis problemomis padeda dvi praktikos ir susijusios priemonės. Tiek kūrimo, tiek duomenų komandos gali nustatyti duomenų problemas, kol jos pasiekia tolesnes duomenų vizualizacijas ir programas.
Pirmoji praktika apima duomenų kokybės įrankius, kurie dažnai yra papildomos galimybės išskleisti, transformuoti ir įkelti (ETL), taip pat kai kuriuos duomenų paruošimo įrankius. Duomenų kokybės įrankiai naudojami keliems tikslams, tačiau vienas dalykas, kurį jie gali padaryti, yra nustatyti ir ištaisyti žinomas duomenų problemas. Kai kurie taisymai gali būti automatizuoti, o kiti gali būti pažymėti kaip išimtys ir išsiųsti duomenų tvarkytojams taisyti rankiniu būdu arba atnaujinti valymo taisykles.
„Informatica“, „Talend“, „IBM“, „Oracle“, „Microsoft“ ir daugelis kitų siūlo duomenų kokybės įrankius, kurie prijungiami prie jų ETL platformų, o duomenų paruošimo įrankiai iš „Tableau“, „Alteryx“, „Paxata“, „Trifacta“ ir kitų turi duomenų kokybės galimybes.
Antroji praktika yra duomenų kilmė. Nors duomenų kokybė padeda nustatyti duomenų problemas, duomenų linija yra praktikos ir įrankių rinkinys, stebintis duomenų pokyčius ir pagrindinius diegimus. Jie padeda vartotojams suprasti, kur duomenų gyvavimo cikle yra vykdoma transformacija, skaičiavimai ar kitos manipuliacijos duomenimis. Tuomet duomenų linijos įrankiai, ataskaitos ir dokumentai gali būti naudojami norint atsekti duomenis į dujotiekį ir padėti tiksliai nustatyti, kur duomenų sraute buvo nustatytas defektas ar kita problema.
Auksinių duomenų rinkinių naudojimas duomenų vizualizacijai patvirtinti
„Analytics“, informacijos suvestinės ir duomenų vizualizacijos neveikia statiniuose duomenų šaltiniuose. Duomenys keičiasi tam tikru greičiu, tuo pačiu metu kūrėjai ir duomenų mokslininkai gali modifikuoti pagrindinius duomenų srautus, algoritmus ir vizualizacijas. Kai žiūrite į informacijos suvestinę, sunku atskirti, ar nenumatyta duomenų problema kilo dėl programinių pakeitimų, ar ji susijusi su duomenimis ar duomenų kokybės pokyčiais.
Vienas iš pokyčių išskyrimo būdų yra atskirti žinomą auksinisduomenų rinkinys, padedantis patvirtinti duomenų srauto, programos ir duomenų vizualizavimo pokyčius. Naudodama auksinį duomenų rinkinį, bandymų komanda gali apibrėžti vieneto, funkcinius ir našumo testus, kad patvirtintų ir palygintų išvestis. Testuotojai gali atlikti A / B testus, kur A yra išvestis prieš įvedant įgyvendinimo pakeitimus, o B yra išvestis atlikus pakeitimus. Testas turėtų parodyti tik tuos laukiamų laukų, kuriuose buvo pakeisti duomenų srautai, modeliai, analizė, verslo logika ar vizualizacijos, skirtumus.
Nors tai yra gana paprasta koncepcija, ją įgyvendinti nėra trivialu.
Pirma, komandos turi sukurti auksinius duomenų rinkinius ir nuspręsti, kokia duomenų apimtis ir įvairovė sudaro išsamų bandinių rinkinį. Taip pat gali prireikti kelių duomenų rinkinių, kurie padėtų patvirtinti skirtingus duomenų segmentus, ribines sąlygas ar analitinius modelius. Vienas įrankis, kuris gali padėti komandoms valdyti bandymų duomenis, yra „Delphix“, skirtas testų duomenų valdymui; kiti pardavėjai taip pat siūlo šią galimybę.
Antra, sukūrus auksinius duomenų rinkinius, bandymų grupėms gali prireikti papildomų aplinkų ar įrankių, kad jie galėtų pakeisti pagrindinius duomenų šaltinius savo aplinkoje. Pavyzdžiui, bandytojai gali norėti išbandyti auksinius duomenų rinkinius, tada antrą kartą paleisti duomenis, kurie yra gamybos duomenų kopija. Komandos, veikiančios debesų aplinkoje ir naudojančios infrastruktūros kodo įrankius, tokius kaip „Lėlė“, „Chef“ ir „Ansible“, gali sukurti ir sugriauti kelias bandymų aplinkas šiems skirtingiems tikslams.
Galiausiai bandymų grupėms reikalingi įrankiai, kad būtų galima atlikti duomenų ir rezultatų A / B testavimą. Daugelis mano pažįstamų komandų tai daro rankiniu būdu, rašydami SQL užklausas ir tada palygindami rezultatus. Jei duomenų rinkiniai ir bandymai yra paprasti, šio metodo gali pakakti. Bet jei reikia išbandyti kelis duomenų srauto taškus, greičiausiai jums reikės specialių įrankių, kad būtų galima centralizuoti bandymų užklausas, jas automatizuoti ir naudoti ataskaitas, kad patvirtintumėte pakeitimus. Vienas įrankis, „QuerySurge“, yra specialiai sukurtas A / B testavimui pagal duomenų srautus, duomenų bazes ir kai kurias verslo žvalgybos priemones įgyvendinti.
Efektyvus darbas su dalyko ekspertais
Tam tikru metu turite įtraukti dalyko ekspertus, kad jie naudotųsi naujomis ir atnaujintomis duomenų vizualizacijomis ir teiktų atsiliepimus. Jie turi padėti atsakyti į klausimus, ar analizė yra tinkama ir naudinga plėtojant įžvalgas ar pagalbą priimant duomenis.
Problema, su kuria susiduria daugelis komandų, gauna pakankamai laiko iš dalyko ekspertų dalyvauti šiame teste. Tai gali būti nemenkas iššūkis bandant dažnai išbandyti ir įdiegti pakeitimus.
Norint efektyviai išnaudoti savo laiką, rekomenduoju tris atskiras veiklas:
- Įgyvendinkite kuo daugiau duomenų kokybės, duomenų linijos ir A / B testavimo auksinių duomenų rinkiniuose. Prieš įtraukdami dalyko ekspertus, darykite pagrįstas pastangas patvirtinti, kad neapdoroti ir apskaičiuoti duomenys yra teisingi. Tai reikia padaryti užtikrintai, kad galėtumėte paaiškinti ir idealiai parodyti dalyko ekspertams, kad pagrindiniai duomenys, transformacijos ir skaičiavimai yra tikslūs, todėl galite būti tikri, kad jiems nereikia skirti daug laiko rankiniam jų patikrinimui.
- Sukurkite duomenų vizualizacijas, kad dalykinių dalykų ekspertai galėtų peržiūrėti ir patvirtinti duomenis ir analizę. Kai kurios vizualizacijos gali būti A / B testų išvestys, o kitos turėtų būti vizualizacijos, atskleidžiančios žemo lygio duomenis. Diegiant didesnio masto duomenų, algoritmo, modelio ar vizualizacijos pakeitimus, dažnai padeda įdiegti šias kokybės kontrolės duomenų vizualizacijas, kad dalyko ekspertai galėtų greitai atlikti patikrinimus.
- Norite, kad dalyko ekspertai atliktų galutinių programų ir duomenų vizualizacijų naudotojų priėmimo testus (UAT). Kai jie pasieks šį žingsnį, jie turėtų būti visiškai įsitikinę, kad duomenys ir analizė yra teisingi.
Paskutinis žingsnis reikalingas norint nustatyti, ar vizualizacijos yra veiksmingos tiriant duomenis ir atsakant į klausimus: ar vizualizaciją lengva naudoti? Ar yra teisingi matmenys, kad būtų galima gilintis į duomenis? Ar vizualizacija sėkmingai padeda atsakyti į klausimus, į kuriuos buvo atsakyta?
Šiuo proceso metu bandote vartotojo patirtį ir užtikrinate, kad prietaisų skydeliai ir programos būtų optimizuotos. Šį kritinį žingsnį galima atlikti kur kas efektyviau, kai yra supratimas ir pasitikėjimas pagrindiniais duomenimis ir analitika.
