Testare software

Testarea software reprezintă o investigație empirică realizată cu scopul de a oferi părților interesate informații referitoare la calitatea produsului sau serviciului supus testării^[1], luând în considerație contextul operațional în care acesta din urma va fi folosit. Testarea software pune la dispoziție o viziune obiectivă și independentă asupra produsului în dezvoltare, oferind astfel businessului posibilitatea de a înțelege și evalua riscurile asociate cu implementarea produsului soft. Tehnicile de testare includ, dar nu sunt limitate la, procesul de execuție a programului sau aplicației în scopul identificării defectelor/erorilor de software. Testarea software mai poate fi definită ca un proces de validare și verificare a faptului că un program/aplicație/produs software (1) corespunde business cerințelor și cerințelor tehnice care au ghidat proiectarea și implementarea lui; și (2) rulează și se comportă corespunzător așteptărilor.

În dependență de metodologia de testare aleasa, testarea software poate fi implementată la orice etapă în cadrul procesului de dezvoltare, deși partea considerabilă a efortului de testare este aplicată de obicei la etapa de după cizelarea/formalizarea cerințelor și finisarea implementării/codării propriu-zise.

Generalități

Nu există un astfel de proces de testare ce ar permite identificarea tuturor defectelor posibile ce le poate conține un produs software. În schimb, un astfel de proces poate furniza o viziune critică sau comparativă, care vine sa contrapună unele aspecte ale produsului (cum ar fi: starea și comportamentul actual) și metricile și constrângerile care servesc drept criterii de acceptanță. Aceste criterii pot fi derivate din specificații tehnice, produse asemănătoare comparabile, versiuni anterioare ale aceluiași produs, așteptari față de produs enunțate de către utilizator sau client, standarde relevante, legi în vigoare, etc.

Fiecare produs software are o audiență caracteristică. De exemplu, audiența pentru un produs din industria jocurilor video este complet diferită de audiența unui produs din sistemul financiar-bancar. De aceea, când o organizație dezvoltă sau investește în dezvoltarea unui produs software, ea trebuie să fie capabilă să evalueze acceptabilitatea produsului din perspectiva utilizatorilor finali, audienței țintă, cumpărătorilor și altor părți interesate. Testarea software este procesul care vine sa facă această evaluare posibilă într-un mod cât mai obiectiv.

Un studiu efectuat în anul 2002 de către NIST a arătat că pierderile anuale pentru economia S.U.A. cauzate de defecte de software se estimează la 59.5 miliarde de dolari. Mai mult de o treime din aceste pierderi ar putea fi evitate dacă s-ar face investiții mai serioase în implementarea procesului de testare.^[2]

Istoric

Gelperin și Hetzel au analizat evoluția conceptului de testare a unui sistem informatic și au împărțit evoluția acestuia în mai multe etape, în funcție de filozofia care a stat la baza conceptului:

1945 - 1956 - Orientarea spre depanare

Testarea programelor informatice este o activitate care a apărut odată cu procesul de dezvoltare a acestora. În perioada apariției primelor sisteme informatice - 1945-1956, procesul de testare era în special orientat către componentele hardware ale sistemului, iar defectele din software erau în general considerate ca fiind mai puțin importante. Persoanele care elaborau codul se ocupau și de partea de testare, deși nu o făceau într-o manieră metodică, și denumeau această activitate verificare. Pentru mulți dintre oamenii de știință care se ocupau de scrierea programelor informatice nu exista o distincție clară între activitățile de scriere a codului, testare și depanare. Din această perioadă timpurie datează prima referire la conceptul de "bug" într-un sistem informatic, când un operator al unui calculator descoperă pe un circuit electronic care funcționa defectuos o molie, și o atașează în jurnalul de operațiuni, cu mențiunea ca a descoperit primul "bug" propriu-zis într-un calculator. Termenul de "bug" în sine este mai vechi, datând din perioada lui Thomas Edison. Primul savant care s-a ocupat de noțiunea de testare a unui program este Alan Turing care publică în 1949 un articol despre principiile teoretice ale verificării corectitudinii funcționării unui program. În 1950, Turing publică un alt articol, în care ridică problema inteligenței artificiale, și definește un test pe care sistemul informatic trebuie să îl treacă, și anume răspunsurile oferite de către acesta la întrebările adresate de un operator (testerul) să nu poată fi diferențiate de către răspunsurile oferite de un om (etalonul). Această lucrare poate fi considerată a fi prima care se ocupă de conceptul de testare, considerat distinct de activitățile de elaborare a codului respectiv de depanare.

