Descrierea efectiv i eficient a defectelor

1. Introducere
Rapoartele defectelor sunt printre cele mai importante rezultate obinute din teste. Ele sunt la fel de importante ca i planul de test i au un impact mai mare asupra calitii produsului dect celelalte rezultate ale testrii. Merit efortul de a nva cum se scriu rapoarte efective ale defectelor. Rapoartele efective ale rapoartelor vor: Reduce numrul defectelor ntoarse de la faza de dezvoltare; mbunti viteza corectrii erorilor; Mri credibilitatea testului; mbunti legtura dintre testare i dezvoltare; De ce unii testeri obin un rspuns mult mai bun de la dezvoltatori dect alii? O parte din rspunsul la aceast ntrebare o reprezint raportul defectelor. Urmnd cteva reguli simple putem s deschidem calea spre un mediu mult mai productiv. Obiectivul nu este s scriem un raport al defectelor perfect, dar unul efectiv, care red un mesaj corect, face lucrul plcut i uureaz procesul pentru fiecare. Accentul trbuie pus pe dou aspecte ale raportului defectelor: 1) Descriere 2) Sumarul Mai nti, s aruncm o privire la punctele eseniale pentru scrierea unor remarci efective.

2. Descrierea defectelor
Iat cteva puncte-cheie pentru a fi siguri c raportul defectelor scris va fi unul efectiv. 1. Consisten Spune clar, dar pe scurt. 2. Acuratee Este acesta un defect sau o greeal a utilizatorului, nenelegere, etc? 3. Neutralitate Doar fapte. Fr nfrumuseri. Fr umor. Fr emoii. 4. Precizie Concret, care este problema? 5. Izolare Ce a fost fcut pentru a izola problema? 6. Generalizare Ce a fost fcut pentru a nelege ct de general este problema? 7. Reproducere Cum poate fi reprodus problema (paii concrei)? 8. Impact Care este impactul asupra clientului? Care este impactul pentru testare? 9. Depanare De ce este nevoie pentru a uura depanarea? (urmrire, descrcare, log-uri, acces imediat, etc.) 10. Eviden Ce documentaie demonstreaz existena erorii? Nu doar capacitile tehnice bune de scriere duc la rapoarte efective ale defectelor. Este mai important s te asiguri c ai pus ntrebrile corecte i ai rspuns corect la ntrebri.Aceasta este cheia care asigur c au fost acoperite punctele eseniale care vor aduce un beneficiu maxim. 2.1. Descrierea efectiv a defectelor 2.1.1 Consisten Spune clar, dar pe scurt. Mai nti de toate, elimin excesul de cuvinte. n al doilea rnd, nu aduga informaie redundant. Este important s fie inclus toat informaia relevant, dar asigurai-v c informaia este relevant. n situaii cnd nu este clar cum de reprodus problema sau nelegerea problemei este vag din oarecare cauz posibil vei avea nevoie s captai mai mult informaie. inei minte c informaia irelevant poate fi la fel de problematic ca i informaia relevant insuficient. De exemplu, trebuie s descriei aceast problem: Sumar: Tab-ul [Trades] nu arat timpul cnd se intr n poziii. 1

Descriere detaliat: Ghidul utilizatorului afirm c tab-ul [Trades] n Account Manager trebuie s arate cnd s-a intrat n poziii. n schimb, acesta arat timpul doar cnd s-a ieit din poziii. Cum se reproduce: 1) Deschidei orice poziie 2) Ducei-v la coloana Account Manager>> Trades tab>>Time. Aceasta este pustie.

Nu scriei n pai pentru a reproduce urmtoarele:

