importana asigurrii calitii

produsului program
Unitatea de nvare:
Planificarea procedurilor de
testare
Pdure Gheorghe

Obiective:
Demonstrarea necesitii procesului de testare;
Descrierea terminologiei din domeniul testrii
produselor program;
Organizarea procesului de testare;
Recunoaterea procedurilor de testare n diverse
modele ale ciclului de via a produsului program.

Termeni cheie:
Produs program;
Ciclu de via;
Testare;
Tester;
Eroare;
Defect;
Bug;

Aspecte ale testrii software:

Impactul erorilor software asupra vieii noastre;
Ce prezint erorile software i care este cauza apariiei lor;
Cine sunt testerii i care este rolul lor n procesul de elaborare a softului.
Pentru a asigura calitatea i sigurana aplicaiilor software se pune un accent
deosebit pe testarea acestor din urm. Testarea de software a devenit o profesie
tehnic foarte important. Urmtoare exemple pot ilustra foarte bine necesitatea
testrii software:
Dezvoltarea aplicaiilor software implic o serie de activiti, n care posibilitatea
erorii umane este foarte ridicat. Testarea este un element cheie n procesul de
dezvoltare, i reprezint o ultim recapitulare a specificaiilor, design-ului i
codului.
Testarea software, prin definiie, urmrete focalizarea pe procesul de identificare
a posibilelor erori de program, erori care ar putea avea un impact negativ asupra
produsului, i prin urmare asupra clienilor. Satisfacia clienilor este cheia reuitei
oricrei afaceri, i asta nu mai este o necunoscut.

 Aceasta presupune c produsul oferit s fie de calitate ridicat, i s

nu produc erori n timpul utilizrii de ctre client. Calitatea ridicat nu
poate fi obinut doar cu ajutorul unei echipe de programatori de
excepie. Este deja bine tiut faptul c orict de bine pus la punct ar fi
produsul dezvoltat, acesta conine totui erori.
Implicarea testrii n procesul de producie aduce urmtoarele
avantaje:
Organizare disciplinat a procesului de dezvoltare i testare matur a
procesului de producie.
Responsabilii i Managerii de proiect induc o linie bine trasat n scopul
urmririi exacte a procesului de producie.
nelegerea importanei calitii n procesul de producie, calitate care
poate fi obinut doar n urma unei testri profesionale.
Impunerea unor reguli i standarte care n timp vor duce la livrarea
unor produse de cea mai nalt calitate, i a unor soluii de cea mai
nalt calitate pentru clienii

Definiia erorii software

1. Aparat medical pentru terapie cu radiaie Therac-25
- 6 accidente cu mori i rni grave (1985-8
7, SUA, Canada)
Cauza direct: erori in programul de control
Analiz retrospectiv [Leveson 1995]:
ncredere excesiv n software (n analiza produsului)
fiabilitate siguran
2. Racheta Ariane 5
- Autodistrugere dup o defeciune la 40 s de la lansare (1996)
Cauza: conversia 64-bit float 16-bit int genereaz o excepie de depire netratat n
programul ADA
Cost: 500 milioane dolari (racheta), 7 miliarde dolari (proiectul)
Analiz retrospectiv
principala cauz: reutilizarea nejudicioasa de software
cod preluat de la Ariane 4, fr reanalizare corespunztoare:

3. Eroarea din procesorul Intel Pentium

Eroare n unitatea de mprire cu virgula mobila, 1994
Cost: cca. 400 milioane dolari
Analiz ulterioar
Circuitul putea fi verificat formal
- demonstrare automat de teoreme [Clarke, German & Zhao]
- cu structuri speciale de date pentru reprezentarea
nmulirii/mpririi [Bryant & Chen]
Accentul a fost pus pe componente mai complexe (unitatea de
execuie, coerena memoriei cache)

Eroarea software
Din exemplele de mai sus se poate vedea impactul
erorilor software asupra noastr. Erorile pot fi
catastrofice, cnd provoac pierderi de viei omeneti
sau pot fi nite inconveniene dac este vorba de
exemplu de un joc pe calculator. Majoritatea erorilor sunt
mult mai complicate dect par la prima vedere. Sunt ns
i erori simple, subtile despre care nu se poate cu
siguran de spus, dac este o eroare adevrat sau nu.