1957 - 1978 - Orientarea spre demonstrație^[3]

Pe măsură ce sistemele informatice creșteau în număr, complexitate și cost, procesul de testare a căpătat o importanță tot mai mare. Testarea pe scară largă a devenit necesară datorită creșterii impactului economic pe care defectele nedetectate le puteau avea. De asemenea, persoanele implicate în dezvoltarea de programe informatice au devenit mai conștiente de riscurile asociate cu defectele din programe și au început să pună mai mult accent pe testarea și remedierea defectelor înainte ca acestea să afecteze produsul livrat. În această perioadă, termenii de testare și depanare se suprapuneau și se refereau la eforturile făcute în scopul descoperirii, identificării și remedierii defectelor din sistemele informatice. Scopul procesului de testare era demonstrarea corectitudinii funcționării programului, adică absența erorilor.

1979 - 1982 - Orientare spre defectare"^[4]

Conceptele de depanare și testare devin mai riguros separate o dată cu publicarea de către Glenford J. Myers a lucrării The Art of Software Testing, în 1979. Myers face distincția dintre depanare care este o activitate care ține de dezvoltarea programului și testarea care este activitatea de rulare a unui program cu scopul declarat de a descoperi erori. De asemenea, el susține că în testarea bazată pe demonstrație există pericolul ca operatorul să aleagă în mod inconștient acel set de parametri care ar asigura funcționarea corectă a sistemului, ceea ce creează pericolul ca multe defecte să treacă neobservate. Myers propune în abordarea sa și o serie de activități de analiză și control care împreună cu procesul de testare să crească nivelul de calitate a sistemelor informatice.

1983 - 1987 - Orientarea spre evaluare^[5]

În 1983, Biroul Național de Standarde din Statele Unite ale Americii publică un set de practici adresate activităților de verificare, validare și testare a programelor de calculator. Această metodologie, adresată în mod specific instituțiilor americane federale, cuprinde metode de analiză, evaluare și testare care să fie aplicate de-a lungul ciclului de viață al aplicației. Ghidul de bune practici sugerează alegerea unor diverse metode de verificare și validare, în funcție de caracteristicile fiecărui proiect în scopul creșterii calității generale a produsului. În anii '70 nivelul de profesionalism al persoanelor implicate în activitatea de testare a crescut simțitor. Apar posturile dedicate de tester, manager de teste sau analist de teste. Apar de asemenea organizații profesionale ale celor care activează în domeniul testării software, precum și publicații specializate, cărți și articole de specialitate. Mai important, instituțiile americane ANSI și IEEE încep elaborarea unor standarde care să formalizeze procesul de testare, efort concretizat în standarde precum ANSI IEEE STD 829, în 1983, care stabilea anumite formate care să fie utilizate pentru crearea documentației de testare.

1988 - în prezent - Orientarea spre prevenire^[6]

Standardele precedente sunt dezvoltate și îmbunătățite începând cu 1987 când IEEE publică o metodologie comprehensivă care se aplică în toate fazele ciclului de viață a programului. Testarea trebuie făcută în toate fazele de lucru, în paralel cu programarea și are următoarele activități principale: planificare, analiză, proiectare, implementare, execuție și întreținere. Respectarea acestei metodologii duce la scăderea costurilor de dezvoltare și de întreținere a unui sistem prin scăderea numărului de defecte care ajung nedetectate în produsul final.

Metodologii moderne

Metodologiile moderne, precum Agile, Scrum, eXtreme Programming și altele pun un accent deosebit pe procesul de testare pe care îl integrează în profunzime cu celelalte activități care țin de dezvoltarea programelor informatice: planificare, proiectare, programare, evaluare și control.

Subiectele testării software

Scopul

