Test af applikationer er en moden disciplin med værktøjer, der hjælper kvalitetssikringsteams med at udvikle og automatisere funktionelle tests, køre belastnings- og ydelsestest, udføre statisk kodeanalyse, indpakke API'er med enhedstest og validere applikationer mod kendte sikkerhedsproblemer. Hold, der praktiserer devops, kan implementere kontinuerlig test ved at inkludere alle eller en delmængde af deres automatiserede tests i deres CI / CD-rørledninger og bruge resultaterne til at afgøre, om en build skal leveres til målmiljøet.
Men alle disse testfunktioner kan let ignorere et afgørende sæt tests, der er kritisk for enhver applikationsbehandling eller præsentation af data, analyser eller datavisualiseringer.
Er dataene nøjagtige, og er analyserne gyldige? Viser datavisualiseringerne resultater, der giver mening for fageksperter? Som et team forbedrer desuden datarørledninger og databaser, hvordan skal de desuden sikre, at ændringer ikke skader et downstream-program eller et dashboard?
Efter min erfaring med at udvikle data- og analyserige applikationer er denne type test og validering ofte en anden tanke sammenlignet med enheds-, funktions-, ydeevne- og sikkerhedstest. Det er også et sværere sæt testkriterier at gøre af flere grunde:
- Validering af data og analyser er svært for udviklere, testere og dataforskere, der normalt ikke er emneeksperter, især om hvordan dashboards og applikationer bruges til at udvikle indsigt eller skabe beslutningstagning.
- Data i sig selv er ufuldkomne med kendte og ofte ukendte problemer med datakvaliteten.
- At forsøge at fange valideringsregler er ikke trivielt, fordi der ofte er almindelige regler, der gælder for de fleste data efterfulgt af regler for forskellige typer af outliers. Forsøg på at indfange og kode for disse regler kan være et vanskeligt og komplekst forslag til applikationer og datavisualiseringer, der behandler store mængder af komplekse datasæt.
- Aktive datadrevne organisationer indlæser nye datasæt og udvikler datarørledninger for at forbedre analyser og beslutningstagning.
- Databehandlingssystemer er ofte komplekse med forskellige værktøjer til integration, styring, behandling, modellering og levering af resultater.
Førstegangsholdene præsenterer dårlige data eller ugyldig analyse for interessenter er normalt det første vækkekald, hvor det kan være nødvendigt med deres praksis og værktøjer til at teste, diagnosticere og løse disse dataproblemer proaktivt.
Forståelse af datastamme og datakvalitet
Dataproblemer løses bedst ved deres kilder og gennem de forskellige datatransformationer, der udføres ved indlæsning og behandling af dataene. Hvis kildedataene har nye datakvalitetsproblemer, eller hvis der er defekter introduceret i datarørledningen, er det langt mere effektivt at identificere og løse disse tidligt i databehandlingsrørledningen.
To fremgangsmåder og relaterede værktøjer hjælper med disse problemer. Begge gør det muligt for udviklings- og datateams at identificere dataproblemer, før de når nedstrøms datavisualiseringer og applikationer.
Den første praksis involverer datakvalitetsværktøjer, der ofte er tilføjelsesfunktioner til at udtrække, transformere og indlæse (ETL) samt nogle data-prep-værktøjer. Datakvalitetsværktøjer tjener flere formål, men en ting, de kan gøre, er at identificere og korrigere for kendte dataproblemer. Nogle rettelser kan automatiseres, mens andre kan markeres som undtagelser og sendes til datastyrere for at rette det manuelt eller for at opdatere udrensningsreglerne.
Informatica, Talend, IBM, Oracle, Microsoft og mange andre tilbyder datakvalitetsværktøjer, der tilsluttes deres ETL-platforme, mens dataprep-værktøjer fra Tableau, Alteryx, Paxata, Trifacta og andre har datakvalitetsfunktioner.
Den anden praksis er datastamme. Mens datakvalitet hjælper med at identificere dataproblemer, er datalinje et sæt praksis og værktøjer, der sporer ændringer i data og underliggende implementeringer. De hjælper brugerne med at forstå, hvor der implementeres en transformation, beregning eller anden databehandling i datalivscyklussen. Datalinjeværktøjer, rapporter og dokumentation kan derefter bruges til at spore tilbage til en datarørledning og hjælpe med at lokalisere, hvor der i en datastrøm blev introduceret en defekt eller et andet problem.
Brug af gyldne datasæt til at validere datavisualiseringer
Analytics, dashboards og datavisualisering fungerer ikke på statiske datakilder. Dataene ændrer sig med en vis hastighed, og samtidig kan udviklere og dataforskere muligvis ændre de underliggende datastrømme, algoritmer og visualiseringer. Når du kigger på et dashboard, er det svært at skelne, om et uventet dataproblem skyldes en programmatisk ændring, eller om det er relateret til data eller ændringer i datakvaliteten.
En måde at isolere ændringer på er at adskille en kendt gyldendatasæt for at hjælpe med at validere ændringer i datastrøm, applikation og datavisualisering. Ved hjælp af et gyldent datasæt kan et testteam definere enheds-, funktions- og præstationstest for at validere og sammenligne output. Testere kan køre A / B-tests, hvor A er output, før implementeringsændringer blev introduceret, og B er output, efter at ændringerne blev foretaget. Testen skal kun vise forskelle i output i forventede områder, hvor datastrømme, modeller, analyser, forretningslogik eller visualiseringer blev ændret.
Selvom dette er et relativt simpelt koncept, er det ikke trivielt at implementere.
For det første skal hold oprette de gyldne datasæt og bestemme, hvilket volumen og hvilken række data der udgør et omfattende prøvesæt til test. Det kan også kræve flere datasæt for at hjælpe med at validere forskellige datasegmenter, randbetingelser eller analytiske modeller. Et værktøj, der kan hjælpe teams med at administrere testdata er Delphix til testdatastyring; andre leverandører tilbyder også denne mulighed.
For det andet, når gyldne datasæt er oprettet, kan testteam muligvis kræve yderligere miljøer eller værktøjer til at skifte de underliggende datakilder i deres miljøer. F.eks. Vil testere muligvis teste mod de gyldne datasæt og derefter køre en anden gang mod data, der er en replika af produktionsdata. Hold, der opererer i skymiljøer og bruger infrastruktur-som-kode-værktøjer som Puppet, Chef og Ansible, kan konstruere og nedbryde flere testmiljøer til disse forskellige formål.
Til sidst har testteam brug for værktøjer til at implementere A / B-test af data og resultater. Mange hold, jeg kender, gør dette manuelt ved at skrive SQL-forespørgsler og derefter sammenligne resultaterne. Hvis datasættene og testene er enkle, kan denne tilgang være tilstrækkelig. Men hvis flere punkter i datastrømmen skal testes, har du sandsynligvis brug for dedikerede værktøjer til at centralisere testforespørgsler, automatisere dem og bruge rapporter til at validere ændringer. Et værktøj, QuerySurge, er specielt designet til implementering af A / B-test mod datastrømme, databaser og nogle business intelligence-værktøjer.
Arbejde effektivt med fageksperter
På et tidspunkt skal du involvere emneeksperter til at bruge nye og opdaterede datavisualiseringer og give feedback. De skal hjælpe med at besvare spørgsmål om, hvorvidt analyserne er gyldige og nyttige til at udvikle indsigt eller hjælpe med datadrevet beslutningstagning.
Problemet, som mange hold står over for, er at få tilstrækkelig tid fra fageksperter til at deltage i denne test. Dette kan være en væsentlig udfordring, når du prøver at teste og implementere ændringer ofte.
For at bruge deres tid effektivt anbefaler jeg tre separate aktiviteter:
- Implementere så meget af datakvaliteten, datastammen og A / B-testen som muligt på gyldne datasæt. Inden du involverer fageksperter, skal du gøre en rimelig indsats for at validere, at rå og beregnede data er korrekte. Dette skal gøres med tillid, så du kan forklare og ideelt illustrere for emneeksperter, at de underliggende data, transformationer og beregninger er nøjagtige - så de kan være sikre på, at de ikke behøver at bruge betydelig tid på at manuelt teste det.
- Design datavisualiseringer, der hjælper fageksperter med at gennemgå og validere data og analyser. Nogle visualiseringer kan være output fra A / B-testene, mens andre skal være visualiseringer, der udsætter data på lavt niveau. Når du implementerer ændringer i større skala, algoritme, model eller visualisering, hjælper det ofte at have disse kvalitetskontroldatavisualiseringer på plads for at hjælpe emneeksperter med at udføre hurtige valideringer.
- Du vil have, at fageksperter skal udføre brugeraccepteringstest (UAT) på de færdige applikationer og datavisualiseringer. Når de når dette trin, skal de have fuld tillid til, at dataene og analyserne er gyldige.
Dette sidste trin er nødvendigt for at afgøre, om visualiseringerne er effektive til at udforske dataene og besvare spørgsmål: Er visualiseringen nem at bruge? Er de korrekte dimensioner tilgængelige til at bore i dataene? Hjælper visualiseringen med at besvare de spørgsmål, den var designet til at besvare?
På dette tidspunkt i processen tester du brugeroplevelsen og sikrer, at dashboards og applikationer er optimeret. Dette kritiske trin kan udføres langt mere effektivt, når der er forståelse og tillid til de underliggende data og analyser.