Un testor bun trebuie s poat folosi diferii

termeni pentru a descrie ce s-a ntmplat cnd a
euat softul. n continuare este dat o list cu
termenii folosii:
Defect (Defect)
Excepie (Variance)
Eec (Failure)
Problem (Problem)
Eroare (Error)
Incident (Incident)
Anomalie (Anomaly)
Inconsisten (Inconsistency)
Aparen (Feature)
Neajuns (Fault)
Bug

 Care dintre aceti termeni vor fi folosii pentru descrierea erorilor ine
doar de cultura companiei i de stadiul la care a fost descoperit
eroarea. Dac ne uitm n dicionar, observm c toate aceste cuvinte
se deosebesc foarte puin, unele fiind chiar sinonime.
De obicei orice eroare software este numit bug, ns acest termen nu
poate fi acceptat cnd se completeaz diferite rapoarte despre testarea
softului. n cadrul acestui curs vom folosi termenul: eroare software.
nainte de a formula definiia erorii software avem nevoie de un termen
de reper: specificaia produsului software.
Specificaia produsului este un acord al echipei de dezvoltare software,
n care este definit: cum ar trebui el s fie, cum este ntr-adevr, ce
trebuie s fac i ce nu trebuie s fac acest produs.

Definiie. Erorile software apar cnd una sau

mai multe dintre urmtoarele afirmaii sunt
adevrate:
Softul nu execut ceva ce specificaiile spun c trebuie s execute.
Softul execut ceva ce specificaiile spun c nu trebuie s execute.
Softul execut ceva ce n specificaii nu este menionat.
Softul nu execut ceva ce specificaiile nu menioneaz dar ar
trebui s menioneze.
Softul este greu de neles, greu de folosit, lent sau se vede c nu a
fost proiectat corect.
Aceast definiie a erorilor acoper o mare parte de probleme, de
acea testorii folosesc aceste reguli pentru a identifica diferite tipuri
de probleme n aplicaiile software

Cauzele apariiei erorilor.

Poate fi surprinztor, dar cel mai mic procent de erori sunt cele
provenite de programare. Cele mai multe erori sunt cauzate de deficienele
din specificaie ( 60%), uneori specificaia pur i simplu nu este scris.
Alte motive specificaia nu este descris n detaliu, a fost modificat
constant i nu a fost adus la cunotina ntregii echipe de dezvoltare. Alt
surs de erori este etapa de proiectare ( 30%), cauzele apariiei erorilor
aici sunt similare cu cele din specificaii ( modificri, comunicarea rea etc.).
Relativ puine (uneori sub 15%) sunt erorile directe de programare. Ele pot
aprea din cauza complexitii softului, a documentaiei insuficiente (n
special n codul care a fost modificat), a timpului insuficient planificat
pentru programare sau a erorilor de proiectare. Uneori programatorii nu
neleg corect cerinele, sau cerinele nu sunt formulate bine.

Costul erorilor.
Erorile depistate i fixate in faza de scriere a
specificaiilor nu cost practic nimic, cele care nu au
fost depistate nainte de faza implementrii i
testrii pot ajunge la sute de dolari. Dac ns
clientul a gsit defecte dup livrarea i lansarea
produsului, costul erorilor poate crete de la mii la
milioane de dolari. Deci costul erorilor poate crete
exponenial avansnd n procesul de producie de la
specificare pn dup livrare.

Rolul i scopurile testerului n

procesul de dezvoltare software
Definiia 1. Scopul testorului este de a depista erorile softului.
Se poate rula programul i confirma c el funcioneaz, fr a pune accentul pe detectarea
erorilor. Dac se testeaz doar componentele funcionale, pot fi omise multe erori. n cazul n
care nu au fost depistate erorile la timp clientul risc s piard muli bani. Deci testorul nu
trebuie s se concentreze doar pe detectarea erorilor, el trebuie s se gndeasc cum s
fac acest lucru ct mai curnd posibil.
De aici avem:
Definiia 2. Scopul testorului este de a depista erorile softului ct mai devreme posibil.
Dar nici aceasta nu este suficient. Testorul este ochiul clientului, primul care ncearc
produsul i el dorete calitate.
Deci:
Definiia 3. Scopul testorului este de a depista erorile softului ct mai devreme posibil i se
asigur c ele au fost fixate i luate msuri n legtur cu aceasta.
Aceast definiie final este foarte important. La fel este important faptul c fixarea
defectelor nu implic neaprat corectarea softului. n legtur cu aceasta poate fi adugat
un comentariu n manualul utilizatorului sau poate fi fcut un seminar special cu utilizatorii.

