Příprava testovacích dat II. - data z produkce

Nejčastějším způsobem přípravy testovacích dat je jejich "zkopírování" z produkčního prostředí do testovacího prostředí. Dnes uvedu pár tipů, jak na to a na co si dát pozor.

Především je důležité správné plánování celého procesu, to zahrnuje:

1) Musí být stanoven datum a čas, ze kterého bude vytvořen "snapshot" produkčních dat z jednotlivých systémů, případně i stanovení postupnosti "přeplachů" jednotlivých systémů. Je to kritické hlavně v případech, pokud jsou data uložena ve více nezávislých systémech (propojených přes integraci) - zabráníte tím velké nekonzistenci dat. 

Příklad, co se může stát. Zákazník byl založen 20.2.2011 v systému CRM a v systému pro fakturaci. Z technických důvodů "přeplach" z produkce je možné pro CRM udělat jen 23.2.2011 (z pravidelné zálohy produkčních dat) a ze systému fakturace jen 25.2.2011.
Ve výsledku po nalití těchto dat do testovacího prostředí nastane situace, že zákazník bude "existovat" v CRM, ale ne ve fakturačním systému, takže případný test case "modifikuj fakturační adresu" tuto sice bez problémů změní v CRM, ale ve fakturačním systému skončí akce s chybou "zákazník neexistuje".
To může vést k nareportování chyby "ve fakturačním systému nebyla změněna adresa" (pokud testeři nekontrolují i logy aplikace ale jen GUI), následnému zamítnutí ze strany vývojáře (chyba testovacích dat) a snižování reputace testerů ("hoax" chyby).

2) Musí být rozdělena odpovědnost za jednotlivé akce, stanoven rozpočet
Nejdůležitější je určit, kdo bude vytvářet "zálohu" produkce a kdo bude tuto "zálohu" kopírovat na testovací prostředí pro jednotlivé systémy.
Je to velmi pracná záležitost, která jde ve většině případů "mimo testerské oddělení", takže na to musí být vyčleněny příslušné zdroje (lidi, peníze).

3) Nutné je i určení "podmnožiny" dat, které budou reálně převedeny z produkce do testovacího prostředí.
Často je testovací prostředí oproti produkci kapacitně omezeno, například do testovací databáze CRM systému se "vejde" jenom 30000 zákazníků se souvisejícími daty (protože je například používaná bezplatná "express" edice databáze, která má limit 2 GB). Je tedy nutné určit množinu dat, která se reálně z produkce do testovacího prostředí přenese.

4) O přeplachu dat je potřebné informovat všechny, kteří cokoliv dělají na testovacím prostředí.
Přeplach dat způsobí "výpadek" testovacího prostředí, takže jej nebude možné používat na testy. Pokud je jedno prostředí "sdílené" mezi různými projekty, musí o tom "výpadku" vědět všichni dotčení uživatelé (test manažeři + projekťáci). Navíc velmi doporučuji datum plánovaného výpadku s nimi konzultovat ještě dřív, než je finálně domluvený "přeplach" - pokud by ten přeplach ohrožoval projekty, muselo by se stejně zvolit jiné datum.


Akce po přeplachu dat

Máte na testovacím prostředí "přeplácnuto". Takže je vše hotovo?
Ještě ne. Zbývá udělat ještě tři věci:

1) Ochrana citlivých dat
V testovacím prostředí teď máte citlivé údaje o zákaznících (rodná čísla, adresy, faktury...) - tohle musíte nějak "pořešit". Buďto zvažte anonymizaci dat (je nutné přesně určit, co se má z těch dat anonymizovat - například rodné číslo...), nebo dejte alespoň příslušným externím testerům/vývojářům podepsat dohodu o mlčenlivosti (NDA), pokud ji již podepsanou nemají.

