Testování na produkčním prostředí

Testům na produkci by se měli testeři obecně vyhýbat, bohužel jsou situace, kdy je takové testování nevyhnutelné (například když testovací prostředí plně neodpovídá produkčnímu a něco na něm nelze udělat).

Při testech je potřebné zachovávat několik pravidel, jinak může dojít k vážným malérům - od poškození produkčních dat, účetních problémů až po poškození dobrého jména firmy. Obzvlášť to platí v případech, pokud již na produkci existuje reálný provoz (tedy nejedná se o pilotní test čistého systému).

Často se na produkčním prostředí pro účely testování vytvoří "testovací objekt", nad kterým se pracuje - například v CRM systému se vytvoří "testovací zákazník". I přes "relativně bezpečnou" práci nad "nezávislou entitou" je potřebné si dát velký pozor na tyto věci:


1) O začátku a rozsahu testů informujte všechny dotčené role a organizace
Všichni, kteří s testem nějakým způsobem mohou přijít do kontaktu, tak by o tom měli být předem informováni - nejenže se bude testovat, ale i co se bude testovat a na jakých datech. Třeba aby se nestalo, že objednávku pračky na smyšlené jméno "Jarmila Pokusná" někdo opravdu zpracuje a zboží fyzicky odešle.


2) Zajistěte financování případných zdrojů pro test
U mobilních operátorů například se musí fyzicky vyrobit "testovací SIM karty" - někdo musí celou přípravu zaplatit, někdo ty SIM karty musí "vlastnit" a případně i platit došlé faktury (jelikož je to SIM jako každá jiná, pouze s nálepkou "testovací").

3) Veškeré "unikátní vlastnosti" testovacích záznamů volte tak, aby nedošlo k záměně s případným reálným záznamem (jak existujícím, tak vytvořeným v budoucnu). 

Například pokud chcete vytvořit v systému nového zákazníka a jako povinný údaj zadáváte jméno, příjmení a rodné číslo, volte tyto hodnoty tak, aby nedošlo k záměně s reálným zákazníkem - například dejte jméno "Testovací zákazník", rodné číslo volte tak, abyste minimalizovali riziko, že nějaký zákazník bude mít stejné rodné číslo.
(Tipy pro rodné číslo: buďto datum narození volte 29.února, případně využijte fintu, že "staré" rodné číslo mělo za lomítkem jen 3 číslice, takže můžete používat formát "nových" rodných čísel se 4 číslicemi za lomítkem, pokud to ovšem testovaná aplikace umožňuje; jiným řešením je vytvořit zákazníka, který bude mít podle rodného čísla např. 120 let, nebo 2 roky.)


4) Jakékoliv kontaktní údaje volte známé "testovací" (např. vaše telefonní číslo, testovací e-mailová schránka), v horším případě reálně neexistující (tady je to trochu ošemetné, pokud se v předpokladu "neexistence" mýlíte)
Pokud třeba nějaký o testu netušící uživatel systému bude chtít prověřit vaši "testovací" objednávku kvůli objednání zboží a zavolá na kontaktní číslo, tak aby bylo vaše.

5) Testujte výhradně na určených datech a veškeré provedené akce si zapisujte, včetně časových a jiných údajů potřebných k identifikaci transakcí. 

Nesmí se vám stát, že nějaká akce ovlivní jiná data, než měla (to už mělo být vyzkoušeno na testovacím prostředí) - ale pokud se tak nějakou náhodou stane, tak musíte přesně vědět, jaká akce byla vykonána a na čem, aby se to mohlo dát do pořádku. Navíc to úzce souvisí s dalším bodem.

6) Po skončení testů udělejte/zajistěte důkladný rollback všech akcí, které jste provedli - ze všech dotčených systémů !
Velmi častá chyba je, že tester smaže z databáze zákazníka a s ním i jeho objednávky a myslí si, že tím je vše "vyčištěno"- to ale nemusí být ani zdaleka pravda!
Musíte se ke všem akcím chovat tak, jako kdyby šlo o reálnou situaci. Čili není možné například platbu za službu jednoduše smazat z databáze, ale musíte ji stornovat, případně zaplatit a následně vystavit dobropis (každá platba jde do účetnictví a pokud ji jen "smažete", porušíte číslování dokladů a daňový úřad bude mít dobrý důvod přijet do firmy na kontrolu).
Ještě horší je, pokud máte váš systém propojen s třetími stranami, např. s dodavatelskou firmou - musíte je pak včas informovat, co jste testovali na jakém zákazníkovi, aby si i oni mohli stornovat příslušnou transakci (například vám neposílat v rámci testu objednanou novou televizi).
Krásný příklad z praxe uvádí na svém blogu James Bach, kterého SPZ "TESTER" nějaký tester použil při testování aplikace na vybírání parkovného a skončilo to soudní obsílkou pro nic netušícího Jamese.

Ještě vtipnější situace nastávají, když máte testovací prostředí, které někdo omylem (byť jen částečně) napojí na produkční systémy, ale o tom zase někdy příště.