Egyre érettebb tudománynak tekinthető az alkalmazások tesztelése olyan eszközökkel, amelyek segítenek a minőségbiztosítást végző csapatoknak kifejleszteni és automatizálni a funkcionális teszteket, lefuttatni a teljesítményteszteket, végrehajtani a statikuskód-elemzéseket, valamint kiszűrni a biztonsági problémákat. A DevOps módszert követő csapatok folyamatos tesztelést végezhetnek, és az eredmények alapján eldönthetik, hogy egy build alkalmas-e arra, hogy a célkörnyezetben telepítsék. A kipróbálás során azonban elmaradhat egy alapvető fontosságú tesztsorozat, amelynek lefuttatása elengedhetetlen minden olyan alkalmazás fejlesztése során, amely adatokat, elemzéseket szolgáltat, vagy adatvizualizációt valósít meg.
Pontosak-e az adatok, érvényes-e az elemzés? Olyan eredményeket mutatnak az adatvizualizációk, amelyekre a témaszakértőknek szükségük van? És minthogy az alkalmazottak módosítani szokták az adatforrásokat és adatbázisokat, hogyan biztosítható, hogy a változtatások nem befolyásolják negatívan az adott alkalmazás vagy dashboard működését?
Sacolick tapasztalatai szerint az adatok feldolgozását és elemzését végző alkalmazások fejlesztésekor az effajta tesztelés és validálás gyakran szorul háttérbe a funkcionális, teljesítmény- és biztonsági tesztelés mögött. Ráadásul több okból is nehezebb elvégezni:
- Az adatok és elemzések validálása komoly feladat a fejlesztők, tesztelők és adattudósok számára, mivel ők általában nem szakértői a témának, vagyis nem tudják, miképpen nyújtanak a dashboardok és alkalmazások döntéshozatalt segítő információkat.
- Az adatok önmagukban nem tökéletesek, léteznek ismert és nem ismert adatminőségi problémák.
- A validációs szabályok kidolgozása és kódolása nehéz és komplex feladat a nagy mennyiségű, összetett adatkészleteket feldolgozó alkalmazások és vizualizációk esetében.
- Az adatvezérelt szervezetek az elemzések és a döntéshozatal hatékonyságának javítása érdekében egyre újabb adatkészleteket és adatforrásokat tárnak fel.
- Az adatfeldolgozó rendszerek gyakran nagyon összetettek, külön eszközöket használnak az integráláshoz, a felügyelethez, a feldolgozáshoz, a modellezéshez és az eredmények prezentálásához.
Amikor az érintetteknek első alkalommal produkálnak rossz adatokat vagy használhatatlan elemzéseket az erre hivatott csapatok, az általában az első intő jel arra, hogy gyakorlataikat és eszközeiket tesztelni és diagnosztizálni kell a hibák kiszűrése érdekében.
Adatminőségi problémák megszüntetése
Legjobb, ha az adatproblémákat a forrásuknál, valamint az adatok betöltése és feldolgozása során végrehajtott transzformációknál tudjuk kezelni. Ha a forrásadatok minősége problémás, vagy ha sérül az adatfolyam, a leghatékonyabb módszer a problémák azonosítása és megszüntetése az adatfeldolgozás korai szakaszában. Két gyakorlat segíthet ebben; mindkettő lehetővé teszi a fejlesztők számára az adatproblémák azonosítását, még mielőtt az adatok eljutnak az alkalmazásokhoz és a vizualizáló eszközökhöz.
Az első adatminőségi eszközöket használ, amelyek gyakran a kivonást, transzformációt és betöltést végző (ETL), illetve az adat-előkészítő eszközök kiegészítői. Az adatminőségi eszközök többféle célt szolgálnak, az egyik közülük az ismert adatproblémák azonosítása és megszüntetése. A korrekciók egy része automatizálható, míg mások kivételként jelölhetők meg, hogy azután az erre illetékesek manuálisan javítsák ki azokat, vagy frissítsék a tisztítási szabályokat.
Többek között az Informatica, a Talend, az IBM, az Oracle, a Microsoft kínál becsatlakozó adatminőségi eszközöket ETL-platformjaihoz, míg a Tableau, az Alteryx, a Paxata, a Trifacta és mások adat-előkészítő megoldásai beépített adatminőségi funkciókat tartalmaznak.
A második módszer az adattörténet (data lineage) figyelése. Míg az adatminőségi eszközök segítenek azonosítani az adatproblémákat, addig az adattörténet olyan gyakorlatokat és eszközöket használ, amelyek nyomon követik az adatok változásait. Ennek jóvoltából a felhasználók megtudják, hogy az adatok életciklusa során hol történt transzformáció, kalkuláció vagy más adatmanipuláció. Az adattörténeti eszközök, jelentések és dokumentációk segítségével nyomon követhetők az adatfolyam korábbi állapotai, és megállapítható, hol kerültek be hibák az adatfolyamba.
Validálás arany adatkészlettel
Az elemzések, dashboardok és adatvizualizációk nem statikus adatforrásokat használnak. Az adatok bizonyos ütemben változnak, mellyel egyidejűleg a fejlesztők és adattudósok módosíthatják a feldolgozó algoritmusokat és vizualizációkat. Amikor ránézünk egy dashboardra, nehéz megmondanunk, mi okozott váratlan adatproblémát: a feldolgozást végző program módosítása vagy az adatminőség romlása.
Egyik módja a módosítások izolálásának egy ismert, úgynevezett arany adatkészlet létrehozása az adatfolyam, az alkalmazás és adatvizualizáció-változtatások validálására. Az arany adatkészlet segítségével a tesztelők funkcionális és teljesítményteszteket tudnak definiálni az eredmények validálására és összehasonlítására. A/B-teszteket tudnak futtatni, ahol az A a változtatások előtti, a B pedig a változtatások utáni eredményt jelöli. Bár ez viszonylag egyszerű koncepciónak tűnik, egyáltalán nem triviális a megvalósítása.
Először is létre kell hozni az arany adatkészleteket, majd meg kell határozni, milyen méretű és változatosságú adattömeggel lehet megbízhatóan végrehajtani a tesztelést. Ebben segíthet például a Delphix nevű eszköz. Másodszor, miután elkészültek az arany adatkészletek, a tesztelőknek további környezetekre vagy eszközökre lehet szükségük. Például nemcsak az arany adatkészlettel kívánhatják elvégezni a tesztelést, hanem a valós adatok másolatán is. A felhős környezetekben működő és infrastruktúra mint kód eszközöket (Puppet, Chef, Ansible) használó vállalatoknál pedig több tesztelési környezet létrehozására is szükség lehet.
Végül a tesztelőknek olyan eszközökre van szükségük, amelyekkel el tudják végezni az adatok A/B-tesztelését. Sok helyen ezt a feladatot SQL-lekérdezések írásával oldják meg, majd összevetik az eredményeket. Ha az adatkészletek egyszerűek, ez a megközelítés működhet. Ha azonban az adatfolyam több pontjának tesztelésére van szükség, valószínűleg dedikált eszközöket kell majd használni a tesztlekérdezések centralizálására és automatizálására, valamint a módosítások validálására. Ilyen eszköz a QuerySurge, amelyet kifejezetten az A/B-tesztelések végrehajtására terveztek.
Együttműködés szakértőkkel
A tesztelés bizonyos pontjain szükség lesz szakértők bevonására az új és frissített adatok vizualizációhoz történő felhasználásához és a visszajelzésekhez. Ők segíthetnek megválaszolni az olyan kérdéseket, hogy érvényes-e egy elemzés, használható-e összefüggések kinyerésére, illetve segíti-e a döntéshozatalt.
A témaszakértők idejének minél hatékonyabb kihasználása érdekében érdemes az alábbiak szerint eljárni:
- Végezzünk minél több adatminőségi, adattörténeti és A/B-tesztelést az arany adatkészleteken. Mielőtt bevonjuk a munkába a témaszakértőket, tegyünk meg mindent annak érdekében, hogy a nyers és kalkulált adatok helyesek legyenek.
- Tervezzük meg az adatvizualizációkat, hogy segítsünk a témaszakértőknek az adatok és elemzések áttekintésében és validálásában. Egyes vizualizációk lehetnek az A/B-tesztek eredményei, míg mások alapjául alacsony szintű adatok szolgálhatnak.
- Azt várjuk el a témaszakértőktől, hogy felhasználói elfogadási tesztelést (user acceptance testing, UAT) végezzenek a véglegesített alkalmazásokon és adatvizualizációkon. Mire eljutunk ehhez a lépéshez, teljesen biztosnak kell lenniük abban, hogy az adatok és elemzések érvényesek.
Végül az utolsó lépés annak vizsgálata, hogy a vizualizációk egyszerűen használhatóak-e. Megfelelő dimenziókat alkalmaztunk-e az adatok szemléltetéséhez? Segít-e a vizualizáció megválaszolni azokat a kérdéseket, amelyek megválaszolására létrehoztuk? A folyamat eme fázisában a felhasználói élményt teszteljük, és meggyőződünk arról, hogy a dashboardok és alkalmazások optimálisan működnek-e. Ez a lépés sokkal gördülékenyebben megy, ha biztosak vagyunk abban, hogy az alapul szolgáló adatok és elemzések helyesek.
