Testaussovellukset ovat kypsyvä tieteenala työkaluilla, jotka auttavat laadunvarmistusryhmiä kehittämään ja automatisoimaan toiminnallisia testejä, suorittamaan kuormitus- ja suorituskykytestejä, suorittamaan staattisen koodin analyysin, käärimään API: t yksikkötesteillä ja validoimaan sovelluksia tunnettuja turvallisuusongelmia vastaan. Devopsia harjoittavat joukkueet voivat toteuttaa jatkuvaa testausta sisällyttämällä kaikki tai osan automatisoiduista testeistä CI / CD-putkijohtoihinsa ja tulosten perusteella päättää, onko koontiversio toimitettava kohdeympäristöön.
Mutta kaikki nämä testausominaisuudet voivat helposti jättää huomiotta yhden tärkeän testisarjan, joka on kriittinen sovelluksen käsittelylle tai tietojen esittämiselle, analytiikalle tai tietojen visualisoinnille.
Ovatko tiedot tarkkoja ja analyysit kelvollisia? Ovatko tietojen visualisoinnit tuloksia, jotka ovat järkeviä aihe-asiantuntijoille? Kun tiimi tekee parannuksia dataputkistoihin ja tietokantoihin, miten niiden tulisi varmistaa, että muutokset eivät vahingoita loppupään sovellusta tai kojelautaa?
Kokemukseni mukaan dataa ja analytiikkaa sisältävien sovellusten kehittämisestä tällainen testaus ja validointi on usein toinen ajatus verrattuna yksikkö-, toiminnallisiin, suorituskyky- ja suojaustesteihin. Se on myös vaikeampaa testikriteerejä useista syistä:
- Tietojen ja analytiikan vahvistaminen on vaikeaa kehittäjille, testaajille ja datatieteilijöille, jotka eivät yleensä ole aiheen asiantuntijoita, etenkin siitä, miten koontinäyttöjä ja sovelluksia käytetään oivallusten kehittämiseen tai päätöksenteon edistämiseen.
- Tiedot sinänsä ovat epätäydellisiä, ja tiedossa ja tiedossa on usein tuntemattomia ongelmia.
- Vahvistussääntöjen yrittäminen ei ole vähäpätöistä, koska useimpiin tietoihin sovelletaan usein yleisiä sääntöjä, joita seuraa sääntöjä erityyppisille poikkeamille. Näiden sääntöjen sieppaaminen ja koodaaminen voi olla vaikea ja monimutkainen ehdotus sovelluksille ja tietojen visualisoinnille, jotka käsittelevät suuria määriä monimutkaisia tietojoukkoja.
- Aktiiviset datalähtöiset organisaatiot lataavat uusia tietojoukkoja ja kehittävät dataputkia analytiikan ja päätöksenteon parantamiseksi.
- Tietojenkäsittelyjärjestelmät ovat usein monimutkaisia, ja niillä on erilaisia työkaluja tulosten integroimiseen, hallintaan, käsittelyyn, mallintamiseen ja tuottamiseen.
Ensimmäisen kerran tiimit esittävät sidosryhmille huonoa dataa tai virheellistä analytiikkaa. Se on yleensä ensimmäinen herätyssoitto, jota heidän käytäntöjään ja työkalujaan voidaan tarvita näiden dataongelmien testaamiseksi, diagnosoimiseksi ja ratkaisemiseksi ennakoivasti.
Tietojen sukulinjan ja laadun ymmärtäminen
Tieto-ongelmat voidaan parhaiten ratkaista niiden lähteistä ja tietojen lataamisen ja käsittelyn aikana suoritetuista erilaisista tiedonmuunnoksista. Jos lähdetiedoilla on uusia tietojen laatuongelmia tai jos tietoputkessa on vikoja, niiden tunnistaminen ja ratkaiseminen on paljon tehokkaampaa tietojenkäsittelyn varhaisessa vaiheessa.
Kaksi käytäntöä ja siihen liittyvät työkalut auttavat näissä asioissa. Molemmat antavat kehitys- ja tietoryhmille mahdollisuuden tunnistaa tietokysymykset ennen kuin ne saavuttavat loppupään datan visualisoinnit ja sovellukset.
Ensimmäinen käytäntö sisältää tietojen laatutyökalut, jotka ovat usein lisäominaisuuksia purkamiseen, muuntamiseen ja lataamiseen (ETL), sekä joitain tietojen valmistelutyökaluja. Datanlaatutyökalut palvelevat useita tarkoituksia, mutta yksi asia, jonka he voivat tehdä, on tunnistaa ja korjata tunnetut dataongelmat. Jotkut korjaukset voidaan automatisoida, kun taas toiset voidaan merkitä poikkeuksiksi ja lähettää tietovalvojille korjaamaan manuaalisesti tai päivittämään puhdistussäännöt.
Informatica, Talend, IBM, Oracle, Microsoft ja monet muut tarjoavat tiedonlaadun työkaluja, jotka liitetään ETL-alustoihin, kun taas Tableaun, Alteryxin, Paxatan, Trifaktan ja muiden tietojen valmistelutyökaluilla on tiedonlaatuominaisuudet.
Toinen käytäntö on datalinja. Vaikka tietojen laatu auttaa tunnistamaan tietokysymyksiä, datalinja on joukko käytäntöjä ja työkaluja, jotka seuraavat datan muutoksia ja niiden taustalla olevia toteutuksia. Ne auttavat käyttäjiä ymmärtämään, missä tietojen elinkaaressa muunnos, laskenta tai muu tietojen käsittely tapahtuu. Data-linjatyökaluja, raportteja ja dokumentaatiota voidaan sitten käyttää jäljittämään dataputkeen ja auttaa tunnistamaan, missä tietovirrassa vika tai muu ongelma tuotiin.
Kultaisten tietojoukkojen käyttäminen tietojen visualisointien vahvistamiseen
Analytics, hallintapaneelit ja tietojen visualisointi eivät toimi staattisissa tietolähteissä. Tiedot muuttuvat tietyllä nopeudella, ja samalla kehittäjät ja tutkijat saattavat muokata taustalla olevia tietovirtoja, algoritmeja ja visualisointeja. Kun tarkastelet hallintapaneelia, on vaikea erottaa, johtuuko odottamaton dataongelma ohjelmallisesta muutoksesta vai liittyykö se dataan vai tietojen laatuun.
Yksi tapa eristää muutokset on erottaa tunnettu kultainentietojoukko, joka auttaa vahvistamaan tietovirran, sovelluksen ja tietojen visualisoinnin muutokset. Kultaisen tietojoukon avulla testausryhmä voi määritellä yksikkö-, toiminnalliset ja suorituskykytestit tulosten vahvistamiseksi ja vertailemiseksi. Testaajat voivat suorittaa A / B-testejä, joissa A on tulos ennen toteutusmuutosten tekemistä ja B on tulos muutosten jälkeen. Testin pitäisi näyttää eroja tuotoksissa vain odotetuilla alueilla, joilla tietovirtoja, malleja, analytiikkaa, liiketoimintalogiikkaa tai visualisointeja muutettiin.
Vaikka tämä on suhteellisen yksinkertainen käsite, se ei ole triviaali toteuttaa.
Ensinnäkin ryhmien on luotava kultaiset tietojoukot ja päätettävä, mikä tietomäärä ja -laji muodostaa kattavan näytesarjan testattavaksi. Se voi myös vaatia useita tietojoukkoja erilaisten tietosegmenttien, reunaehtojen tai analyyttisten mallien validoimiseksi. Yksi työkalu, joka voi auttaa tiimejä hallitsemaan testitietoja, on Delphix testitietojen hallintaan; muut toimittajat tarjoavat myös tämän mahdollisuuden.
Toiseksi, kun kultaiset tietojoukot on luotu, testausryhmät voivat tarvita lisäympäristöjä tai työkaluja taustalla olevien tietolähteiden vaihtamiseksi ympäristöissä. Esimerkiksi testaajat saattavat haluta testata kultaisia tietojoukkoja vastaan ja sitten suorittaa toisen kerran tietoja, jotka ovat kopio tuotantotiedoista. Joukkueet, jotka toimivat pilviympäristöissä ja käyttävät infrastruktuurikoodityökaluja, kuten Puppet, Chef ja Ansible, voivat rakentaa ja hajottaa useita testausympäristöjä näitä eri tarkoituksia varten.
Viimeiseksi testausryhmät tarvitsevat työkaluja tietojen ja tulosten A / B-testauksen toteuttamiseksi. Monet tuntemani joukkueet tekevät tämän manuaalisesti kirjoittamalla SQL-kyselyitä ja vertaamalla sitten tuloksia. Jos tietojoukot ja testit ovat yksinkertaisia, tämä lähestymistapa voi olla riittävä. Mutta jos useita tietovirtapisteitä on testattava, tarvitset todennäköisesti erillisiä työkaluja testikyselyjen keskittämiseen, niiden automatisointiin ja raporttien avulla muutosten vahvistamiseen. Yksi työkalu, QuerySurge, on suunniteltu erityisesti A / B-testauksen toteuttamiseen tietovirtoja, tietokantoja ja joitain liiketoimintatiedon työkaluja vastaan.
Työskentely aihe-asiantuntijoiden kanssa tehokkaasti
Jossain vaiheessa sinun on otettava aiheen asiantuntijat mukaan käyttämään uusia ja päivitettyjä tietojen visualisointeja ja antamaan palautetta. Niiden on autettava vastaamaan kysymyksiin siitä, onko analytiikka pätevää ja hyödyllistä kehitettäessä oivalluksia tai auttaakseen dataan perustuvassa päätöksenteossa.
Monien joukkueiden kohtaama ongelma on saada asiantuntijoilta riittävästi aikaa osallistua tähän testaukseen. Tämä voi olla merkittävä haaste, kun yritetään testata ja ottaa muutoksia käyttöön usein.
Ajan tehokkaaseen käyttämiseen suosittelen kolmea erillistä toimintaa:
- Toteuta mahdollisimman suuri osa tietojen laadusta, datalinjasta ja A / B-testauksesta kultaisille tietojoukoille. Ennen kuin saat asiantuntija-asiantuntijoita mukaan, tee kohtuulliset ponnistelut varmistaaksesi, että raakatiedot ja lasketut tiedot ovat oikeita. Tämä on tehtävä luottavaisin mielin, jotta voit selittää ja kuvata aiheellisella tavalla asiantuntijoille, että taustalla olevat tiedot, muunnokset ja laskelmat ovat tarkkoja - joten voit olla varma, että heidän ei tarvitse investoida paljon aikaa sen manuaaliseen testaamiseen.
- Suunnittele tietojen visualisoinnit, jotta aihe-asiantuntijat voivat tarkistaa ja vahvistaa tiedot ja analyysit. Jotkut visualisoinnit voivat olla A / B-testien lähtöjä, kun taas toiset pitäisi olla visualisointeja, jotka paljastavat matalan tason tietoja. Kun toteutetaan laajempia tietoja, algoritmeja, malleja tai visualisointimuutoksia, se auttaa usein pitämään nämä laadunvalvontadatan visualisoinnit paikkansa, jotta aiheen asiantuntijat voivat tehdä nopeita validointeja.
- Haluat, että aiheen asiantuntijat suorittavat käyttäjien hyväksymistestauksen (UAT) viimeisteltyihin sovelluksiin ja tietojen visualisointeihin. Siihen mennessä, kun he saavuttavat tämän vaiheen, heidän pitäisi olla täysin varmoja siitä, että tiedot ja analyysit ovat kelvollisia.
Tämä viimeinen vaihe on tarpeen sen selvittämiseksi, ovatko visualisoinnit tehokkaita tietojen tutkimisessa ja vastauksissa kysymyksiin: Onko visualisointi helppokäyttöinen? Onko tietojen poraamiseen käytettävissä oikeita mittoja? Auttaako visualisointi onnistuneesti vastaamaan kysymyksiin, joihin se on suunniteltu vastaamaan?
Tässä prosessin vaiheessa testaat käyttökokemusta ja varmistat, että kojelaudat ja sovellukset ovat optimoituja. Tämä kriittinen vaihe voidaan tehdä paljon tehokkaammin, kun taustalla olevaan dataan ja analytiikkaan ymmärretään ja luotetaan.