1) n box-a Stock introducei toate cmpurile necesare cu valori valide (alegei comanda Market i plasai comanda Buy). 2) Dup completarea comenzii (deschiznd poziia lung) trecei la fereastra Account Manager, tab-ul [Trades] o nuo nregistrare este creat i cmpul [Time] este vid (privii screenshot-ul ataat). 2.1.2 Acuratee Asigurai-v c ceea ce raportai este ntr-adevr o eroare. Putei s pierdei din credibilitate foarte rapid dac obinei o reputaie de raportare e problemelor care se adeveresc a fi probleme de configurare, greeli ale utilizatorilor sau inconsistene ale produsului. nainte de a descrie problema, asigurai-v c ai ndeplinit sarcina de baz. nainte de a descrie problema luai n considerare: Este ceva n setri ce ar putea cauza aceasta? De exemplu, sunt instalate versiunile corecte i se respect toate dependenele? Ai realiazt corect logarea, securitatea, secvena de comenzi .a.m.d.? S-ar putea ca curarea incomplet, rezultate incomplete sau intervenii de la testarea precedent s cauzeze aceasta? S-ar putea s fie rezultatul unei probleme de reea sau de mediu? ntr-adevr nelegei cum aceasta ar trebui s lucreze? ntotdeauna sunt influene numeroase ce pot afecta rezultatul testului. Asigurai-v c nelegei ce sunt aceste influene i considerai rolul lor n eroarea perceput pe care o raportai. Este un domeniu care repede separ un tester experimentat de unul fraged. Dac nu suntei sigur despre validitatea problemei ar fi nelept s v consultai cu un tester experimentat sau un dezvoltator nainte de a descrie problema. n esen, dac avei dubii, ntrebai. Dac nu ntrebai nimeni nu va ti ca nu cunoatei. Fii proactivi n autoeducare. De regul ajut zicala: este un pcat s supra-raportezi, dar este o crim s sub-raportezi. Nu v fie fric s scriei problemele. Depunei maxim efort s v asigurai c acestea sunt probleme valide. Cnd ai descoperit c ai depistat o problem ce a fost raportat incorect, nvai din aceasta. 2.1.3 Neutralitate Prezentai problema obiectiv. Nu ncercai s utilizai umor sau emoii. Ceea ce credei c e amuzant cnd descriei defectul poate s nu fie interpretat la fel de ctre dezvoltator care lucreaz supratimp i este stresat de linii pe care trebuie s le scrie n plus. Utiliznd fraze ncrcate cu emoii nu ajut cu nimic la rezolvarea problemei. Frazele emoionale doar creeaz bariere de comunicare i pericliteaz lucrul n echip. Chiar dac dezvoltatorii au dubii i v-au returnat defectul precedent, dar suntei convins c avei dreptate, iar ei au greit, doar prezentai problema i informaia adiional ce va fi de folos dezvoltatorilor. Cu timpul aceasta v va aduga profesionalism, respect i credibilitate. Citii descrierea problemei nc o dat nainte de a o trimite i eliminai sau revizuii acele comentarii ce pot fi interpretate ca negative de ctre destinatar. Exemplu de neutralitate: Acest exemplu este un rspuns unui dezvoltator returnnd un defect pentru mai mult informaie i necesitnd mai multe detalii despre valorile ce au cauzat problema. Remarca defectului: 2

Nu scriei: Prima clauz va fi probabil interpretat ca o mpunstur pentru developer i nu adaug informaie de folos: Cum putea fi determinat din eroarea original cu efort foarte mic, funcia ABC ntr-adevr eueaz cu orice valori negative la intrare. Scriei: Funcia ABC eueaz cu orice valori negative. Exemple cu cteva valori testate: -1, -36, -32767. 2.1.4 Precizie Persoana care citete descrierea problemei nu trebuie s fie un detectiv pentru a determina care este problema. Sus n dreapta descrierii, descriei exact problema perceput. Unele descrieri detaliaz o serie de aciuni i rezultate. Exemplu: Am apsat tasta Enter i a avut loc aciunea A. Apoi am apsat tasta sgeata napoi i a avut loc aciunea B. Apoi am tastat comanda xyz i a avut loc aciunea C. Cititorul poate s nu tie dac credei c toate trei aciuni rezultante au fost incorecte, sau care din ele, dac vre-una este incorect. n toate cazurile, dar mai ales dac descrierea este lung, trebuie s facei un sumar al problemelor la nceputul descrierii. Nu depinde dac este prezent un abstract ntr-un cmp diferit a raportului defectului sau dac este utilizat de ctre fiecare persoan, care citete descrierea problemei. S nu credei c alii vor face aceleai concluzii pe care le-ai fcut. Scopul vostru nu este s facei o descriere ce poate fi neleas, ci o descriere care nu poate fi neneleas (neleas greit). Unica cale s facei aceasta este s descriei explicit i precis problema n loc s descriei doar ce s-a ntmplat. Exemplu precis de remarc a defectului: Nu scriei: n acest exemplu, este greu de spus dac problema este 1) portul Twinax not timing out sau 2) printer nu returneaz ready sau 3) mesajul pe panelul de operare Lansarea unei anulri de printare cnd job-ul se afl n starea PRT (job-ul deja este n printer i AS/400 ateapt s primeasc printare completat de la printer) cauzeaz port-ul Twinax s nu fie n timeout. Printer-ul niciodat nu returneaz starea READY i nedefinit afieaz PRINTING IPDS FROM TRAY1 pe panelul de operare. Scriei: Precedai descrierea cu un sumar scurt care percepei a fi problema: Anularea unui job n timpul printrii face printer-ul s se blocheze. Lansarea unei anulri de printare cnd job-ul se afl n starea PRT (job-ul deja este n printer i AS/400 ateapt s primeasc printare completat de la printer) cauzeaz port-ul Twinax s nu se afle n timeout. Printer-ul niciodat nu returneaz starea READY i nedefinit afieaz PRINTING IPDS FROM TRAY1 pe panelul de operare. 2.1.5 Izolare Fiecare organizaie are propria filozofie i ateptri pe ct de mult tester-ul trebuie s izoleze problema. Dei se nainteaz anumite cerine, tester-ul trebuie s investeasc o cantitate rezonabil de efort pentru izolarea problemei. Considerai urmtoarele cnd izolai problemle. 3

