Asigurarea calitatii software si testarea

Asigurarea Calitatii

Testarea software presupune punerea in functiune a unui sistem sau a unei aplicatii in conditii controlate si evaluarea rezultatelor (de exemplu, "in cazul in care utilizatorul este in interfata A a aplicatiei in timp ce foloseste hardware-ul B, si opereaza in C, atunci ar trebui sa se produca D"). Conditiile controlate trebuie sa includa atat conditii normale cat si anormale. Testarea ar trebui sa faca lucrurile sa nu mearga bine in mod intentionat cu scopul de a determina daca lucrurile se produc atunci cand acestea nu ar trebui sau daca acestea nu se produc atunci cand ar trebui. Testarea software este orientata spre "detectare".

E posibil ca unele proiecte sa nu solicite personal de testare independent pentru a se derula.



Ce proiecte ar putea sa nu aiba nevoie de personal de testare independent? Raspunsul depinde de dimensiunea si contextul proiectului, de riscuri, de metodologia de dezvoltare, de calificarea si experienta dezvoltatorilor si alti factori. De exemplu, in cazul in care proiectul este pe termen scurt, mic ca dimensiune, cu un risc scazut, cu programatori extrem de experimentati care folosesc unitati de testare aprofundata, e posibil ca inginerii de test sa nu fie necesari pentru ca proiectul sa aiba succes.



In unele cazuri, o organizatie IT poate fi prea mica sau noua pentru a avea un personal de testare, chiar daca situatia o cere. In aceste circumstante, ar putea fi oportun sa se apeleze la contractori sau externalizare, sau sa se ajusteze abordarea managementului de proiect si dezvoltare (prin trecerea la dezvoltatori mai experimentati si o prima testare mai profunda, de exemplu).



Pentru proiecte de marime nontriviala sau proiecte cu riscuri nontriviale, de obicei este necesar un personal de testare. Ca in orice afacere, utilizarea de personal cu aptitudini specializate sporeste capacitatea unei organizatii de a fi de succes in sarcini mari, complexe sau dificile. Aceasta va avea atat competente mai profunde si mai puternice cat si contributii din perspective diferite. De exemplu, programatorii au de obicei perspectiva "care sunt problemele tehnice in efectuarea acestei functionalitate de lucru?". Un inginer de testare are de obicei perspectiva "ce ar decurge rau in aceasta functionalitate si cum se poate asigura satisfacerea asteptarilor?". O persoana tehnica care poate fi foarte eficienta in abordarea sarcinilor ambelor perspective este rara, motiv pentru care, mai devreme sau mai tarziu, organizatiile apeleaza la specialisti de testare.

* Comunicarea insuficienta sau lipsa de comunicare – specificatiile referitoare la ceea ce la aplicatia ar trebui sau nu ar trebui sa faca (cerintele aplicatiei).

* Complexitatea software - complexitatea aplicatiilor software curente poate fi dificil de inteles pentru persoanene fara experienta in dezvoltarea software moderna. Sisteme distribuite pe mai multe nivele, aplicatii ce folosesc mutliple servicii web locale si la distanta, comunicari de date, baze de date relationale enorme, complexitatea securitatii si dimensiunea mare de aplicatii contribuie toate la cresterea exponentiala in software-ul/sistemul de complexitate.

* Erori de programare - programatorii, ca oricine altcineva, pot face greseli.

* Schimbarea cerintelor (cu documentatie sau fara) - utilizatorul final ar putea sa nu inteleaga efectele schimbarilor, sau poate sa inteleaga si sa solicite redesign, reesalonare de ingineri, efecte pe alte proiecte, lucrari deja realizate care trebuie refacute sau lasate la o parte, cerinte hardware care pot fi afectate, etc. Daca exista multe schimbari minore sau o schimbare majora, dependente cunoscute si necunoscute intre partile proiectului vor interactiona si pot provoca probleme, precum si complexitatea schimbarilor de coordonare poate duce la erori. Entuziasmul personalului de inginerie poate fi afectat si el. In unele medii de afaceri ce suporta schimbari rapide, cerintele modificate in mod continuu pot fi un fapt in derularea proiectelor. In acest caz, managementul trebuie sa inteleaga riscurile aferente, iar inginerii de test si asigurarea calitatii trebuie sa se adapteze si sa planifice testarea continua pentru a evita ca bug-urile sa iasa se sub control.

* egourile

* presiunile de timp – programarea proiectelor software este dificila, necesitand adesea o multime de presupuneri. Atunci cand apar termenele limita se instaleaza si o atmosfera de criza si astfel pot sa apara greseli.

* cod slab documentat - este greu sa se mentina si sa se modifice codul prost scris sau prost documentat, rezultatul fiind bug-urile. Multe organizatii de management nu cer programatorilor sa-si documenteze codul sau sa scrie cod cat mai clar, usor de inteles, usor de intretinut. De fapt, este de obicei invers: primesc puncte pentru rapiditatea scrierii codului, si nu este problema lor in cazul in care nimeni nu il intelege.

* instrumente de dezvoltare software - instrumente vizuale, librarii de clase, compilatoare, instrumente de scripting, etc. introduc adesea bug-uri proprii sau sunt prost documentate, rezultand bug-uri adaugate.