Insemnari

Bugs

Filed under: Din viata,Work related — Gelu November 28, 2011 @ 15:53

Pe blogul asta am tot vorbit despre relatii, sex, obsesii si vise dar nu am prea vorbit despre ceea ce-mi consuma majoritatea timpului si uneori si a nervilor: munca. Sambata am venit la birou ca sa-mi dovedesc ca nu sunt nebun. Vineri am descoperit un bug care se reproducea inclusiv pe codul pe care il testasem acum cateva saptamani. Stiam ca am mai rulat testul respectiv si trecea insa acum pe exact acelasi cod pica. Stiam ca nu sunt nebun dar din exterior asa parea. Oricum, nu vreau sa va vorbesc despre acest bug ci despre cum vad eu “circuitul bug-urile in natura”.

Noi avem o politica destul de sanatoasa: daca cineva are mai mult de 10 “defecte” deschise trebuie sa se opreasca din ceea ce face ca sa se ocupe de ele. Ce inseamna sa te ocupi de ele? Simplu: fie sa le repari, fie sa validezi ca sunt reparate, sa le marchezi ca “not a bug” sau sa le inchizi pentru ca nu mai sunt de actualitate. Eu vad insa lucrurile putin mai drastic: daca se ajunge sa ai 10 bug-uri la un produs nu mai are sens sa continui sa lucrezi la acel produs. De ce? Pentru ca e evident ca chiar daca indrepti problemele existente vor aparea mereu altele. In plus, mie nu imi place sa rezolv problemele gasite. Nu, eu le las acolo. Singurul lucru care e posibil sa-l fac e sa-l inchid pentru ca e “obsolete”: nu o mai consider o problema. Mi se pare ca doar asa pot sa zic ca sunt sincer cu mine. Evident ca exista o exceptie: daca apar probleme majore lumea e obligata sa se ocupe imediat de rezolvarea lor. Lumea. Eu ma decid ca nu mai are rost sa continui investitia in proiect. Daca ceva trebuie explicat atunci nu ai cum sa intelegi. Daca ceva trebuie imbunatatit atunci clar nu e ceea ce cauti.

Un alt lucru pe care toata lumea il stie e ca o problema gasita mai repede costa mult mai putin sa fie indreptata decat o problema gasita tarziu. De exemplu, daca gasesti un defect revizuind specificatiile unui produs e mult mai simplu sa il repari decat daca il gasesti la code review sau la testarea de functionalitate. Pe mine nu ma ajuta extrem de mult asta tinand cont ca oricum nu am de gand sa le repar dar cu cat gasesc mai repede defectele cu atat pot sa ma decid mai repede ca  nu mai are sens sa-mi pierd timpul cu un proiect care nu se indreapta spre nivelul de calitate pe care il astept eu. Evident ca indiferent de stadiul in care este gasita problema conteaza si gravitatea ei.

Prea multa teorie. Sa luam un exemplu: te aflii in metrou. E o tipa relativ simpatica in fata ta. Ea iti zambeste. Tu ii raspunzi la zambet. Asa incepe review-ul specificatiilor. Iti place ca e bruneta cu ochi verzi, formele sunt interesante, zambet frumos. Gasesti in primul minut doua probleme, minore ce-i drept: poarta Uggsi si citeste Coelho. Dupa un minut in care nu mai gasesti nici un defect evident ii suna telefonul si asa apare un “show stopper” (prioritate A+ ): il are pe Guta la soneria de la mobil. Gata! Nu mai are sens sa investesti. De dragul exercitiului sa presupunem insa ca soneria de la telefon e una clasica, de exemplu cea pe care o ai si tu la mobil. Pana vine statia ta mai observi un defect relativ grav dar nu destul de grav sa abandonezi implementarea: la un moment dat i se adreseaza persoanei cu care vorbeste cu apelativul “fata”.

Coborati la aceiasi statie si pe scarile rulante o abordezi si o chemi la o bere. Ea accepta. S-a terinat procesul de “spec review” si urmeaza cel de “code review”. La prima intalnire bea si ea bere asa ca problema legata de cizmele ei devine atat de mica incat poti sa o inchizi pentru totdeauna. Iti dai seama si ca acel “fata” a fost adresat intr-un mod ironic. Apar insa alte doua probleme: nu i-a placut De Veghe In Lanul de Secara (un B) si i-a placut in Viena (un C pus pe lista doar pentru ca te simti prost sa nu ai decat 3 defecte ramase deschise). Nici dupa a treia intalnire nu ai destul de multe informatii ca sa renunti asa ca dupa ce se trezeste a doua dimineata la tine incepi procesul de testare functionala.

Dupa 3 luni in care au aparut si au disparut zeci de defecte pe lista (nici unul nu a fost remediat si niciodata nu s-a trecut de limita de 10 simultan) decizi ca e momentul de a duce lucrurile un pas mai in fata. Va mutati impreuna si te pregatesti sufleteste pentru o perioada pe care nu ai mai experimentat-o niciodata: testarea de integrare si de sistem.

La un moment dat esti gata sa renunti in dimineata in care tu i-ai pregatit micul dejun dar ea in loc sa-ti multumeasca cu un zambet s-a intors pe partea cealalta si a continuat sa doarma. Iti dai seama ca totusi nu e atat de grava problema mai ales ca nu ai reusit sa o mai reproduci asa ca te multumesti cu viata linistita a unui produs care se invarte mereu intre 5 si 6 defecte deschise. Ai vrea sa o continui asa cat mai mult timp dar iti dai seama ca oricum nu poti face testare exhaustiva oricat ai vrea. Gandul unui produs 1.0 te sperie asa ca scoti la bataie o baterie de teste negative cumulate cu teste de performanta si de stres. Nici un A sau A+. Nu a mai vorbit cu tine o seara intreaga dar iti dai si tu seama ca probabil e normal sa reactioneze asa dupa ce ai lasat-o sa te astepte timp de doua ore in fata barului vostru preferat. Iti dai seama cu ocazia asta cat de important ca fiecare test sa aibe un punct de validare foarte clar.

Intr-un final nu ai decat doua optiuni: sa te bazezi pe toata munca de testare facuta pana atunci si sa spui cu mana pe inima: “Da, lansam si va fi un produs perfect!”, sau sa-ti dai seama ca daca nu a picat nici cele mai dubioase teste sigur e ceva in neregula cu strategia ta de testare, sa renunti si sa o iei de la capat cu revizuirea specificatiilor altui proiect.

Un singur lucru e cert: daca ceva are un lucru care trebuie imbunatatit atunci clar nu e acel Ceva pe care il cauti.

No Comments »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a comment