Calitile unui testor bun

Cum am menionat mai sus testarea software este o profesie tehnic. Testorii trebuie implicai
n procesul de dezvoltare software nc din fazele incipiente, pentru a asigura calitatea bun a
produsului soft. Pentru a fi angajat i preuit un testor trebuie s posede urmtoarele caliti:
Trebuie s fie un explorator. Testorul software este cel care experimenteaz cu soft-uri noi
ncercndu-le funcionalitile.
Trebuie s fie nenduplecai. Testorul software este mereu n cutare. El caut erori prin toate
cile posibile.
Trebuie s fie creativ. Testarea superficial nu este suficient pentru testor. El trebuie s
gndeasc creativ i s intuiasc unde poate gsi erori.
Trebuie s fie perfecionist. Testorii tind spre perfeciune, cu toate c neleg c n industria
software ea este de neatins.
Trebuie s posede o bun judecat. Ei trebuie s decid ce trebuie de testat, ct timp i dac o
oarecare problem este ntr-adevr o eroare sau nu.
Trebuie s aib tact i s fie bun diplomat. El este cel care aduce vetile rele programatorului.
Trebuie s fie perseverent. Erorile gsite nu totdeauna sunt vizibile i uneori sunt greu de
descris. Testorul trebuie s-i poat expune punctul de vedere i s poat demonstra
necesitatea fixrii i posibil corectrii erorilor gsite.

Termeni i definiii ale testrii

Testarea software este o disciplin tehnic, ns ea implic importante
consideraii economice i psihologice.
Ideal ar fi testarea tuturor combinaiilor posibile ale intrrilor i ieirilor
programului. n cele mai multe cazuri ns aceasta este imposibil, deoarece
chiar i un program simplu poate avea sute i chiar mii de combinaii ale
intrrilor i ieirilor. Crearea cazurilor de test pentru toate aceste combinaii
este destul de nepractic, pentru aceasta este nevoie de resurse umane i
financiare enorme, mai mult ca att procesul poate dura timp ndelungat.
Plus la aceasta mai trebuie de luat n consideraie i viziunea testorului fa
de crearea unui test de succes. Atitudinea testorului fa de produs este de
asemenea foarte important. Pentru ca procesul de testare s nu se
transforme ntr-o goan haotic dup erori este benefic de respectat unele
principii ale testrii pe care le-a artat practica testrii i timpul i de
cunoscut nite tehnici de testare, pentru a sistematiza acest proces.

Psihologia testrii
Testarea software este o disciplin tehnic, ns ea implic importante
consideraii economice i psihologice.
Ideal ar fi testarea tuturor combinaiilor posibile ale intrrilor i ieirilor
programului. n cele mai multe cazuri ns aceasta este imposibil,
deoarece chiar i un program simplu poate avea sute i chiar mii de
combinaii ale intrrilor i ieirilor. Crearea cazurilor de test pentru toate
aceste combinaii este destul de nepractic, pentru aceasta este nevoie
de resurse umane i financiare enorme, mai mult ca att procesul poate
dura timp ndelungat. Plus la aceasta mai trebuie de luat n consideraie
i viziunea testorului fa de crearea unui test de succes. Atitudinea
testorului fa de produs este de asemenea foarte important. Pentru
ca procesul de testare s nu se transforme ntr-o goan haotic dup
erori este benefic de respectat unele principii ale testrii pe care le-a
artat practica testrii i timpul i de cunoscut nite tehnici de testare,
pentru a sistematiza acest proces.

Definiii ale testrii