ncercai s gsii cel mai scurt, simplu set de trepte necesare pentru reproducerea problemei. Aceasta de obicei necesit o cale lun spre izolarea problemei. ntrebai-v dac ceva din exteriorul codului specific care e testat a contribuit la apariia problemei. Spre exemplu, dac ai avut o blocare sau o pauz, ar putea s fie din cauza unei probleme de reea? Sunt careva lucruri ce le-ai putea face pentru a ajuta ngustarea spectrului componentelor ce au produs eroarea? Dac testul are condiii multiple la intrare, variai valorile de intrare pn o putei gsi pe cea care cauzeaz problema.

Abilitatea de a izola problemele, n mare parte, definete valoarea voastr ca tester. Izolarea efectiv salveaz pe fiecare implicat de mult timp pierdut. La fel aceasta v salveaz mult timp cnd trebuie s verificai o eroare corectat. 2.1.6 Generalizare Deseori, dezvoltatorii vor corecta exact ce ai raportat, fr chiar s neleag c problema este una mai general care necesit o atenie mai mare. Spre exemplu, putem raporta c funcia procesorului de texte salvare fiier a euat i procesorul de texte s-a blocat cnd am ncercat s salvm fiierul myfile. O investigare mai profund poate scoate n eviden c aceai euare are loc cnd salvm un fiier de lungime nul. Posibil n aceast versiune acesta se blocheaz la fiecare salvare pe un disk ndeprtat, un disk doar citibil .a.m.d. Dac cunoatei deja aceasta cnd scriei raportul, vei salva mult timp pentru dezvoltator i vei facilita posibilitatea corectrii mai bune pentru prelucrarea cazului general. Cnd detectai o problem, parcurgei paii rezonabili pentru determinarea dac ea este mai general dect cazul evident. Exemplu de Generalizare: Nu scriei: Mesajul de eroare pentru eroarea fiierul nu a fost gsit are caractere inadmisibile pentru numele fiierului. Scriei: Mesajul de eroare pentru eroarea fiierul nu a fost gsit are caractere inadmisibile pentru numele fiierului. Fiecare mesaj ncercat care atepta date pentru a fi inserate n mesaj aveau aceeiai problem. Mesajele fr inserri erau valide. 2.1.7 Re-creare Unele erori sunt uor de re-creat, iar unele nu. Dac putei re-crea eroarea trebuie s explicai exact ce trebuie fcut pentru re-creare. Trebuie s listai toi paii, inclusiv sintaxa exact, numele fiierelor, secvene ce au fost utilizate pentru a produce sau re-crea problema. Dac credei c problema va avea loc cu orice fiier, orice secven, etc. menionai aceasta, dar totui oferii un exemplu explicit ce poate fi utilizat pentru re-creare. Dac n efortul vostru de a verifica dac eroarea este re-creabil gsii o cale mai scurt i sigur, documentai cea mai scurt, uoar cale de re-creare. Dac nu putei re-crea problema sau dac credei c nu putei re-crea problema, adunai toat informaia relevant care putei, care ar putea oferi informaie util persoanei care trebuie s ncerce i s elimin problema. Nu considerai c aceasta poate fi re-creat dac nu ai verificat acest fapt. Dac nu putei sau nu ai realizat re-crearea problemei, este important s menionai aceasta n remarca defectului. 2.1.8 Impact Care este impactul dac eroarea iese la suprafa n mediul clientului? Impactul unor erori este evident. Spre exemplu, ntregul sistem cade cnd aps tasta Enter. 4

