Cele 7 principii ale testarii software
Cand ne gandim la un domeniu si mai ales la bazele acestuia, trebuie sa fim constienti ca peste tot avem anumite legi fundamentale sau principii care guverneaza la nivel general acel domeniu. Aceste principii sunt valabile pentru respectiva nisa deoarece servesc ca punct de pornire pentru alte legi, reguli sau idei care nu pot exista in afara cadrului ingradit de ideile fundamentale.
Ca exemplu, ne putem gandi la Constitutia unei tari (= legea ei fundamentala), si la faptul ca restul legilor deriva din aceasta, nu o pot incalca sau ocoli. Si in testarea software avem astfel de principii care alcatuiesc specificul ei de baza si care guverneaza aceasta ramura, in teorie dar mai ales in practica.
Cele 7 principii ale testarii software
In testarea software exista mai exact 7 principii care reprezinta niste idei universal valabile in practica, de la care pornesc restul regulilor si ideilor teoretice pe care trebuie sa le cunoastem. Chiar daca nu le stim ca atare, ele apar aproape in mod inevitabil in practica, fiind si niste idei de bun-simt, a caror ignorare poate atrage consecinte negative.
Ordinea acestor principii nu e una fixa, depinde de sursa consultata. Un prim loc unde sunt enumerate si explicate este manualul ISTQB, dar si pe multe alte site-uri.
1. Testarea ne arata prezenta defectelor, nu lipsa lor
Atunci cand desfasuram diferite strategii si metode specifice de testare pentru un produs software, acestea ne vor scoate in evidenta faptul ca anumite bug-uri sunt prezente. Insa in acest caz afirmatia reciproca, cum ca defectele sunt absente daca nu le-am depistat nu se sustine.
Acest lucru se explica prin faptul ca aproape intotdeauna vor fi anumite bug-uri pe care nu le depistam la momentul potrivit, ci probabil in timp. Mai ales in contextul aplicatiilor destul de complexe de astazi, mereu vor exista defecte, mai mari sau mai mici, care nu vor fi vizibile, dar asta nu inseamna ca ele nu exista.
2. Testarea exhaustiva este imposibila
Formulat destul de simplu, acest al doilea principiu al testarii software este clar si direct: oricat de mult ne-am stradui, nu avem cum sa testam 100% complet un produs software. Acest principiu deriva din primul mentionat, deoarece daca vor exista defecte ascunse in aplicatie, nedepistate, atunci inseamna ca testarea aplicatiei nu s-a realizat complet, ci intr-o masura mai mica.
Desigur, scopul ramane acela de a incerca prin cat mai multe mijloace, strategii si discutii cu echipa sa fie identificate cat mai multe erori si defecte pentru a creste in final calitatea produsului care va ajunge la utilizatori. Insa nu trebuie sa intervina frustrari din cauza unor complexitati care fac testarea completa imposibila.
3. Testarea timpurie economiseste timp si bani
Acest principiu contine o idee ce poate fi intalnita extrem de des in practica, si anume cu cat descoperim mai din timp erorile in produsele verificate, cu atat va fi mai usor sa fie corectate, cu implicatii financiare si de timp mai mici.
Daca un bug e descoperit tarziu in Software Development Life Cycle, eventual chiar dupa ce a fost lansat oficial, atunci costurile necesare remedierii vor fi mai mari, si va fi mai greu de modificat un cod ajuns intr-o faza mai avansata, decat daca era depistat in fazele incipiente din SDLC si corectat aproape imediat, prin discutii.
4. Defectele se grupeaza impreuna
De multe ori se spune ca o problema nu vine niciodata singura. Cam asa se traduce si acest principiu al testarii software. De regula exista anumite componente mai mici din cadrul aplicatiei care aduna un numar mai mare de bug-uri ce se rasfrang apoi asupra calitatii generale.
Acest principiu a fost pus in evidenta la nivel general de sociologul Vilfredo Pareto, cunoscut si ca regula 80 / 20. Mai concret, aplicat pe cazul testarii software, 20% dintr-o aplicatie cuprinde 80% din defecte (si invers). Asa ca daca este gasit un bug intr-o sectiune a aplicatiei, atunci e foarte posibil ca acolo sa se mai ascunda si alte defecte.
5. „Paradoxul pesticidelor”
Preluand metaforic o situatie practica din realitatea cotidiana, principiul „paradoxului pesticidelor” in testare se refera la faptul ca daca aplicam mereu aceleasi tipuri si metode de testare, la un moment dat noile defecte nu vor mai fi depistate de acestea.
La fel ca gandacii din viata reala, si bug-urile din aplicatii vor deveni mai „rezistente” la aceste metode, vor aparea altele noi si atunci trebuie sa fim creativi si sa nu folosim doar tehnicile vechi, deja cunoscute. Revizuirea si rediscutarea constanta a cazurilor de test si a strategiilor aplicate pot ajuta la evitarea situatiei stipulate de „paradoxul pesticidelor”.
6. Testarea este dependenta de context
La fel ca cele precedente, si acest principiu inglobeaza o idee simpla si de bun-simt. Procesul testarii software depinde in mod covarsitor de contextul oferit de aplicatia respectiva, de scopul ei si de prevederile din documentatia tehnica.
De exemplu, daca un buton de pe un site pe care il avem la test este rosu, atunci acest simplu caz nu ne duce neaparat cu gandul ca e un defect. Dar daca in documentatia proiectului scrie ca respectivul buton trebuie sa aiba de fapt culoarea verde, atunci acest context largit ne ofera perspectiva unui bug depistat.
De aceea, testarea se realizeaza diferit, cu metode diferite de la caz la caz, si trebuie tinut cont de cat mai multe detalii, nu sa fie facuta in graba.
7. Ideea gresita a absentei defectelor
Ultimul principiu de care discutam este cel al credintei eronate ca un produs software poate ajunge la stadiul cand nu mai prezinta erori si defecte functionale, iar in ciuda acestui lucru, acel produs sa nu indeplineasca cerintele clientului sau sa nu fie de folos unui business.
Pe langa verificarea propriu-zisa a produsului, sa vedem ce merge la el si ce nu, daca este in regula din punct de vedere tehnic, trebuie sa existe atentie si pentru cerintele clientului, daca sunt indeplinite, astfel incat acesta sa fie multumit. Nicio aplicatie nu e lipsita de bug-uri, dar trebuie sa aiba un scop de utilitate practica.
De ce sunt importante aceste principii?
Asa cum mentionam si la inceputul articolului, aceste principii nu fac decat sa reuneasca intr-o formulare generala anumite idei de bun-simt legate de testare care se intalnesc foarte frecvent in practica.
De aici deriva si importanta lor: daca le cunoastem, atunci vom sti mult mai bine la ce sa ne asteptam cand suntem implicati intr-un proces de testare, la anumite situatii sau reguli care descriu scenarii realiste si inevitabile, precum testarea 100% a unui produs (caz extrem de improbabil).
De asemenea, cunoasterea acestor principii poate ajuta la o mai buna intelegere a domeniului testarii software, mai ales daca suntem la inceputul studierii ei. Ele ne ajuta sa stim mai bine cum sa ne raportam in mod realist la procesul de testare, definindu-i bazele care sunt universal valabile indiferent de produsul testat, de proiect sau de compania in care vom lucra.
Concluzii
In incheiere, cele 7 principii ale testarii software reprezinta un subiect folositor de stiut atunci cand citim si invatam despre testarea software. Ele contureaza intr-o maniera formulata concis anumite reguli care provin din practica recurenta a procesului de testare, si care devin astfel valabile in majoritatea situatiilor.
Cunoasterea lor poate fi utila pentru a ne seta anumite asteptari atunci cand suntem implicati in acest proces, si ne ajuta sa avem o abordare mult mai realista cand vine vorba de organizarea testarii, in termeni de strategii si obiective. Desigur, situatii neasteptate pot aparea oricand, dar bazele raman importante.
Surse consultate si aditionale
Despre cele 7 principii ale testarii, cu explicatii si exemple gasiti aici, aici si aici.
Manualul ISTQB (Foundation Level) vorbeste si el de aceste principii.
Un articol succint despre acestea de pe Linkedin.
Despre Principiul lui Pareto (80/20).
Erori, defecte si esecuri in testarea software.
Sursa imaginii de cover + alte explicatii despre principii.
