Teste pe computer, cele mai bune practici

Un pas esențial în orice dezvoltare IT, faza de test are ca scop verificarea faptului că livrabilul satisface nevoile exprimate de utilizator. O atenție deosebită va fi acordată asigurării faptului că instrumentul furnizat este utilizabil, ușor, într-o manieră durabilă, fără erori și produce ceea ce a fost construit într-un timp de răspuns acceptabil. Deși utilitatea sa este esențială, faza de testare este, din păcate, adesea luată ostatică de întârzierile acumulate de proiect și servește drept variabilă de ajustare pentru a respecta termenele limită. Prin urmare, în practică, nu va fi vorba de stabilirea faptului că sistemul funcționează corect în toate cazurile, ci mai degrabă de detectarea faptului că un anumit element nu funcționează conform așteptărilor în anumite condiții. După ce a trecut prin principalele tipuri și faze ale posibilelor teste, a doua parte va fi dedicată schimbului de bune practici pentru a desfășura această vânătoare de erori cât mai eficient posibil.

Un mic ocol prin teorie

Mai întâi este necesar să se facă distincția între niveluri de testare si tipuri de teste. Atragerea pe tărâmul posibilului ne oferă deja elemente pentru a structura corect testele și a le asigura completitudinea, în funcție de contextul proiectului.

Patru niveluri principale de testare poate fi șters:

Teste unitare: au ca scop verificarea funcționalității unei anumite secțiuni de cod, independent una de cealaltă. Prin urmare, vom identifica potențial un defect la o anumită locație.
Teste de integrare: Odată ce testele unitare au fost efectuate, aceasta implică testarea sistemului în ansamblu, adică prin integrarea tuturor componentelor sale. Sunt posibile două variante, în modul componentă sau în modul „big bang”.
Teste de sistem: scopul acestei faze este de a verifica dacă dezvoltarea funcționează corect în teorie, dar și în contextul dat de utilizator.
Teste de acceptare care caută să valideze dezvoltarea între diferite echipe de proiect (MOE => MOA) apoi cu utilizatorii.

În aceste nivele diferite se află diferite tipuri de teste. Putem cita pentru cele mai comune:

Și în practică ce dă ?

Nevoia de a avea o strategie și un plan de testare încă din faza de dezvoltare

În mod ideal, ar trebui să construim cazurile de testare funcționale ca și când specificațiile. Acest lucru permite, de exemplu, să confirmați comportamentul așteptat de utilizator reflectând asupra multiplelor cazuri posibile. Testele pot fi folosite și pentru a ilustra specificațiile oferind exemple, utile atât dezvoltatorului, cât și utilizatorului. Deoarece o parte semnificativă a bug-urilor este cauzată de neînțelegeri (Utilizatori/MOA sau MOA/MOE), ar fi greșit să nu favorizăm o comunicare bună din primele faze.

A fortiori, utilizarea testelor cuantificate face posibilă identificarea cazurilor extreme sau limită. Dacă un calcul necesită, de exemplu, prețul de execuție, ce se întâmplă dacă este negativ? Ar trebui să ofer o bară de protecție dacă e de rahat? Evităm astfel riscul de a pune aceste întrebări în următoarele faze, unde costul corectării erorilor poate fi mai mare (în special în gestionarea ciclului V, mai puțin în Agile).

În acest sens, așa-numitele metode de „testare continuă” (Test Driven Development, Behavior Driven Development), care combină atât codarea, cât și testele automate în procesul de construcție, oferă un mare avantaj: detectarea imediată a erorilor prin testarea simultană a pieselor tehnice și funcționale. Timpul este economisit, iar timpul înseamnă bani.

Importanța planificării

Este logic să coordonați fazele de testare sub un dublu aspect: tăiere și bugetare diversele teste pe de o parte, planificarea resurselor pe de altă parte.

Diferitele faze de test se suprapun între ele, deci nu putem trece la o fază fără să o fi validat pe cea anterioară, este de la sine înțeles. Nu există teste end-to-end înainte de testele de fum, strigă mareșalul La Palice! Mai precis, totuși, ar trebui acordată o atenție specială secvenței acestor teste, precum și duratei lor respective. Cât de dificil este un exercițiu, atât de dificil este estimarea sarcinii, specifică fiecărui proiect. Un eveniment neprevăzut care nu poate fi niciodată exclus, detectarea unei probleme poate duce uneori la apariția multor altele, mai numeroase și mai grave de corectat. Micul gândac se transformă apoi brusc într-un furnicar, unde multe alte fiare mici așteaptă liniștit, ghemuit în umbră, gata să iasă de îndată ce una dintre ele este descoperită. Pentru a evita orice impact asupra următoarelor faze și a datei de producție, se recomandă insistent să vă acordați o marjă de aproximativ 10% asupra sarcinii totale așteptate, doar pentru a vă simți confortabil dacă apare un element neașteptat. Intrați pe calea critică.