Unele erori nu sunt att de evidente. Spre exemplu, putei descoperi un typo pe fereastra. Aceasta poate prea foarte minor, chiar trivial dac nu artai c de fiecare dat cnd cineva utilizeaz produsul acesta este primul lucru pe care l vd i typo rezult ntr-un cuvnt inofensiv. n acest caz, chiar dac este doar un typo, aceasta poate fi ceva ce trebuie fixat neaprat nainte de a livra produsul. Judecai bine. Dac credei c este posibil ca acest defect s nu aib prioritate suficient, atunci specificai impactul potenial i reclamai defectul. Nu supra-reclamai, dar asigurai-v c cititorii defectului au neles clar impactul probabil asupra clientului. 2.1.9 Depanare De ce va avea nevoie developer-ul pentru depanarea problemei? Exist trace-ing, dump-uri, log-uri .a.m.d. ce ar trebui captate i furnizate cu acest raport al defectului? Documentai ce a fost capturat i cum poate fi accesat. Spre exemplu, cnd este esenial, oferii: fiiere .rtf, .lyt, Dr.Watson, etc.

2.1.10 Evidena
Ce poate demonstra existena erorii? Ai furnizat att rezultatele ateptate ct i cele obinute? Exist documentaie care suport rezultatele ateptate? Odat ce scriei un raport al problemelor este evident c credei c ntr-adevr exist o problem. Oferii orice pentru a convinge i pe alii c aceasta este ntradevr o problem valid. Evidena poate lua forma documentaiei de la utilizator, ghid-uri, specificaii, cerine i proiectri. La fel pot fi comentarii precedente ale clienilor, standarde de-facto de la produse competitive, sau rezultate de la versiunile precedente ale produsului. Nu credei c toi vd lucrurile la fel ca dvs. Nu ateptai ca oamenii s citeasc printre rnduri i s fac aceleai concluzii. Nu credei c peste 3 sptmni v vei aminti de ce ai crezut c este o eroare. Gndii-v ce v-a convins c este o eroare i includei aceasta n raport. Va trebui s oferii o eviden chiar mai ampl dac credei c exist ansa ca situaia s nu fie acceptat ndat ca o eroare valid.

2.1.11 List de verificare

Nu vei fi n stare s v ntoarcei i s studiai acest document de fiecare dat cnd scriei un raport. Este important s dezvoltai o list de verificare uor accesibil pe care o trecei prin minte de fiecare dat cnd scriei un raport al defectelor. Inspeciile s-au dovedit a fi cele mai puin costisitoare i cele mai efective metode de mbuntire a calitii soft-ului. Este important ca s memorizai aceast list de verificare utiliznd orice tehnici de memorie preferate. n majoritatea cazurilor rapoarte neadecvate a defectelor nu sunt datorit inabilitii de a scrie un raport bun. De obicei pur i simplu nu ne gndim s rspundem la ntrebrile corecte. Aceast list de verificare ne trece prin procesul de gndire i rspuns la ntrebrile corecte. Putei gsi util utilizarea mnemonicii pentru lista de verificare. Dac v uitai la prima liter a fiecrui item din list, aceasta devine CAN PIG RIDE? Aceasta este destul de relevant pentru a se memoriza uor. Dac zece itemi sunt prea muli pentru a memoriza, concentrai-v la PIG. Dac facei un lucru bun pe aceti trei itemi: Precizare, Izolare i Generalizare, acestea v vor ndruma spre rapoarte adecvate i mai efective a defectelor n majoritatea cazurilor.

3. Template de raport
5

Un template al remrcii defectului poate fi destul de util n asigurarea faptului c remrcile ofer informaia corect i rspund la ntrebrile corecte. Unele unelte de urmrire a defectelor pot permite afiarea unui template. Altfel, poate fi necesar ca s tiai i inserai un template n remrci. Un exemplu de template urmeaz. Data: Produs: Exploratoriu? Care Numele Sumar: Descriere detaliat: Pai de Reprodus: Note: Informaie de depanare suplimentar: (log-uri, referine, screenshot-uri, etc.) n raportarea efectiv a defectelor, ca i n multe situaii, nu conteaz att dac ai rspuns corect, ct dac ai rspuns la ntrebarea corect. Aceste zece puncte: Condensare Acuratee Neutralizare Precizie Izolare Generalizare Re-creare Impact Depanare Eviden Ofer o list de verificare rapid pentru asigurarea faptului c rapoartele defectelor rspund la ntrebrile corecte care vor aduce un beneficiu maxim organizaiei. 11.20.03 Y T. Popescu OS/Browser Versiunea Script de test? Win XP, SP1 4.5.36_1 N

