Testare software automată — ghid pentru fondatori non-tehnici
Fiecare client ne întreabă: «de ce costă atât de mult testarea?» Răspunsul scurt: pentru că un bug în producție costă de 10-100 de ori mai mult decât testul care l-ar fi prins. Răspunsul lung: testarea nu e un cost adițional, e o asigurare. Iată ce primești de fapt când plătești pentru testare automată și cum recunoști o echipă care testează bine.
Ce este testarea software (și ce nu este)
Testarea înseamnă verificarea că aplicația face ceea ce trebuie, în condițiile în care trebuie. Există două abordări: manuală (o persoană dă click-uri prin aplicație și verifică) și automată (cod scris special care rulează verificări în câteva secunde, de sute sau mii de ori pe zi).
Testarea manuală are un loc — pentru UX, pentru explorare, pentru verificarea vizuală. Dar nu scalează. Dacă ai 200 de funcționalități și faci o modificare, un tester uman nu poate verifica manual toate cele 200 înainte de fiecare release. Testele automate fac exact asta: rulează în 30 de secunde și îți spun «100% din verificări trec» sau «3 teste au picat, iată exact unde».
Ceea ce NU este testarea: a da aplicația la un grup de prieteni să «o mai folosească puțin». Feedback-ul lor e valoros pentru UX, dar nu e testare. Nu reproduce condițiile de producție, nu verifică cazurile limită și nu rulează repetabil.
Cele trei tipuri de teste automate
Orice echipă serioasă folosește trei niveluri de teste. Fiecare prinde alt tip de problemă:
| Tip test | Ce verifică | Timp de execuție | Cât din cod acoperă |
|---|---|---|---|
| Unitare (unit tests) | O singură funcție sau modul izolat | Milisecunde | Cel mai mult |
| De integrare (integration tests) | Modurile care comunică între ele (API + DB, frontend + backend) | Secunde | Mediu |
| End-to-end (E2E) | Flux complet de utilizator, de la login la checkout | Minute | Cel mai puțin ca număr, cel mai aproape de realitate |
Teste unitare — fundația
Un test unitar ia o funcție, îi dă un input specific și verifică că output-ul e corect. De exemplu: funcția care calculează prețul cu discount. Testul îi dă prețul 100 RON și discount 20%, și verifică că rezultatul e 80 RON. Apoi îi dă preț 0 RON și discount 50% și verifică că rezultatul e 0, nu eroare. Apoi preț negativ și verifică că funcția respinge input-ul.
Testele unitare sunt cele mai rapide (mii rulează în sub 10 secunde), cele mai ieftine de scris și cele mai stabile. O echipă bună are 70-80% din cod acoperit de teste unitare.
Teste de integrare — verifică conexiunile
Fiecare funcție poate funcționa corect individual, dar când API-ul trimite date către baza de date, iar baza de date returnează un format diferit de cel așteptat, aplicația pică. Testele de integrare verifică exact aceste puncte de contact. Rulează mai încet (pornesc baza de date, fac request-uri HTTP reale), dar prind probleme pe care testele unitare nu le pot vedea.
Teste end-to-end — simulează utilizatorul real
Un test E2E deschide un browser real, navighează la site-ul tău, face click pe «Cont nou», completează formularul, apasă «Plătește», și verifică că comanda apare în dashboard-ul admin. E cel mai aproape de ceea ce experimentează un utilizator real. Dezavantajul: sunt lente (minute, nu secunde) și fragile (un mic delay de rețea poate face testul să eșueze fals). Echipa bună folosește E2E selectiv — doar pentru fluxurile critice (checkout, înregistrare, plată), nu pentru fiecare pagină.
De ce contează — costul real al bug-urilor
Un bug prins în faza de dezvoltare costă în medie €5-€50 de remediere. Același bug ajuns în producție costă €500-€5.000: timp de diagnosticare, pierderi de vânzări în timpul în care aplicația e blocată, suport client, și uneori daune de imagine greu de cuantificat. Diferența e de 10-100x.
Exemple concrete din piața românească:
- Magazin online cu checkout stricat — 8 ore de downtime în Black Friday = zeci de comenzi pierdute. Bug-ul: o validare care respingea cardurile emise de o bancă anume. Un test de integrare l-ar fi prins.
- Aplicație mobilă care nu sincroniza datele — utilizatorii pierdeau comenzi offline. Fixat după 3 zile de plângeri și rating-uri de 1 stea în App Store. Un test E2E l-ar fi prins înainte de release.
- Integrare ANAF care trimitea facturi duplicate — descoperit abia la verificarea fiscală, 6 luni mai târziu. Un test unitar pe funcția de retry l-ar fi prins la prima rulare.
Cum evaluezi dacă echipa ta testează bine
Aici intervine partea practică. Chiar dacă nu scrii cod, poți evalua calitatea testării din trei indici concreți:
- Cere să vezi pipeline-ul de CI. «CI» înseamnă continuous integration — un sistem care rulează toate testele automat la fiecare modificare. Dacă echipa are CI configurat (GitHub Actions, GitLab CI, sau un alt runner), testează regulat. Dacă «rulează testele manual când ține minte», nu testează regulat.
- Cere raportul de acoperire (coverage). Acoperirea e procentul din cod atins de teste. Peste 70% e bine. Sub 40% înseamnă că mari porțiuni din aplicație nu sunt verificate automat. Zero înseamnă că nu există teste automate deloc.
- Întreabă ce se întâmplă când un test pică. Răspunsul corect: «Build-ul e blocat, nu se face deploy până nu se repară.» Răspunsul greșit: «Le ignorăm și le reparăm când avem timp.» Testele care sunt ignorate nu sunt teste — sunt false iluzii de siguranță.
Cât costă testarea — cifre reale
Testarea adaugă timp de dezvoltare. Regula empirică: 15-30% din timpul total al proiectului se duce pe scrierea și mentenanța testelor. Aceasta nu e risipă — e costul prevenirii.
| Tip proiect | Buget dezvoltare | Cost teste (15-30%) | Ce previne |
|---|---|---|---|
| Site de prezentare (5 pagini statice) | €2.000 – €5.000 | €300 – €1.500 | Link-uri stricate, layout pe mobil |
| Magazin online (WooCommerce/Shopify) | €5.000 – €20.000 | €750 – €6.000 | Checkout stricat, prețuri greșite, stoc negativ |
| Aplicație web SaaS (custom) | €15.000 – €60.000 | €2.250 – €18.000 | Date utilizatori pierdute, plăți duplicate, acces neautorizat |
| Aplicație mobilă (React Native / nativ) | €10.000 – €40.000 | €1.500 – €12.000 | Crash-uri pe dispozitive specifice, sync offline |
| Plată / FinTech | €30.000 – €150.000 | €4.500 – €45.000 | Bani greșit transferați, conformitate PSD2 |
Pentru proiectele critice (plăți, date personale, conformitate legală), testarea nu e opțională — e cerință contractuală și uneori legală. PSD2, GDPR și SOC 2 cer dovezi de testare.
Când NU merită să investești masiv în teste
Aici trebuie să fiu sincer. Nu toate proiectele au nevoie de suite de teste complete:
- Prototip de validare — dacă build-uiesti un demo care va fi aruncat în 2 săptămâni, testele sunt risipă. Scopul e să înveți, nu să fii robust.
- Landing page simplu — o pagină HTML statică fără logică nu are ce să se strice. Verificarea vizuală e suficientă.
- Funcționalitate experimentală — dacă nu știi dacă vei păstra feature-ul, scrii testul după ce decizi că rămâne.
Regula: testul se scrie pentru codul care rămâne în producție mai mult de o lună și a cărui stricare generează cost. Restul e exces.
Testarea în practică — ce ar trebui să vezi la echipa ta
O echipă care ia testarea în serios are următoarele în loc:
- Pipeline CI verde. La fiecare commit, testele rulează automat. Verde înseamnă «toate trec». Roșu înseamnă «niciun deploy până nu se repară».
- Teste înainte de feature-uri noi. Dezvoltatorul scrie testul pentru noul comportament, apoi implementează codul care îl face să treacă. Aceasta se numește TDD (test-driven development) și reduce bug-urile cu 40-60% conform studiilor din industrie.
- Teste de regresie. Când se găsește un bug în producție, se scrie un test care îl reproduce, apoi se repară codul. Bug-ul respectiv nu se va mai întâmpla niciodată — testul îl va prinde.
- Monitoring în producție. Testele previn, dar nu pot prinde tot. Sentry sau un tool similar prinde erorile care ajung la utilizatori și le raportează în timp real.