În timp ce pregătește următoarea postare din serie despre automatizare. Am vrut să împărtășesc, după părerea mea, materiale interesante din cartea Agile Testing: Un ghid practic pentru testere și echipe agile.
Deci, există o mulțime de tipuri de testare: încărcare, ad hoc, sanitară, cutie neagră, cutie albă și așa mai departe. Și de mult timp nu am întâlnit un sistem bun care să conțină o grupare normală a tuturor acestor specii și să ofere o explicație când și de ce ar trebui folosite. Și tocmai a doua zi am citit despre Quadrantul de testare agil (ATQ), despre care vreau să spun.
De fapt, sistemul arată astfel:
După cum se poate observa, diagrama clasică este 2 * 2. Deci, pe una dintre axele testelor sunt împărțite în afaceri orientate și orientate spre tehnologie, cealaltă axă - pentru teste pentru a sprijini echipa și pentru „Produsul de critici.“ Vreau doar să remarcăm că numerotarea nu spune nimic când să efectueze aceste teste.
Să trecem prin fiecare sector.
Sectorul Q1 este o practică bine cunoscută ca TDD. Este simplu: primul test, apoi codul. Și aceste teste sunt în primul rând responsabilitatea echipei de dezvoltare. Toate aceste teste trebuie executate prin CI, pentru verificarea constantă a calității codului. Toate acestea sunt pictate în multe surse, pentru cei care nu au practicat încă TDD, vreau să recomand acest link aici.
Sectorul Q2 conține mai multe teste la nivel înalt, care au deja legătură cu afacerile. Trecerea cu succes a acestor teste este obligatorie pentru a vorbi despre finalizarea oricărei funcționalități. Pentru că putem spune că această sau pe cea funcțională se realizează atunci când rezolvă una dintre sarcinile pe care le prezintă utilizatorii de afaceri. La acest nivel, shell-ul exterior al aplicației este practic testat: interfață, API, servicii web și așa mai departe. Pe de altă parte, acest sector include testarea prototipurilor, mocapelor, modelelor și așa mai departe. Adesea, testul de acceptare a termenului este folosit pentru a se referi la testele care sunt incluse. deși acest lucru nu este în întregime adevărat, deoarece testele din sectoarele Q3 și Q4 merită, de asemenea, să fie atribuite testelor de acceptare.
Testele din sectorul Q3 implică participarea obligatorie a experților în domeniul domeniului, experți în utilizare, utilizatori și așa mai departe. De multe ori se întâmplă că funcționalitatea implementată nu rezolvă cu adevărat problemele clientului sau ceva a fost înțeles greșit de echipa de dezvoltare. Din nou, ar putea apărea noi aspecte legate de lucrul cu obiecte de domeniu sau a devenit clar faptul că interfața proiectată nu a fost convenabilă pentru utilizatori. Aici intră în joc testele destinate "criticii" produsului. Faceți imediat o rezervă că cuvântul "critică" are aici o conotație pozitivă. Este de la sine înțeles că această testare poate fi numai manuală, deoarece niciun script nu poate detecta problemele indicate, deși, desigur, putem folosi instrumente auxiliare, de exemplu, pentru a încărca date.
Și, în sfârșit, ultimul sector al Q4. care vorbește despre acele teste care nu testează rezolvarea problemelor de afaceri, dar vorbesc despre cât de bine este scris aplicația noastră, folosind termeni precum securitatea, performanța, stabilitatea, scalabilitatea și așa mai departe. Aceste teste vă vor ajuta să verificați respectarea cerințelor nefuncționale, dacă există, și să înțelegeți modul în care a fost proiectată cu succes aplicația într-un stadiu incipient. Aceste teste contribuie foarte mult la evitarea problemelor în viitor. Este clar că pentru efectuarea unor astfel de verificări trebuie să folosiți instrumente speciale, care sunt prezentate în prezent foarte mult.
Astfel, Quadrant-urile de testare Agile sunt un fel de listă de verificare care arată că ne îndreptăm în direcția corectă, că procesele noastre sunt suficient de automatizate și se pot angaja în teste de cercetare manuală. Și cel mai important, Quadrantul de testare Agile va arăta cât de succes este produsul nostru, în termeni de afaceri.