Secțiunile articolului
Aceeași scenă revine de-atâtea ori încât a devenit un tipar: un patron de restaurant sau un manager de magazin sună entuziasmat. „A funcționat perfect în demo. Am dat click, s-a sincronizat stocul, s-a trimis factura, totul instant.” Semnează contractul, instalează sistemul în producție. A doua zi, telefonul sună invers. „Nu mai merge. Trimite facturi duble, pierde date, iar clienții sună să întrebe unde le sunt banii.”
Vina nu ține de client, ci de felul în care testăm. Verificăm traseul ideal, nu traseul pe care îl parcurge un sistem când lucrurile ies din tipar: cu date incomplete, cereri simultane și o rețea care întârzie exact în momentul nepotrivit.
Demo-ul e o bucătărie goală
Când arăți o automatizare în demo, ai pregătit totul dinainte. Baza de date conține doar date proaspete, fără intrări vechi, fără caractere ciudate, fără comenzi parțial finalizate. Rețeaua e locală, latența zero. Serverul e gol, CPU-ul doarme. Nu există concurență. Niciun alt proces nu citește sau scrie în aceleași fișiere.
E ca și cum ai demonstra un nou cuptor într-o bucătărie goală, cu o singură tigaie și un singur cartof. Funcționează impecabil. Apoi îl instalezi într-o bucătărie reală, cu zece bucătari, ulei care stropește, comenzi care vin în același timp și frigiderul deschis de o sută de ori pe zi. Cuptorul e același. Mediul nu.
O automatizare pică în producție pentru că nimeni n-a gândit haosul pe care îl generează oamenii și sistemele când lucrează în paralel. Codul execută fix instrucțiunile scrise. Dacă nimeni nu i-a spus ce să facă atunci când datele lipsesc sau cererile se ciocnesc, nu are de unde ști. Se oprește. Simplu.
Erori pe care nimeni nu le-a prevăzut
În demo, totul e scenariul fericit. Utilizatorul introduce date corecte, câmpurile sunt complete, serverul răspunde prompt. În producție, un ospătar pune un spațiu în plus la nume, un furnizor trimite un fișier cu o coloană lipsă, o conexiune de rețea pică exact când automatizarea așteaptă un răspuns. Eroarea nu e în instrucțiunea dată, ci în lipsa instrucțiunii pentru momentul în care ceva nu e perfect.
O automatizare care în demo citea câteva înregistrări ajunge, în producție, să primească mii, unele cu câmpuri goale, altele cu date de acum câțiva ani. Problema nu ține de viteză. Ține de logică: codul nu știa ce să facă cu o valoare lipsă. Cădea.
În practică, cât timp rulezi doar pe cazul fericit, vei descoperi problemele abia când e prea târziu.
Resursele nu sunt infinite
Demo-ul rulează de obicei pe un laptop sau pe un server dedicat, cu o singură conexiune la baza de date. În producție, aceeași automatizare concurează cu alte aplicații pentru memorie, timp de procesor și viteză de rețea. Dacă nu ai gândit limite de așteptare, reluări după un eșec sau un spațiu de lucru pentru scrieri concomitente, sistemul cedează sub sarcină.
E ca și cum ai avea o singură chiuvetă într-o bucătărie de restaurant. În demo, speli un pahar. În producție, zece ospătari aduc farfurii în același timp. Chiuveta nu e problema. Faptul că nu ai gândit rândul e problema.
Diferența pe scurt
| Demo | Producție |
|---|---|
| Date curate, puține, previzibile | Date murdare, multe, imprevizibile |
| Fără concurență | Zeci de procese simultane |
| Rețea locală, latență zero | Rețea reală, întârzieri, pierderi de conexiune |
| Resurse aparent nelimitate | Resurse limitate, partajate |
| O singură stare posibilă | Sute de stări: erori, duplicate, date parțiale sau goale |
| Testat de inginerul care l-a scris | Folosit de oameni care nu știu cum funcționează |
Cum schimbi rezultatul
Testarea bună nu pornește de la scenariul fericit. Pornește de la întrebarea inversă: ce poate merge prost? Ce faci dacă fișierul e gol? Dacă baza de date răspunde cu o eroare? Dacă utilizatorul închide programul la jumătatea procesului?
Aceste cazuri se scriu în teste înaintea codului principal, nu după, pentru că un test scris după ce ai văzut eroarea în producție ajunge mereu prea târziu. Așa, demo-ul arată că sistemul merge, se oprește curat, se recuperează rapid și nu pierde informații.
Patronii și managerii nu trebuie să știe de timeout-uri sau de mecanisme de reluare. Trebuie să știe să ceară, înainte de semnare, un plan de testare a eșecurilor. Întrebarea e simplă: „Ce faci dacă serverul nu răspunde? Ce faci dacă angajatul greșește datele?” Dacă răspunsul e „nu pică niciodată”, e semn roșu.
Înainte să accepți o automatizare, cere testele pentru fișier gol, timeout, date duplicate și oprire la jumătatea procesului. Dacă furnizorul nu poate arăta recuperarea pentru fiecare caz, nu considera demo-ul o dovadă de robustețe.