Testing av applikasjoner er en moden disiplin med verktøy som hjelper kvalitetssikringsteam å utvikle og automatisere funksjonstester, kjøre belastnings- og ytelsestester, utføre statisk kodeanalyse, pakke API-er med enhetstester og validere applikasjoner mot kjente sikkerhetsproblemer. Team som praktiserer devops kan implementere kontinuerlig testing ved å inkludere alle eller en delmengde av sine automatiserte tester i deres CI / CD-rørledninger og bruke resultatene til å avgjøre om en build skal leveres til målmiljøet.
Men alle disse testmulighetene kan enkelt ignorere ett avgjørende sett med tester som er kritisk for enhver applikasjonsbehandling eller presentasjon av data, analyser eller datavisualiseringer.
Er dataene nøyaktige og er analysene gyldige? Viser datavisualiseringene resultater som gir mening for fageksperter? Når et team forbedrer datarørledninger og databaser, hvordan skal de dessuten sikre at endringer ikke skader et nedstrøms program eller dashbord?
I min erfaring med å utvikle data- og analyserike applikasjoner er denne typen testing og validering ofte en andre tanke sammenlignet med enhets-, funksjonelle, ytelses- og sikkerhetstesting. Det er også et vanskeligere sett med testkriterier å gjøre av flere grunner:
- Validering av data og analyse er vanskelig for utviklere, testere og dataforskere som vanligvis ikke er fageksperter, spesielt når det gjelder dashbord og applikasjoner som brukes til å utvikle innsikt eller drive beslutningstaking.
- Data i seg selv er ufullkomne, med kjente og ofte ukjente problemer med datakvaliteten.
- Å prøve å fange valideringsregler er ikke trivielt fordi det ofte er vanlige regler som gjelder for de fleste data etterfulgt av regler for forskjellige typer avvikere. Å prøve å fange og kode for disse reglene kan være et vanskelig og komplekst forslag for applikasjoner og datavisualiseringer som behandler store mengder komplekse datasett.
- Aktive datadrevne organisasjoner laster inn nye datasett og utvikler datarørledninger for å forbedre analyse og beslutningstaking.
- Databehandlingssystemer er ofte komplekse, med forskjellige verktøy for å integrere, administrere, behandle, modellering og levere resultater.
Førstegangsteamene presenterer dårlige data eller ugyldig analyse for interessenter, er vanligvis den første vekkeren om at deres praksis og verktøy kan være nødvendig for å teste, diagnostisere og løse disse dataproblemene proaktivt.
Forstå datarad og datakvalitet
Dataproblemer løses best ved kildene og gjennom de forskjellige datatransformasjonene som utføres ved lasting og behandling av dataene. Hvis kildedataene har nye problemer med datakvaliteten, eller hvis det er feil introdusert i datarørledningen, er det langt mer effektivt å identifisere og løse disse tidlig i databehandlingsrørledningen.
To fremgangsmåter og relaterte verktøy hjelper til med disse problemene. Begge gjør det mulig for utviklings- og datateam å identifisere dataproblemer før de når nedstrøms datavisualiseringer og applikasjoner.
Den første øvelsen involverer datakvalitetsverktøy som ofte er tilleggsmuligheter for å trekke ut, transformere og laste (ETL), samt noen data-prep-verktøy. Verktøy for datakvalitet tjener flere formål, men en ting de kan gjøre er å identifisere og korrigere for kjente dataproblemer. Noen korreksjoner kan automatiseres, mens andre kan markeres som unntak og sendes til datastyrer for å korrigere manuelt eller for å oppdatere rengjøringsreglene.
Informatica, Talend, IBM, Oracle, Microsoft og mange andre tilbyr datakvalitetsverktøy som plugges inn i ETL-plattformene sine, mens data-prep-verktøy fra Tableau, Alteryx, Paxata, Trifacta og andre har datakvalitetsfunksjoner.
Den andre praksisen er datalinje. Mens datakvaliteten hjelper til med å identifisere dataproblemer, er datalinjen et sett med praksis og verktøy som sporer endringer i data og underliggende implementeringer. De hjelper brukerne med å forstå hvor i datas livssyklus en transformasjon, beregning eller annen datamanipulering er implementert. Datalinjeverktøy, rapporter og dokumentasjon kan deretter brukes til å spore tilbake til en datarørledning og hjelpe til med å finne ut hvor i en datastrøm en feil eller et annet problem ble introdusert.
Bruke gyldne datasett for å validere datavisualiseringer
Analytics, dashboards og datavisualisering fungerer ikke på statiske datakilder. Dataene endres med en viss hastighet, og samtidig kan utviklere og dataforskere endre de underliggende datastrømmene, algoritmene og visualiseringene. Når du ser på et dashbord, er det vanskelig å skille om et uventet dataproblem skyldes en programmatisk endring, eller om det er relatert til data eller endringer i datakvaliteten.
En måte å isolere endringer på er å skille et kjent gyldendatasett for å validere dataflyt-, applikasjons- og datavisualiseringsendringer. Ved hjelp av et gyldent datasett kan et testteam definere enhets-, funksjons- og ytelsestester for å validere og sammenligne utdata. Testere kan kjøre A / B-tester, hvor A er utdata før implementeringsendringer ble introdusert og B er utdata etter at endringene ble gjort. Testen skal bare vise forskjeller i produksjonen i forventede områder der datastrømmene, modellene, analysene, forretningslogikken eller visualiseringene ble endret.
Selv om dette er et relativt enkelt konsept, er det ikke trivielt å implementere.
Først må lagene lage de gyldne datasettene og bestemme hvilket volum og hvilket utvalg av data som utgjør et omfattende prøvesett å teste. Det kan også kreve flere datasett for å validere forskjellige datasegmenter, grensebetingelser eller analytiske modeller. Et verktøy som kan hjelpe team med å administrere testdata er Delphix for testdataadministrasjon; andre leverandører tilbyr også denne muligheten.
For det andre, når gyldne datasett er opprettet, kan testteam kreve flere miljøer eller verktøy for å bytte de underliggende datakildene i sine omgivelser. For eksempel kan testere ønske å teste mot de gyldne datasettene, og deretter kjøre en gang til mot data som er en kopi av produksjonsdata. Team som opererer i skymiljøer og bruker infrastruktur som kodeverktøy som Puppet, Chef og Ansible, kan konstruere og rive ned flere testmiljøer for disse forskjellige formål.
Sist, testteam trenger verktøy for å implementere A / B-testing av data og resultater. Mange team jeg kjenner gjør dette manuelt ved å skrive SQL-spørsmål og deretter sammenligne resultatene. Hvis datasettene og testene er enkle, kan denne tilnærmingen være tilstrekkelig. Men hvis flere punkter i datastrømmen må testes, trenger du sannsynligvis dedikerte verktøy for å sentralisere testspørsmål, automatisere dem og bruke rapporter for å validere endringer. Ett verktøy, QuerySurge, er spesielt designet for å implementere A / B-testing mot datastrømmer, databaser og noen verktøy for forretningsinformasjon.
Arbeide effektivt med fageksperter
På et tidspunkt må du involvere fageksperter for å bruke nye og oppdaterte datavisualiseringer og gi tilbakemelding. De må hjelpe med å svare på spørsmål om analysen er gyldig og nyttig for å utvikle innsikt eller hjelpe til med datadrevet beslutningstaking.
Problemet mange lag står overfor er å få tilstrekkelig tid fra fageksperter til å delta i denne testen. Dette kan være en betydelig utfordring når du prøver å teste og distribuere endringer ofte.
For å bruke tiden sin effektivt anbefaler jeg tre separate aktiviteter:
- Implementere så mye av datakvaliteten, datalinjen og A / B-testing som mulig på gyldne datasett. Før du involverer fageksperter, må du gjøre rimelige anstrengelser for å validere at rå og beregnede data er riktige. Dette må gjøres med tillit, slik at du kan forklare og ideelt sett illustrere for fageksperter at de underliggende dataene, transformasjonene og beregningene er nøyaktige - så de kan være trygge på at de ikke trenger å bruke betydelig tid på å teste det manuelt.
- Design datavisualiseringer for å hjelpe fageksperter med å gjennomgå og validere dataene og analysene. Noen visualiseringer kan være utdata fra A / B-testene, mens andre bør være visualiseringer som avslører data på lavt nivå. Når du implementerer større data-, algoritme-, modell- eller visualiseringsendringer, hjelper det ofte å ha disse kvalitetskontrolldatavisualiseringene på plass for å hjelpe fageksperter med å utføre raske valideringer.
- Du vil at fageksperter skal utføre brukerattesttesting (UAT) på de endelige applikasjonene og datavisualiseringene. Når de når dette trinnet, bør de ha full tillit til at dataene og analysene er gyldige.
Dette siste trinnet er nødvendig for å avgjøre om visualiseringene er effektive for å utforske dataene og svare på spørsmål: Er visualiseringen enkel å bruke? Er de riktige dimensjonene tilgjengelige for å bore i dataene? Hjelper visualiseringen med å svare på spørsmålene den ble designet for å svare på?
På dette punktet i prosessen tester du brukeropplevelsen og sørger for at dashbordene og applikasjonene er optimalisert. Dette kritiske trinnet kan gjøres langt mer effektivt når det er forståelse og tillit til de underliggende dataene og analysene.