Scopul primordial pentru procesul de testare este (1) identificarea erorilor de software, (2) izolarea și fixarea/corectarea defectelor care au cauzat aceste erori. Deseori este un exercițiu non-trivial, deoarece testarea nu poate demonstra cu certitudine de 100% ca produsul funționează corect în orice condiții; testarea doar poate demonstra că produsul nu funcționează corect în anumite condiții.^[7] În scopul testării deseori se include atât examinarea statică a codului sursă, cât și examinarea codului în execuție în diferite împrejurări și sub diferite condiții. Aspectele de cod ce rămân sub ochiul vigilent al test/software inginerului în timpul acestui exercițiu sunt (1) codul face lucrul care este presupus sa-l facă și (2) codul face lucrul care trebuie sa-l facă. Informația obținută în urma procesului de testare poate fi folosită pentru corectarea și îmbunătățirea procesului conform căruia se dezvoltă produsul software.^[8]

Defecte și eșuări

Nu toate defectele software sunt cauzate de greșeli în cod. O sursă răspândită de defecte costisitoare sunt lacunele și neclaritățile la nivel de cerințe, de exemplu, cerințele "ascunse" sau incomplete pot să rezulte într-un set de erori introduse încă în faza de proiectare de către designerul programului.^[9] Cerințele non-funcționale precum ar fi testabilitatea, scalabilitatea, mentenabilitatea, usabilitatea, performanța și securitatea, sunt o sursă raspândită de astfel de erori.

Defectele software se manifestă ca rezultat al următorului proces: un programator comite o eroare (greșeală), care la rândul ei rezultă într-un defect (bug) la nivel de codul sursă al programului; dacă acest defect este executat, în anumite condiții sistemul va produce un rezultat greșit, ceea ce ulterior va duce la o eșuare a programului.^[10] Nu toate defectele pot duce la eșuarea programului. De exemplu, defectele ce se conțin într-o secțiune de cod "mort" niciodată nu vor duce la eșuarea programului. Defectele se pot manifesta ca eșuări la schimbarea împrejurimii în care rulează programul. Exemplele de astfel de modificări includ: trecerea pe o platformă hardware nouă, alterări în sursa de date sau interacțiunea cu software diferit.^[10] Un singur defect poate rezulta într-un spectru larg de simptome prin care se manifestă căderile.

Compatibilitatea

Deseori aplicațiile software cad din cauza problemelor de compatibilititate cauzate atât de interacțiunea lor cu alte aplicații sau sisteme de operare, cât și de non-conformitățile ce apar de la o versiune a programului la alta într-un proces inceremental de dezvoltare a produsului. Incompatibilitățile ce apar între versiuni se datorează faptului că la momentul scrierii codului programatorul a considerat, sau a testat, produsul doar pentru un singur sistem de operare (sau un set restrâns de sisteme de operare), fară a lua în calcul problemele ce pot apărea la schimbarea contextului de execuție. Un rezultat nedorit al acestui fapt poate fi următorul: ultima versiune a programului poate să nu mai fie compatibilă cu acea combinație de software/hardware folosită mai devreme, sau poate să nu mai fie compatibilă cu un alt sistem, compatibilitate extrem de importantă. Deci, testarea de compatibilitate este o "strategie orientată spre prevenire", fapt ce o asociază clar cu ultima din fazele de testare propuse de Dave Gelperin și William C. Hetzel ^[6].

Combinări de date de intrare și precondiții

O problema fundamentală a testării software a fost și rămâne imposibilitatea de a testa un produs utilizând toate combinațiile posibile de date de intrare și precondiții (starea inițială). Aceasta este adevărat chiar și în cazul produselor simple ^[11]^[12].

Referințe

