Pe blogul ăsta am tot vorbit despre relații, sex, obsesii și vise dar nu am prea vorbit despre ceea ce-mi consumă majoritatea timpului și uneori și a nervilor: munca. Sâmbătă am venit la birou ca să-mi dovedesc că nu sunt nebun. Vineri am descoperit un bug care se reproducea inclusiv pe codul pe care îl testasem acum câteva săptămâni. Știam că am mai rulat testul respectiv și trecea însă acum pe exact același cod pica. Știam că nu sunt nebun dar din exterior așa părea. Oricum, nu vreau să vă vorbesc despre acest bug ci despre cum văd eu „circuitul bug-urile în natură”.
Noi avem o politică destul de sănătoasă: dacă cineva are mai mult de 10 „defecte” deschise trebuie să se oprească din ceea ce face ca să se ocupe de ele. Ce înseamnă să te ocupi de ele? Simplu: fie să le repari, fie să validezi că sunt reparate, să le marchezi ca „not a bug” sau să le închizi pentru că nu mai sunt de actualitate. Eu văd însă lucrurile puțin mai drastic: dacă se ajunge să ai 10 bug-uri la un produs nu mai are sens să continui să lucrezi la acel produs. De ce? Pentru că e evident că chiar dacă îndrep problemele existente vor apărea mereu altele. În plus, mie nu îmi place să rezolv problemele găsite. Nu, eu le las acolo. Singurul lucru care e posibil să-l fac e să-l închid pentru că e „obsolete”: nu o mai consider o problemă. Mi se pare că doar așa pot să zic că sunt sincer cu mine. Evident că există o excepție: dacă apar probleme majore lumea e obligată să se ocupe imediat de rezolvarea lor. Lumea. Eu mă decid că nu mai are rost să continui investiția în proiect. Dacă ceva trebuie explicat atunci nu ai cum să înțelegi. Dacă ceva trebuie îmbunătățit atunci clar nu e ceea ce cauți.
Un alt lucru pe care toată lumea îl știe e că o problemă găsită mai repede costă mult mai puțin să fie îndreptată decât o problemă găsită târziu. De exemplu, dacă găsești un defect revizuind specificațiile unui produs e mult mai simplu să îl repari decât dacă îl găsești la code review sau la testarea de funcționalitate. Pe mine nu mă ajută extrem de mult asta ținând cont că oricum nu am de gând să le repar dar cu cât găsesc mai repede defectele cu atât pot să mă decid mai repede că nu mai are sens să-mi pierd timpul cu un proiect care nu se îndreaptă spre nivelul de calitate pe care îl aștept eu. Evident că indiferent de stadiul în care este găsită problema contează și gravitatea ei.
Prea multă teorie. Să luăm un exemplu: te afli în metrou. E o tipă relativ simpatică în fața ta. Ea îți zâmbește. Tu îi răspunzi la zâmbet. Așa începe review-ul specificațiilor. Îți place că e brunetă cu ochi verzi, formele sunt interesante, zâmbet frumos. Găsești în primul minut două probleme, minore ce-i drept: poartă Uggsi și citește Coelho. După un minut în care nu mai găsești niciun defect evident îi sună telefonul și așa apare un „show stopper” (prioritate A+): îl are pe Guță la soneria de la mobil. Gata! Nu mai are sens să investești. De dragul exercițiului să presupunem însă că soneria de la telefon e una clasică, de exemplu cea pe care o ai și tu la mobil. Până vine stația ta mai observi un defect relativ grav dar nu destul de grav să abandonezi implementarea: la un moment dat i se adresează persoanei cu care vorbește cu apelativul „fată”.
Coborâți la aceeași stație și pe scările rulante o abordezi și o chemi la o bere. Ea acceptă. S-a terminat procesul de „spec review” și urmează cel de „code review”. La prima întâlnire bea și ea bere așa că problema legată de cizmele ei devine atât de mică încât poți să o închizi pentru totdeauna. Îți dai seama și că acel „fată” a fost adresat într-un mod ironic. Apar însă alte două probleme: nu i-a plăcut De Veghe În Lanul de Secară (un B) și i-a plăcut in Viena (un C pus pe lista doar pentru că te simți prost să nu ai decât 3 defecte rămase deschise). Nici după a treia întâlnire nu ai destul de multe informații ca să renunți așa că după ce se trezește a doua dimineață la tine începi procesul de testare funcțională.
După 3 luni în care au apărut și au dispărut zeci de defecte pe lista (niciun nu a fost remediat și niciodată nu s-a trecut de limita de 10 simultan) decizi că e momentul de a duce lucrurile un pas mai în față. Vă mutați împreună și te pregătești sufletește pentru o perioadă pe care nu ai mai experimentat-o niciodată: testarea de integrare și de sistem.
La un moment dat ești gata să renunți în dimineața în care tu i-ai pregătit micul dejun dar ea în loc să-ți mulțumească cu un zâmbet s-a întors pe partea cealaltă și a continuat să doarmă. Îți dai seama că totuși nu e atât de gravă problema mai ales că nu ai reușit să o mai reproduci așa că te mulțumești cu viața liniștită a unui produs care se învârtă mereu între 5 și 6 defecte deschise. Ai vrea să o continui așa cât mai mult timp dar îți dai seama că oricum nu poți face testare exhaustivă oricât ai vrea. Gândul unui produs 1.0 te sperie așa că scoți la bătaie o baterie de teste negative cumulate cu teste de performanță și de stres. Niciun A sau A+. Nu a mai vorbit cu tine o seară întreagă dar îți dai și tu seama că probabil e normal să reacționeze așa după ce ai lăsat-o să te aștepte timp de două ore în fața barului vostru preferat. Îți dai seama cu ocazia asta cât de important că fiecare test să aibă un punct de validare foarte clar.
Într-un final nu ai decât două opțiuni: să te bazezi pe toată munca de testare făcută până atunci și să spui cu mâna pe inimă: „Da, lansăm și va fi un produs perfect!”, sau să-ți dai seama că dacă nu a picat nici cele mai dubioase teste sigur e ceva în neregulă cu strategia ta de testare, să renunți și să o iei de la capăt cu revizuirea specificațiilor altui proiect.
Un singur lucru e cert: dacă ceva are un lucru care trebuie îmbunătățit atunci clar nu e acel Ceva pe care îl cauți.