3.1 Sumar:
O linie scurt de abstract care e asociat cu majoritatea defectelor este un instrument puternic de comunicare. Deseori, abstract-ul este unica poriune a defectului care este citit de ctre cei ce iau decizii. Abstractul, i nu ntreaga descriere, care este inclus n rapoarte. Abstractul este cel la care privesc managerii proiectelor, team liderii i ali manageri cnd ncearc s neleag defectele asociate cu produsul. Abstractul trebuie s fie concis, descriptiv i s transmit un mesaj clar. Abstractul este de obicei foarte limitat n lungime. Din cauza lipsei de spaiu, abrevierile sunt acceptate i mesajele scurte i clare au prioritate fa de o gramatic bun. O bun utilizare a cuvintelor-cheie este esenial odat ce multe cutri sunt bazate pe abstract. Cuvinte-cheie ca uuare, suspendare, typo .a.m.d. sunt descriptive i convenabile pentru cutare. Dac spaiul permite este de ajutor s fie indicat mediul, impactul, i una din cine, ce, cnd, unde, de ce ntrebri ce pot fi adresate ntr-un spaiu scurt. 6

Fii ct mai specific posibil. Spre exemplu, urmtorul abstract este adevrat, dar nu ofer informaie suficient pe ct ar fi putut. Sumar: Euarea CTPro. Posibil, un abstract mai descriptiv ar fi: Sumar: CTPro cade dup nchiderea ferestrei Stock Box prin Start Tool cnd este nchis fereastra de verificare a comenzii. Niciodat nu putei obine totul ce dorii ntr-un abstract. Iat o list de itemi care putei s-i includei ntr-un abstract.

3.1.1 Sumarul listei de verificare

Obligatoriu: 1. Concis, explicit prezentai problema. (Nu doar c exist o problem).

Recomandat: 1. 2. 3. 4. 5. Utilizai cuvinte-cheie relevante Prezentai mediul i impactul Rspundei la ntrebrile: cine, ce, cnd, unde, de ce i cum E acceptabil s utilizai abrevieri Gramatic e secundar fa de transmiterea mesajului

3.2 Descrierea Detaliat:

Testerii pierd o cantitate semnificativ de timp pentru cutarea i descoperirea problemelor de software. Odat detectate, productivitatea crete dac defectul este raportat astfel ca problema s fie fixat depunnd un efort minim. Asigurarea c este oferit informaia necesar este mai important ca abilitile superioare n scris. Cele 10 puncte descrise n acest document Condensare Acuratee Neutralizare Precizie Izolare Generalizare Re-creare Impact Depanare Eviden

v vor ajuta mult n oferirea informaiei corecte n fiecare raport al defectelor. Nu fiecare citete ntregul raport al defectelor. Muli din cei care iau decizii se bazeaz pe o linie de Sumar al defectului. Este important de scris abstracte care relev cu acuratee mesajul corect.

Cu ct mai bun suntei n scrierea rapoartelor defectelor i abstractelor, mai mare probabilitatea c problemele vor fi fixate ntr-un timp mai scurt. Credibilitatea i valoarea voastr pentru business va crete odat ce developerii, managerii i ali testeri vor putea face mai bine lucrul lor datorit rapoartelor defectelor bine scrise i de ncredere.

3.3 Pai de Reprodus:

1) 2) 3) Etc.

3.4 Note:
Exemple:

4.

Anexa A
Condensare (Spune clar, dar pe scurt) Acuratee (Este acesta un defect sau o eroare a utilizatorului, nenelegere, etc. ?) Neutralizare (Doar fapte. Fr nfrumuseri. Fr umor. Fr emoii.) Precizie (Explicit, care este problema?) Izolare (Ce a fost fcut pentru a izola problema?) Generalizare (Ce a fost fcut pentru a nelege ct de general este problema?) Re-creare (Care este esena iniierii/re-crerii acestei probleme?) Impact (Care este impactul asupra clientului?) Depanare (De ce are nevoie developer-ul pentru a depana aceasta?) Eviden (Ce documentaie va demonstra existena erorii?)

5. Referine:
Writing Effective Defect Reports de Kelly Whitmill IBM Printing Systems Division 6300 Diagonal Highway 003G Boulder, Colorado 80301 (303) 924-9145