2) Kontrola přepojení systémů
Při přeplachu dat, které se vykonávají zálohováním databáze a jejím následným "obnovením" na testovacím prostředí často dochází k tomu, že se takto na testovací prostředí "obnoví" i produkční konfigurace.
Takže například testovací CRM systém bude následně obsahovat connection string na PRODUKČNÍ fakturační systém a pokud v testovacím CRM systému uděláte nějaký test, tak se výsledky projeví v produkční fakturaci a zákazník zaplatí něco, co si neobjednal.

Zážitek z praxe - takhle nám přeplácli server na přenos telefonního čísla "MNP", administrátoři ale zapomněli upravit tyto "connection stringy" z produkčních na testovací. Na testovacím prostředí jsem tak dělal test přenosu čísla k jinému operátorovi, z testovacího CRM šel požadavek do testovacího MNP serveru (což bylo v pořádku), ten to ale poslal do produkčního MNP serveru druhého mobilního operátora a ten začal tuto portaci reálně zpracovávat - takže mi málem fyzicky přenesli číslo. Ještě štěstí, že jsem po letech v oboru trochu paranoidní a zkoušel jsem to nejdřív na svém soukromém čísle v testovací databázi - jiný zákazník by nejspíš měl bez online komunikace s IT velký problém.

Pozor i na takové "drobnosti", jako je konfigurace spojení na SMS centrum (zákazníkovi budou chodit SMSky) nebo konfigurace SMTP serveru (pokud je nějaký připojen do internetu, zákazníkům budou chodit "záhadné" e-maily).

3) Manažment testovacích dat
Počítejte s tím, že "přeplach" z důvodu náročnosti u velkých systémů nebudete moct dělat každý týden - spíše tak jednou za půl roku. Takže nějaký čas budete muset s těmito daty "vydržet".
Musíte je tedy nějakým způsobem "manažovat", zvlášť pokud máte jenom podmnožinu produkčních dat. Tedy například zákazníky označovat jako "již použité", "ještě nepoužité" a třeba je po každém releasu "recyklovat" - zjistit, že již použitý zákazník je například využitelný pro jiný test (stačí například sdílený Excel, nebo můžete použít i "sofistikovanější" způsob).

Moje zkušenost z "recyklace". U zákazníka jsou 2 testovací prostředí pro CRM systém (CRM-A, CRM-B), ale jenom jedno testovací prostředí pro fakturační systém (INV-T). Jelikož pro testy musí být tato prostředí propojena, tak se CRM-A a CRM-B "přepláchnou" stejnými daty z produkce, podobně jako INV-T. Následně se střídavě podle potřeb projektu připojují systémy CRM-A a CRM-B k prostředí INV-T.
Tím samozřejmě dochází k značnému znehodnocení dat (při propojeném CRM-A k INV-T deaktivujete zákazníka, pak když připojíte CRM-B, tak tam je zákazník aktivní, ale v INV-T je deaktivní a máte nekonzistenci).

Pro zabránění nutných častých přeplachů jsem naprogramoval nástroj, který kontroluje, že zákazník je ve stejném "stavu" v právě připojeném CRM systému (A nebo B) a v INV-T.
Možná se to nezdá, ale tím, že před každým začátkem testů takhle vytvořím "množinu validních dat" na testovacím prostředí, značně se snížil počet nahlášených bugů s výsledkem "chyba testovacích dat" a navíc nebylo nutné tak často přeplachovat systémy (až když se množství "využitelných dat" značně snížilo) - na každém "ušetřeném přeplachu" bylo ušetřeno cca 30 mandays, což jsou ve světě IT velmi slušné peníze.

Příklad jsem trochu zjednodušil pro lepší pochopení, ve skutečnosti bylo těch "sdílených testovacích systémů" 8 a "nezávislé testovací systémy" byly 2.

Na závěr možná link na výrobce, který vyrábí dobré komerční nástroje pro práci s testovacími daty - Grid Tools - žádné jiné podobné produkty jsem nevygooglil. Pokud tedy máte nějaký další tip na nějaký vhodný nástroj na manažment testovacích dat (nejlépe open-source), podělte se v diskuzi.