TSM - Concepţii greșite despre testarea software

Sunt tester din 2004. Am avut multe roluri în 13 ani, dar m-am considerat mereu un tester. M-am bucurat când am găsit buguri care frizau niște situaţii/context  aproape imposbil de conceput. M-am simtit prost când mi-a scăpat ceva ce a făcut produsul dificil sau imposibil de utilizat în producţie. M-am ascuns în proiectele mele și în firma mea, considerând că sunt un tester bun. M-am aflat pe scenă în faţa a sute de oameni, așteptând acea întrebare care să mă facă să realizez ce stupide au fost presupunerile mele.  

Am întâlnit multe concepţii greșite despre testarea software. Cu unele veţi fi de accord, cu altele nu, dar consider că arta de a testa ține de împărtășirea ideilor și a experienţelor, acesta fiind chiar lucrul pe care intenţionez să îl fac.  Iată-le: 

• Oricine poate testa. A spune că toată lumea poate testa este ca și cum ai spune că oricine poate conduce. Amintiți-vă acest lucru când vă aflați în trafic. Dacă aveți păreri ferme în această privință, aruncați o privire pe TheTestingMap.org. Am pus pe această hartă tot ceea ce cred că ar trebui să știe un tester. 
• Testarea se poate face în orice circumstanțe. Este adevărat, dar rezultatele nu vor fi cele mai bune. Pentru a putea testa, e nevoie de testability (capacitatea de a fi testabil). Ce înseamnă acest lucru? Pentru a reține ușor, folosiți acronimul CHAOS UI ( Controllability, Heterogeneity, Automatability, Observability, Separation of concerns, Understandability, Isolateability).
• Să înțelegi specificațiile e suficient să le citești. Pentru a înțelege ceva, nu este suficient să citești acel lucru. Trebuie să îl înțelegi. Pentru aceasta, puteți utiliza o serie de tehnici precum: Critical Thinking Questions, Sashimi, Simulate and Model, Cubin, Drawing Diagrams and Flow….
• Testarea automată.  Acesta este un unicorn. Toți vorbesc despre ea, dar nimeni nu o poate vedea. Există testare automată tot atât cât există programare automată. Tetarea automatizată este o chestiune pentru viitor. Termenul corect este test automation (automatizarea testelor). Realizezi un test, pentru ca apoi, pentru a eficientiza munca, decizi să automatizezi niște etape de verificare. Finalmente, nu există nici automatizare de teste, ci automatizarea unor verificări/validări. Instruiești un program să verifice niște lucruri. Programul nu va spune niciodată că ceva e ciudat și va verifica și acest aspect. Va face doar lucrurile pe care îl instruiți să le facă.
• Testare manuală vs. Testare automată. În primul rând, vă rog să citiți punctul de mai sus. Nu există testare automată. În al doilea rând, toată testarea este manuală. Totul se face cu mâna, tot așa cum scrierea de programe se face cu mâna. Termenul "manual" nu este cel mai potrivit în acest context, deoarece nu acoperă raționamentul și brainstormingul din spate. După cum spune și Michael Bolton: "we help to cheapen and demean the craft" ("ajutăm la ieftinirea și minimalizarea meseriei") utilizând termenul "manual" lângă termenul "testare" (Dacă primul lucru la care vă gândiți este cum poate un cântăreț să vorbească despre testare, atunci nu vă gândiți la Michael Bolton cel potrivit. Ar trebui să vă faceți timp să ascultați marile minți din testarea software). Termenul "manual" nu are o alură prea inteligentă. 
• Testerii sunt programatorii care nu au avut succes. Dacă ești un tester ce cunoaște tehnicile de testare, ce folosește gândirea critică, ce știe cum este creat un software, poți deveni un programator grozav, dacă vrei. Ai nevoie doar de motivație și de conștientizarea faptului că vei fi junior într-un domeniu nou. Am văzut de puține ori testeri ce au devenit programatori. Cel mai des, ei devin Project Managers, Scrum Masters, Business Analysts. Din echipa inițială de testeri în care am început să lucrez în 2004, sunt singura persoană încă pasionată de testare. Consider că testerii se mută pe alte poziții din două motive: se plictisesc (nu înțeleg rostul activității) sau devin mai valoroși pentru companie în alte poziții. A fi tester presupune că vei acumula multă experiență în legătură cu ce merge și cu ce nu merge, că vei ști cum să lucrezi cu oamenii, că poți să anticipezi așteptările ….
• Testerii cu mai mult de cinci ani experiență sunt seniori. Să nu confundăm cinci ani de experiență cu un an de experiență multiplicat de cinci ori. Experiența vine odată cu interacțiunea cu diferite aplicații, tehnologii, echipe și metode de lucru. Un tester este senior dacă poate străluci în orice context de testare, nu doar în cadrul aplicației pe care o testează de cinci ani. 
• Asigurarea calității înseamnă testare. Să fim sinceri: asigurarea calității nu înseamnă testare. Asigurarea calității reprezintă un mod de a ne asigura că produsul final este de calitate. Calitatea nu se întâmplă pur și simplu: ea trebuie definită. Un tester (sau inginer de asigurare a calității, cum este adesea denumit) nu este responsabil de calitatea codului, de faptul că alți membri ai echipei respect procesul sau nu. Dacă doriți mai multe informații despre asigurarea calității, vă rog accesați articolul din Today Software Magazine unde am descris în detaliu acest aspect. 
• Testerii trebuie să găsească buguri. Bugurile sunt doar un tip de informație. Testerii ar trebui să livreze informație relevantă legată de elementele pe care factorii de decizie le consideră importante. 
• Testerii distrug software-ul. După cum a spus și Michael Bolton "testers do not break software, the software is already broken" ("testerii nu distrug software-ul, acesta e deja distrus când ajunge la testeri"). 
• E bine să numeri testele. A număra testele este același lucru cu a număra liniile de cod per programator. Acest aspect nu oferă nicio informație relevantă. Este o pierdere de timp și resurse. Gândiți în termeni de calitate, nu cantitativ. De exemplu, la câte verificări automatizate găsim un bug? Acesta este un bun exemplu de metodă prin care se pot măsura calitatea și succesul procesului de automatizare.
• Testerii trebuie doar să fie deștepți. Evident, dacă ești deștept, poți fi bun în multe domenii, dar pentru testarea software trebuie să știi cel puțin care sunt abordările și tehnicile de testare. Ce sunt acestea? Cum se folosesc? Ce rezultate se așteaptă? Testarea are nevoie de multă învățare și introspecție. 
• Sunt un tester bun. S-ar putea să fii, dar realmente consideri că aparții acestei meserii? Contribui cu ceva în cadrul comunității tale? Faci parte din vreo comunitate? La fel ca în familia ta, ca în proiectele tale, ai putea fi un tester bun (persoană bună). Eu cred că adevărata măsură a acestui aspect vine din cât de mult oferi comunității și cât de mult feedback primești în legătură cu ce faci și cum faci, lucru ce poate fi validat doar de ceilalți testeri și comunitate, la conferințe, de exemplu. Din experiența mea, când participi la o conferință se pot întâmpla două lucruri:  vezi ce chestii grozave fac alții și ești inspirat să faci la fel, sau, după cum spunea Ion Creangă: "Ştiu că sunt prost, dar când mă uit în jur prind curaj". Dacă începi să crezi că poți face lucrurile mai bine, atunci nu ezita să le faci. 
• Testerii aduc vești proaste. La prima vedere este adevărat, dar un tester poate oferi și posibilitatea de a vedea în viitor. Testerii ar trebui să spună: _"Încă nu ai terminat!_" Mai sunt lucruri de făcut. Nu e rău să știi ce ai de făcut pentru a ajunge acolo!
• Testarea este o activitate analitică. E greu de zis. Am crezut acest lucru la început. E destul de simplu: ai niște specificații (oricum ar arăta), ai niște tehnici de testare și poți produce teste de calitate. Corect? Se pare că și în cele mai simple activități, nu este suficient să stăpânești tehnica. Cum folosești tehnica? Când o folosești? Cum obții cele mai bune rezultate în cel mai scurt timp posibil? Acestea vin odată cu experiența. Testarea e o artă. Ar trebui să îți găsești unul sau mai mulți mentori care să te ghideze. Dacă crezi că testarea este o activitate analitică, accesează testingchahallenges.thetestingma.org și află dacă poți găsi cele 18 validări necesare pentru a testa un singur câmp de tip text. 
• Este în regulă să testezi la final de sprint. Să consultăm ghidul Scrum: "Echipele Scrum livrează produse iterativ și incremental, maximizând oportunitățile de feedback". Nu prea îți poți maximiza oportunitățile de feedback dacă testezi la final, nu-i așa? Să ne uităm și la principiul 7 al Agile Manifesto: "Procesele Agile promovează dezvoltarea sustenabilă. Sponsorii, programatorii și utilizatorii ar trebui să poată menține un ritm constant pe termen nedefinit.". Ce ritm ai tu, dacă testezi la final? E mai degrabă un salt. Testarea efectuată doar la final nu îți va da oportunitatea păstrării unui ritm pe termen nedefinit.
• Nu sta deoparte dacă observi concepții greșite despre testare. Luptă-te. Pune totul sub semnul întrebării. Provoacă lumea la discuții. Atâta timp cât folosim testarea automată și termenul "testare manuală", noi vom fi de vină dacă permitem concepțiilor greșite să devină practici comune.