O cauz important a calitii proaste a produselor soft este definirea incorect a
procesului de testare. De exemplu se spune c:
1. Testarea e procesul de a demonstra c programul nu are erori (or acest lucru este
imposibil folosind doar testarea) sau
2. Scopul testrii este de a arta c produsul este performant i funcioneaz corectsau
3. Testarea este procesul prin care se demonstreaz c produsul face ceea ce trebuie
s fac
Aceste definiii nu sunt rele doar c sunt cam pe dos. Este cunoscut c aciunea de
testare a unui program se deosebete de celelalte faze prin care acesta trece
(specificare, proiectare, programare) prin caracterul su n aparen "demolator". ntradevr, n timp ce alte faze au o esen constructiv, testarea are n aparen un
caracter mai degrab distructiv, deoarece scopul acestei aciuni este de a pune n
eviden proasta funcionare a produsului obinut. Din punct de vedere psihologic
programatorul trebuie s adopte n aceasta etap o atitudine "dumnoas" fa de
creaia sa i s-i expun defectele.

 Esena procesului este fr ndoial tot constructiv,

scopul su fiind de a pune n operare real un produs la
parametrii prevzui.
Deci cele mai adecvate definiii ale testrii ar fi:
1. Testarea e procesul prin care se execut un program
cu intenia de a gsi erori (Myers) sau mai mult ca
att:
2. Testarea este utilizata pentru a semnala prezena
defectelor unui program, fr a garanta absena
lor( Dijkstra).
3. Un test de succes (test concludent) e acela care
descoper (i localizeaz) o eroare.

Principii ale testrii (Myers)

Continund ideea acestei teme observm c cea mai important problem n testare este cea
psihologic. Reieind din aceasta pot fi formulate nite principii ale testrii.
Principiul 1: Un caz de test trebuie sa defineasc neaprat ieirea sau rezultatul dorit.
Formularea acestui principiu este bazat pe psihologia uman. Dac rezultatul corect nu este predefinit ,
ansa c orice rezultat va fi interpretat ca corect este destul de mare. Avem aici fenomenul Vedem ceea
ce dorim s vedem. Cu alte cuvinte noi subcontient ateptm rezultatul corect. O cale de combatere a
acestui fenomen este ncurajarea examinrii detaliate a tuturor ieirilor. Conform acestui principiu un
caz de test trebuie s fie compus din:
Descrierea instanei unui program.
Descrierea precis a rezultatului sau a ieirii programului pentru aceast instan.
Principiul 2: Un programator ar trebui s evite i s testeze propriul program.
Orice scriitor cunoate, sau cel puin trebuie s cunoasc, c este o idee nu prea bun s-i corecteze i
s-i redacteze singur manuscrisele. Iari este vorba de un fenomen psihologic. Autorul nu dorete s
descopere erori n propria lucrare. Dup ce programatorul a lucrat constructiv la designul i scrierea
programului este foarte dificil s ia o atitudine distructiv fa de propria oper. Plus la aceasta
programatorul subcontient nu dorete s gseasc erori de teama criticii din partea clientului sau
beneficiarului. n afar de aceast problem psihologic mai este una important: Programul poate avea
erori din cauza nenelegerii de ctre programator a sarcinii puse sau a specificaiei produsului. Astfel
programatorul va transmite aceleai nenelegeri i testelor executate. Aceasta nu nseamn c
programatorul nu trebuie sub nici o form s-i testeze propriul program, ns testarea de ctre o alt
persoan va fi mai eficient. Acest principiu nu poate fi aplicat i depanrii. Acest proces este mai bine
efectuat de ctre programatorul care a codificat programul.

 Principiul 3: Companiile de programare nu ar trebui s-i testeze produsele