^ Exploratory Testing Arhivat în 26 ianuarie 2009, la Wayback Machine., Cem Kaner, Florida Institute of Technology, Quality Assurance Institute Worldwide Annual Software Testing Conference, Orlando, FL, November 2006
^ Software errors cost U.S. economy $59.5 billion annually Arhivat în 22 ianuarie 2013, la Wayback Machine., NIST report
^ From 1957-1978 there was the demonstration oriented period where debugging and testing was distinguished now - in this period it was shown, that software satisfies the requirements. Gelperin, D. (1988). „The Growth of Software Testing”. CACM. 31 (6). ISSN 0001-0782.
^ The time between 1979-1982 is announced as the destruction oriented period, where the goal was to find errors. Gelperin, D. (1988). „The Growth of Software Testing”. CACM. 31 (6). ISSN 0001-0782.
^ 1983-1987 is classified as the evaluation oriented period: intention here is that during the software lifecycle a product evaluation is provided and measuring quality. Gelperin, D. (1988). „The Growth of Software Testing”. CACM. 31 (6). ISSN 0001-0782.
^ ^a ^b From 1988 on it was seen as prevention oriented period where tests were to demonstrate that software satisfies its specification, to detect faults and to prevent faults. Gelperin, D. (1988). „The Growth of Software Testing”. CACM. 31 (6). ISSN 0001-0782.
^ Kaner, Cem (1999). Testing Computer Software, 2nd Ed. New York, et al: John Wiley and Sons, Inc. pp. 480 pages. ISBN 0-471-35846-0.
^ Kolawa, Adam (2007). Automated Defect Prevention: Best Practices in Software Management. Wiley-IEEE Computer Society Press. p. 41-43. ISBN 0470042125. Mai multe valori specificate pentru |pages= și |page= (ajutor)
^ Kolawa, Adam (2007). Automated Defect Prevention: Best Practices in Software Management. Wiley-IEEE Computer Society Press. p. 86. ISBN 0470042125. Mai multe valori specificate pentru |pages= și |page= (ajutor)
^ ^a ^b Section 1.1.2, Certified Tester Foundation Level Syllabus Arhivat în 17 decembrie 2008, la Wayback Machine., International Software Testing Qualifications Board
^ pp 17–18
^ Principle 2, Section 1.3, Certified Tester Foundation Level Syllabus, International Software Testing Qualifications Board

Vezi și

Testare software automată

Legături externe

The online knowledge bank for Software Test professionals Arhivat în 29 februarie 2008, la Wayback Machine. (în Română)
Software Quality Assurance and Software Testing Arhivat în 25 august 2007, la Wayback Machine. (în Română)
Software-Testing.ro: Testare Software, Metodologii de Testare, Documentatie de Test, Consultanta Quality Assurance Arhivat în 13 februarie 2009, la Wayback Machine. (în Română)
Lista internațională a companiilor de testare software
Curs de Testare Software

[1] Exploratory Testing Arhivat în 26 ianuarie 2009, la Wayback Machine., Cem Kaner, Florida Institute of Technology, Quality Assurance Institute Worldwide Annual Software Testing Conference, Orlando, FL, November 2006

[2] Software errors cost U.S. economy $59.5 billion annually Arhivat în 22 ianuarie 2013, la Wayback Machine., NIST report

[3] From 1957-1978 there was the demonstration oriented period where debugging and testing was distinguished now - in this period it was shown, that software satisfies the requirements. Gelperin, D. (1988). „The Growth of Software Testing”. CACM. 31 (6). ISSN 0001-0782.

[4] The time between 1979-1982 is announced as the destruction oriented period, where the goal was to find errors. Gelperin, D. (1988). „The Growth of Software Testing”. CACM. 31 (6). ISSN 0001-0782.

[5] 1983-1987 is classified as the evaluation oriented period: intention here is that during the software lifecycle a product evaluation is provided and measuring quality. Gelperin, D. (1988). „The Growth of Software Testing”. CACM. 31 (6). ISSN 0001-0782.

[Gelperin_1988-6] From 1988 on it was seen as prevention oriented period where tests were to demonstrate that software satisfies its specification, to detect faults and to prevent faults. Gelperin, D. (1988). „The Growth of Software Testing”. CACM. 31 (6). ISSN 0001-0782.

[Kaner1-7] Kaner, Cem (1999). Testing Computer Software, 2nd Ed. New York, et al: John Wiley and Sons, Inc. pp. 480 pages. ISBN 0-471-35846-0.

[kolawa-8] Kolawa, Adam (2007). Automated Defect Prevention: Best Practices in Software Management. Wiley-IEEE Computer Society Press. p. 41-43. ISBN 0470042125. Mai multe valori specificate pentru |pages= și |page= (ajutor)

[9] Kolawa, Adam (2007). Automated Defect Prevention: Best Practices in Software Management. Wiley-IEEE Computer Society Press. p. 86. ISBN 0470042125. Mai multe valori specificate pentru |pages= și |page= (ajutor)

[ctfl-10] Section 1.1.2, Certified Tester Foundation Level Syllabus Arhivat în 17 decembrie 2008, la Wayback Machine., International Software Testing Qualifications Board

[autogenerat1-11] 17–18

[12] Principle 2, Section 1.3, Certified Tester Foundation Level Syllabus, International Software Testing Qualifications Board

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]