Dummy-data om tests mee uit te voeren zijn noodzakelijk. En erg gevaarlijk. Dit is de discussie-stelling die Computable-lezers vandaag krijgen voorgelegd.
Het uitvoeren van tests of het opzetten van testomgevingen kan omwille van beveiliging en privacy maar beter niet met echte data worden gedaan. Tegenover productiedata staat dus testdata. Een noodzakelijk en nuttig fenomeen in de ict-wereld. Alleen moet daar wel zorgvuldig mee worden omgegaan. Want testdata kan bij verkeerd gebruik grote schade aanrichten. Misschien nog wel meer schade dan waar testen met productiedata toe kan leiden.
Wie rekent er uit hoeveel financiële schade er is geweest door de fout van een aandelenhandelsbedrijf aangesloten bij tech-beurs Nasdaq dat de aandeelwaarde van zo’n zestien grote tech-bedrijven ineens op 123,47 dollar zette? Amazons koers leek hierdoor 87 procent ingestort, nipt meer dan de 86 procent daling voor Google. Tegelijkertijd scheen Microsoft wel tachtig procent meer waard te zijn en (Facebooks gamemaker) Zynga wel 3.292 procent meer. Testdata, een groot gevaar.
Wat vind jij?
Seems like all systems are running at 123.47% over at good ole’ @NYSE! pic.twitter.com/2IvhkVaISk
— Anil Dash (@anildash) July 4, 2017
Dit lijkt me niet zozeer een probleem van de testdata, maar eerder van de testomgeving.
In de tijd dat ik zelf nog betrokken was bij dit soort testen werden test en productie zorgvuldig gescheiden gehouden (wat soms best kostbaar is)
Bij de laatste testen waarbij we integratie met productie deden werd eerst een backup gemaakt van productie, vervolgens de testen gedaan en tot slot de backup weer terug gezet zodat alles “schoon” achterbleef. Dat betekende bijvoorbeeld ook dat alle interactie van de productieomgeving naar buiten tijdelijk stopgezet moest worden.
Dat alles staat los van de testdata, derhalve oneens met de stelling
Het is een kwestie van goed opletten wat je doet.
Omdat mensen fouten maakt je ervoor zorgt dat je veiligheid voorzieningen inbouwt die controleert welke data voor welke omgeving gebruikt wordt en als de combinatie niet goed is ervoor zorgt dat de data niet beschikbaar is voor gebruik. Tevens zijn verschillende veiligheids configuraties per omgeving ook aan te raden.
Goed beheer en zaken goed scheidden.
Begint met je software in je ontwikkelproces goed categoriseren.
Zo kun je hard afdwingen in je ontwikkelstraat dat unittesten alleen tijdens builds draaien, en dat stubs nooit verder komen dan een testomgeving.
In acceptatie draai je vervolgens de checks of de waarden in de database, terug komen in je processen (dus dat er niet een stub, of een hard coded waarde is meegekomen) zodat je het risico van testdata in een productieomgeving kan mitigeren.
Productiedata naar een testomgeving brengen is over het algemeen een nogo. Maskeren zonder het verlies van context blijft een lastige (zeker als klantnummers, mailadressen of zelfs bsn nummers primaire sleutels in je databases zijn), en niet maskeren is met de aangescherpte wetgeving illegaal.
Echter, veel bedrijfsprocessen bieden gewoon de mogelijkheden om zelf continu testdata te genereren conform productie. Waarom zou je niet vol automatisch elke dag x testklanten aanmaken met je echte processen op acceptatie. Deze x producten geven en daar vervolgens je mutaties op los laten. Een parallele wereld, waar je elke dag end-to-end je meest belangrijke processen draait, met productiesoftware (of een stabiele versie die productierijp is).
Pff, en nu zijn er lezers die denken: dat is heel veel inspanning, en dat kost veel tijd/geld/energie. Goed testen en kwaliteit borgen kost ook veel tijd/geld en energie. Hoe complexer je systeem en je business logica, hoe meer inspanning je kwijt kan zijn om de risico’s af te dekken. Daar moeten we gewoon met zijn allen eerlijk over zijn. En hoe langer je daarmee wacht (testen als losse fase na je ontwikkeltraject), hoe duurder en risicovoller het wordt. Kwaliteitsborging hoort onderdeel te zijn van je gehele proces, zodat je vroeg risico’s kan signaleren en mitigeren.
Testen = testen
Productie = productie
Niet zo moeilijk toch? Of worden we steeds dommer?
Testen = testen
Productie = productie
Niet zo moeilijk toch? Of worden we steeds dommer?
Testen = testen
Productie = productie
Niet zo moeilijk toch? Of worden we steeds dommer?