proprii.
Argumentele acestui principiu sunt similare cu cele de la principiul precedent.
Aici pot avea loc probleme de planificare: produsul trebuie livrat la timp, orice
ntrziere cost bani. Este destul de dificil ca o companie s fie obiectiv fa
de calitatea propriului produs. Grupul de testori ar trebui s fie altul dect cel
de dezvoltare, iar ntreinerea unui departament de testare este destul de
costisitoare i nu orice companie poate s-i permit aceasta.
Principiul 4: Fiecare rezultat al testului trebuie examinat foarte minuios.
Acesta este probabil cel mai evident principiu. Ct de minuios nu ar fi fcut
testarea este posibil s se strecoare diferite erori. Erorile depistate ntr-un
stagiu tardiv de testare deseori se dovedesc a fi cele omise n stadii incipiente
de testare.
Principiul 5: Cazurile de test trebuie s fie scrise att pentru condiii de
intrare valide ct i pentru cele invalide i neateptate.
Este normal tendina de testare a produsul pentru date valide de intrare,
neglijnd datele incorecte. Este ns forte important comportamentul
produsului cnd sunt introduse date incorecte sau ilegale. Acest principiu nu
poate fi neglijat atunci cnd sunt elaborate cazurile de test.

 Principiul 6: Trebuie testat c produsul face ce trebuie i nu face ce nu trebuie.

Putem considera acest principiu ca un corolar al principiului precedent.
Programele trebuie supuse i examinate pentru efecte neateptate. Mai ales
astfel de teste trebuie elaborate pentru produsele cu destinaie financiar.
Principiul 7: Trebuie de pstrat i refolosit cazurile de test.
Acest principiu este important i este respectat de specialitii n testare. Orice
produs poate fi mbuntit i dac dorim s vedem dac schimbrile nu au avut
un efect negativ asupra altor componente ale sistemului atunci este bine de a
testa cu testele vechi noul produs. Astfel se testeaz integritatea i
funcionalitatea produsului. Refolosirea cazurilor de test este binevenit i
atunci cnd au fost corectate unele erori deja gsite. Pstrarea testelor i
refolosirea lor dup modificri n produs poart denumirea de testare regresiv
(regression testing).
Principiul 8: Nu se planific procesul de testare presupunnd c nu vor fi
gsite erori.
Este o greeal a managerilor de proiect cnd se folosete o definiie incorect a
testrii. De exemplu: Testarea e procesul prin care se demonstreaz c
produsul este performant i funcioneaz corect n locul Testarea e procesul
prin care se execut un program cu intenia de a gsi erori

 Principiul 9: Probabilitatea de a gsi erori ntr-un fragment de cod

este proporional cu numrul de erori deja gsite.
Dac avem de exemplu un program din dou module A i B i n
modulul A au fost gsite cinci erori iar n B numai una, i dac modulul
A nu a fost supus intenionat unui test riguros, atunci acest principiu
ne spune c probabilitatea c n modulul A vor fi gsite mai multe erori
dect n modulul B este destul de mare. La prima vedere acest
principiu nu are prea mult sens, ns este un fenomen prezent n
majoritatea programelor.
Principiul 10:Testarea este un lucru extrem de creativ i intelectual.
Este probabil adevrat c creativitatea cerut la testarea produselor
serioase depete creativitatea cerut n proiectarea acestora. Este
clar c este imposibil de testat un produs suficient pentru a demonstra
absena erorilor n acest produs. Metodologia pe care o vom studia n
cadrul cursului va fi de un mare folos la elaborarea unui numr
rezonabil de cazuri de test, ns aceast metodologie cere un nivel
nalt de creativitate a testorului.

Axiomele testrii.
1. Este imposibil testarea complet a unui program.
Aceast axiom este adevrat din urmtoarele motive:
Numrul intrrilor posibile este foarte mare.
Numrul rezultatelor posibile este foarte mare.
Numrul drumurilor ntr-un program este foarte mare.
Specificaiile programului sunt subiective.
Exemplul calculatorului

 2. Testarea software este un exerciiu de apreciere a riscurilor.

Dac ai luat decizia s nu testezi toate scenariile de test
posibile, atunci i-ai asumat un oarecare risc. De exemplu,
dac ai decis s nu testezi n calculator cazul
1024+1024=2048, iar programatorul accidental a greit
aceast combinaie, nimerind acest produs la consumator,
care este un contabil i a gsit aceast eroare, ce se va
ntmpla n aa caz? Aceast eroare va costa foarte mult. Sun
destul de urt aceasta, dar pe de alt parte este imposibil de
testat tot, dar dac nu se testeaz totul este posibil s se
strecoare diferite erori. Ce se poate de fcut n astfel de
cazuri? Un element important este c testorul trebuie s nvee
cum se poate reduce domeniul imens a datelor de intrare pn
la nite seturi realizabile de teste i cum s ia decizii ce este
important de testat i ce nu este.

 3. Testarea nu poate arta c produsul nu are erori.

