Testování aplikací je dozrávající disciplína s nástroji, které pomáhají týmům zajišťujícím kvalitu vyvíjet a automatizovat funkční testy, spouštět testy zátěže a výkonu, provádět statickou analýzu kódu, zalamovat API pomocí testů jednotek a ověřovat aplikace podle známých bezpečnostních problémů. Týmy cvičící devops mohou implementovat nepřetržité testování zahrnutím všech nebo podmnožiny svých automatizovaných testů do svých kanálů CI / CD a pomocí výsledků určit, zda by měla být sestava doručena do cílového prostředí.
Ale všechny tyto možnosti testování mohou snadno ignorovat jednu zásadní sadu testů, která je zásadní pro jakékoli zpracování aplikací nebo prezentaci dat, analytiky nebo vizualizace dat.
Jsou data přesná a jsou analytické údaje platné? Zobrazují vizualizace dat výsledky, které mají smysl pro odborníky? Jak by tým měl dále vylepšovat datové kanály a databáze, jak by měl zajistit, aby změny nepoškodily následnou aplikaci nebo řídicí panel?
Podle mých zkušeností s vývojem aplikací bohatých na data a analytiku je tento typ testování a ověřování často druhou myšlenkou ve srovnání s testováním jednotek, funkcí, výkonu a zabezpečení. Je to také těžší sada testovacích kritérií, která je třeba provést z několika důvodů:
- Ověření dat a analytiky je obtížné pro vývojáře, testery a datové vědce, kteří obvykle nejsou odborníky na předmět, zejména pokud jde o to, jak se dashboardy a aplikace používají k vývoji přehledů nebo řízení rozhodování.
- Data sama o sobě jsou nedokonalá, se známými a často neznámými problémy s kvalitou dat.
- Pokus o zachycení ověřovacích pravidel není triviální, protože pro většinu dat často platí společná pravidla, následovaná pravidly pro různé typy odlehlých hodnot. Pokus o zachycení a kódování těchto pravidel může být obtížným a složitým návrhem pro aplikace a vizualizace dat, které zpracovávají velké objemy složitých datových sad.
- Aktivní organizace založené na datech načítají nové datové sady a vyvíjejí datové kanály, aby zlepšily analytiku a rozhodování.
- Systémy zpracování dat jsou často složité s různými nástroji pro integraci, správu, zpracování, modelování a poskytování výsledků.
První týmy, které prezentují zúčastněným subjektům špatná data nebo neplatnou analýzu, jsou obvykle prvním probuzením, že jejich postupy a nástroje mohou být potřebné k proaktivnímu testování, diagnostice a řešení těchto problémů s daty.
Porozumění datové linii a kvalitě dat
Problémy s daty je nejlépe řešit u jejich zdrojů a prostřednictvím různých transformací dat prováděných při načítání a zpracování dat. Pokud mají zdrojová data nové problémy s kvalitou dat nebo pokud jsou v kanálu dat zavedeny vady, je mnohem efektivnější je identifikovat a vyřešit brzy v kanálu zpracování dat.
S těmito problémy pomáhají dva postupy a související nástroje. Oba umožňují vývojovým a datovým týmům identifikovat problémy s daty dříve, než se dostanou k následným vizualizacím dat a aplikacím.
První praxe zahrnuje nástroje pro kvalitu dat, které jsou často doplňkovými funkcemi pro extrakci, transformaci a načítání (ETL), stejně jako některé nástroje pro přípravu dat. Nástroje pro kvalitu dat slouží více účelům, ale jedna věc, kterou mohou udělat, je identifikovat a opravit známé problémy s daty. Některé opravy lze automatizovat, zatímco jiné lze označit jako výjimky a poslat je správcům dat, aby je opravili ručně nebo aktualizovali pravidla čištění.
Informatica, Talend, IBM, Oracle, Microsoft a mnoho dalších nabízí nástroje pro kvalitu dat, které se připojují k jejich platformám ETL, zatímco nástroje pro přípravu dat od společností Tableau, Alteryx, Paxata, Trifacta a dalších mají možnosti kvality dat.
Druhým postupem je datová linie. Zatímco kvalita dat pomáhá identifikovat problémy s daty, datová linie je sada postupů a nástrojů, které sledují změny dat a základní implementace. Pomáhají uživatelům pochopit, kde v životním cyklu dat je implementována transformace, výpočet nebo jiná manipulace s daty. Nástroje, sestavy a dokumentaci datové linie lze poté použít ke zpětnému trasování do datového kanálu a pomoci přesně určit, kde v toku dat byla zavedena závada nebo jiný problém.
Použití zlatých datových sad k ověření vizualizací dat
Analytics, řídicí panely a vizualizace dat nefungují na zdrojích statických dat. Data se mění určitou rychlostí a vývojáři a vědci v oblasti dat mohou současně upravovat základní datové toky, algoritmy a vizualizace. Když se díváte na řídicí panel, je obtížné oddělit, zda je neočekávaný problém s daty způsoben programovou změnou nebo zda souvisí se změnami dat nebo kvality dat.
Jedním ze způsobů, jak izolovat změny, je oddělit známé zlatýdatová sada, která pomáhá ověřit změny datového toku, aplikace a vizualizace dat. Pomocí zlaté datové sady může testovací tým definovat jednotkové, funkční a výkonnostní testy k ověření a porovnání výstupů. Testeři mohou spustit testy A / B, kde A je výstup před zavedením změn implementace a B je výstup po provedení změn. Test by měl ukázat pouze rozdíly ve výstupu v očekávaných oblastech, kde byly změněny datové toky, modely, analytika, obchodní logika nebo vizualizace.
I když se jedná o relativně jednoduchý koncept, jeho implementace není triviální.
Nejprve musí týmy vytvořit zlaté datové sady a rozhodnout se, jaký objem a rozmanitost dat představuje komplexní ukázkovou sadu k testování. Může také vyžadovat více datových sad, aby pomohla ověřit různé datové segmenty, okrajové podmínky nebo analytické modely. Jedním z nástrojů, který může týmům pomoci se správou testovacích dat, je Delphix pro správu testovacích dat; tuto možnost nabízejí i další prodejci.
Za druhé, jakmile budou vytvořeny zlaté datové sady, mohou testovací týmy vyžadovat další prostředí nebo nástroje pro přepínání podkladových zdrojů dat v jejich prostředích. Například testeři mohou chtít otestovat proti zlatým datovým sadám a potom spustit podruhé proti datům, která jsou replikou produkčních dat. Týmy pracující v cloudových prostředích a využívající nástroje infrastruktury jako kód jako Puppet, Chef a Ansible mohou pro tyto různé účely vytvořit a strhnout několik testovacích prostředí.
A konečně, testovací týmy potřebují nástroje k implementaci A / B testování dat a výsledků. Mnoho týmů, které znám, to dělá ručně psaním dotazů SQL a následným porovnáním výsledků. Pokud jsou datové soubory a testy jednoduché, může tento přístup stačit. Pokud je ale třeba otestovat více bodů v datovém toku, budete pravděpodobně potřebovat specializované nástroje pro centralizaci testovacích dotazů, jejich automatizaci a použití sestav k ověření změn. Jeden nástroj, QuerySurge, je speciálně navržen pro implementaci A / B testování proti datovým tokům, databázím a některým nástrojům business intelligence.
Efektivní práce s odborníky na dané téma
V určitém okamžiku musíte zapojit odborníky, aby používali nové a aktualizované vizualizace dat a poskytovali zpětnou vazbu. Musí pomoci odpovědět na otázky, zda je analytika platná a užitečná pro rozvoj poznatků nebo pomoc při rozhodování na základě dat.
Problém, kterému mnoho týmů čelí, je dostatek času od odborníků na předmět k účasti na tomto testování. To může být významnou výzvou při pokusu o časté testování a nasazení změn.
Aby efektivně využili svůj čas, doporučuji tři samostatné aktivity:
- Implementujte co nejvíce kvality dat, datové linie a testování A / B na zlaté datové sady. Před zapojením odborníků na předmět se přiměřeně snažte ověřit, zda jsou surová a vypočítaná data správná. To je třeba provést s jistotou, abyste odborníkům na předmět mohli vysvětlit a v ideálním případě ilustrovat, že podkladová data, transformace a výpočty jsou přesné - takže si můžete být jisti, že nemusí investovat příliš mnoho času na ruční testování.
- Navrhněte vizualizace dat a pomozte odborníkům kontrolovat a ověřovat data a analýzy. Některé vizualizace mohou být výstupy z testů A / B, zatímco jiné by měly být vizualizace, které vystavují nízkoúrovňová data. Při implementaci větších dat, změn algoritmu, modelu nebo vizualizace často pomůže mít tyto vizualizace dat kontroly kvality zavedeny, aby pomohly odborníkům provádějícím rychlé ověření.
- Chcete, aby odborníci na předmět prováděli uživatelské akceptační testování (UAT) na finálních aplikacích a vizualizacích dat. Než dosáhnou tohoto kroku, měli by mít úplnou jistotu, že data a analytika jsou platná.
Tento poslední krok je nutný k určení, zda jsou vizualizace efektivní při prozkoumávání dat a odpovídání na otázky: Je vizualizace snadno použitelná? Jsou k dispozici správné rozměry pro vrtání do dat? Pomáhá vizualizace úspěšně odpovídat na otázky, na které byla navržena?
V tomto bodě procesu testujete uživatelské prostředí a zajišťujete optimalizaci řídicích panelů a aplikací. Tento kritický krok lze provést mnohem efektivněji, pokud existuje porozumění a důvěra v podkladová data a analýzy.
