Există un mit persistent în industrie: bug‑urile mari se văd înainte să ajungă în producție. Realitatea? Unele dintre cele mai costisitoare erori din istoria tehnologiei au trecut prin echipe întregi de ingineri — și nimeni nu le‑a prins la timp. Joi este ziua noastră de #TestingTriviaThursday, și am ales 5 bug‑uri care nu doar că au făcut titluri de presă, ci au redefinit felul în care gândim testarea software. Shall we?
TL;DR rapid: Fiecare bug de mai jos a avut o cauză tehnică simplă. Costul a fost uriaș. Lecția pentru tester? Predictibilă, dacă știi unde să cauți.
1. Ariane 5, 1996 — când 64 de biți nu încap în 16
Pe 4 iunie 1996, racheta Ariane 5 a Agenției Spațiale Europene s‑a autodistrus la 37 de secunde după lansare. Costul misiunii: aproximativ 370 de milioane de dolari. Cauza? Un număr în virgulă mobilă de 64 de biți a fost convertit forțat într‑un întreg de 16 biți. Overflow. Excepție neprinsă. Sistem de navigație oprit. Rachetă pierdută.
Lecția pentru tester: boundary value analysis nu este un exercițiu teoretic pentru examenul ISTQB. Este exact tipul de test care ar fi prins această conversie imposibilă înainte de lansare. Dacă lucrezi cu sisteme embedded, aerospace sau orice domeniu în care datele numerice circulă între module cu tipuri diferite, testele de limită sunt prima ta linie de apărare — nu ultima.
2. Therac‑25, 1985–1987 — un race condition care a costat vieți omenești
Therac‑25 era un aparat de radioterapie. Între 1985 și 1987, cel puțin șase pacienți au primit doze de radiații de 100 de ori mai mari decât cele prescrise. Unii au murit. Cauza tehnică: un race condition — o condiție de concurență între două procese software care accesau aceeași resursă fără sincronizare corectă. Eroarea apărea doar când operatorul taста foarte repede o secvență specifică de comenzi.
Lecția pentru tester: testarea manuală cu un singur flux fericit nu ajunge. Scenariile negative, ordinea neașteptată a acțiunilor utilizatorului și concurența între procese sunt exact ce acoperă un tester experimentat prin exploratory testing și, acolo unde sistemul o permite, prin teste automate de concurență. Dacă domeniul tău este medical, financiar‑bancar sau orice sistem critic, riscul nu este academic — este uman.
3. NASA Mars Climate Orbiter, 1999 — metrice imperiale vs. metrice SI
Sonda Mars Climate Orbiter a fost lansată în decembrie 1998 cu un buget de 327 de milioane de dolari. Pe 23 septembrie 1999, în loc să intre pe orbita Marte, s‑a dezintegrat în atmosferă. Motivul? O echipă folosea unități de măsură imperiale (pound‑force per second), cealaltă folosea unități metrice SI (newton per second). Nimeni nu a verificat interfața dintre cele două sisteme.
Lecția pentru tester: integration testing și contract testing există tocmai pentru aceste momente. Când două echipe — sau două sisteme, sau două microservicii — schimbă date, formatul și unitățile acelui schimb trebuie verificate explicit. În 2025, cu arhitecturi distribuite și API‑uri peste tot, această lecție este mai relevantă ca niciodată. Postman, schema validation, consumer‑driven contract testing cu Pact — toate pornesc de la același principiu: nu presupune, verifică.
4. Y2K, 1999 — bug‑ul care a mobilizat o industrie întreagă
Poate cel mai discutat bug din istoria IT‑ului, Y2K (Year 2000 Bug) a pornit de la o decizie de economisire a memoriei din anii '60: datele calendaristice erau stocate cu doar două cifre pentru an (99 în loc de 1999). Când ceasul urma să treacă în 2000, sistemele ar fi interpretat 00 ca 1900.
#FunFact: se estimează că între 300 și 600 de miliarde de dolari au fost cheltuiți la nivel global pentru remedierea acestui bug înainte de 1 ianuarie 2000. A fost, de fapt, cel mai mare efort de regression testing din istorie.
Lecția pentru tester: technical debt acumulat în timp devine o problemă de testare. Și, uneori, singura soluție este o campanie structurată de test analysis, prioritizare risk‑based și remediere sistematică. Exact ce se predă în modulele de ISTQB Foundation și Advanced la Academia Testarii.
5. Knight Capital Group, 2012 — 440 de milioane de dolari în 45 de minute
Pe 1 august 2012, firma de trading Knight Capital Group a pierdut 440 de milioane de dolari în mai puțin de 45 de minute din cauza unui bug în algoritmul de tranzacționare automată. Codul vechi, marcat pentru dezactivare, a fost reactivat accidental în timpul unui deployment pe un singur server din opt. Sistemul a plasat mii de ordine greșite pe bursă înainte ca cineva să poată opri procesul manual.
Lecția pentru tester: deployment testing și smoke testing post‑release nu sunt opționale. Un pipeline CI/CD fără verificări automate după fiecare deployment este un pariu, nu un proces. Dacă folosești GitHub Actions, Jenkins sau orice alt tool de automatizare, asigură-te că primul lucru rulat după deploy este o suită de smoke tests care confirmă că sistemul se comportă corect. Și, la fel de important, testează scenariile de rollback — nu doar calea fericită.
Ce au în comun toate cele 5?
Nici unul dintre aceste bug‑uri nu a fost exotic sau imposibil de anticipat. Toate au ieșit la suprafață din cauza unor goluri în procesul de testare: lipsă de boundary testing, absența integration testing, deployment fără verificare, ignorarea scenariilor negative.
Mindset‑ul unui tester bun nu este "să găsesc bug‑uri". Este "să înțeleg unde sistemul poate eșua și să construiesc filete de siguranță înainte ca eșecul să coste". Diferența dintre cele două abordări se vede cel mai clar tocmai în poveștile de mai sus.
La A4Q Summit și la DevTalks, subiectul riscului în testare revine an de an — nu pentru că industria nu a învățat, ci pentru că fiecare generație de testeri are nevoie să internalizeze aceste lecții în context propriu: automotive, banking, retail, energie, healthcare.
Vrei să înveți să gândești ca un tester care prinde bug‑uri înainte de producție?
La Academia Testarii găsești cursuri practice — de la ISTQB Foundation Level până la automatizare cu Selenium, Playwright și Cypress — construite tocmai pe tipul de gândire ilustrat în exemplele de mai sus: risk‑based, structurat, aplicabil de luni.
Dacă ești la început de drum sau vrei să îți validezi experiența printr‑o certificare recunoscută internațional, fă primul pas pe academiatestarii.ro. 🚀
Iar dacă acest articol ți‑a adus un insight util, share‑uiește‑l cu un coleg de echipă — s‑ar putea să fie exact lecția de care are nevoie înainte de următorul release. 🐞
#DeAziEstiTester #AcademiaTestarii #SoftwareTesting #TestareSoftware #ISTQB