Testarea poate arta c erorile exist ntr-un produs, dar nu poate arta c ele
nu sunt n el. Pot fi perfecionate testele, pot fi gsite i raportate erorile, dar nu
este posibil de garantat c erori n produs nu se vor mai gsi. Unicul lucru care
se poate de fcut este de a continua testarea i posibil se vor mai gsi erori.
4. Cu ct mai multe erori gseti, cu att mai multe sunt.
Erorile au tendina de a se gsi n grupuri. Dac ai gsit una, poi fi sigur c n
vecintatea ei vor mai fi i altele. Deseori, trece destul de mult timp pn cnd
testerul gsete o eroare. ns dac a fost gsit una el o va gsi i pe a doua i
pe a treia etc. Exist motive serioase pentru aceasta:
Programatorul a avut o zi grea. Codul scris ntr-o zi poate fi perfect, iar unul scris
n alt zi poate avea o sumedenie de erori. O eroare gsit ne poate spune c
mai sunt i altele prin zon.
Programatorii foarte des fac aceleai erori. Un programator care a fcut aceiai
greeal de mai multe ori o va repeta iar i iar.
Fiecare eroare este ca un aisberg. Deseori proiectul i arhitectura software au
probleme serioase. Testerul ar trebui s le depisteze pe acestea n primul rnd,
dar de obicei ele sunt detectate dup ce au provocat multe probleme serioase.

 5. Paradoxul pesticidelor: erorile devin rezistente la teste

Paradoxul pesticidelor n testare descrie fenomenul: cu ct mai mult testezi cu
att mai imun fa de teste devine softul. Analogic cu insectele i pesticidele: dac
sunt aplicate aceleai pesticide de fiecare dat insectele devin imune la ele i
chiar mai puternice dect au fost. Pentru a gsi erori noi e nevoie de teste noi.
6. Nu toate erorile gsite vor fi corectate.
O realitate trist atestrii este, c dup ce s-a lucrat destul de mult i greu pentru
a depista erorile, nu toate din ele sunt fixate i corectate. efii echipelor de testare
trebuie s fac compromisuri i s ia decizii bazate pe riscuri n ceea ce privete
fixarea anumitor erori.
Acest lucru are motive serioase:
Nu este suficient timp pentru aceasta.
ntr-adevr nu este o eroare.
Este prea riscant de fixat( fixarea ei poate provoca mai multe erori).
Nu are nici o valoare.
Procesul de luare a deciziilor fa de fixarea erorilor i implic pe testori, managerii
de proiect i pe programatori i fiecare are opinia lui fa de eroarea respectiv
ns nimeni nu tie cine are dreptate, aa c decizia luat este bazat pe anumite
riscuri (exemplu Procesorul Intel Pentium)

 7. E greu de spus cnd o eroare e o eroare ...

n afar de acele afirmaii care alctuiesc definiia erorii testorii pot apela i la
opinia altor persoane poate chiar a clientului, ce reprezint pentru el o eroare
i i poate formula propria definiie a erorii.
8. Specificaiile produselor nu sunt niciodat definitive.
Industria software se dezvolt foarte rapid. n acelai timp produsele soft
devin tot mai complexe, iar termenii de predare mai scurte din cauza
concurenei. Aceste dou aspecte sunt n conflict permanent i rezultatul
conflictului este schimbarea constant a specificaiilor. Un alt motiv este
perfecionarea unui produs care a fost scos pe pia cu ceva timp n urm
specificaiile au fost rescrise, dar nu conin i funcionalitile vechi ale
produsului.
9. Testorii nu sunt cei mai populari membri ai echipei de proiect.
Ne amintim de scopul unui testor. Cteva sfaturi utile pentru testori:
Gsii erorile ct mai devreme. Toi vor fi mulumii dac o s gsii erorile
serioase cu dou luni, dar nu cu o zi nainte de sfritul perioadei de testare.
Temperai-v entuziasmul. Ct de bucuros nu ai fi c ai gsit o eroare critic,
fii diplomat cnd i-o spui programatorului.