Introducere
În multe proiecte cu care am lucrat, oamenii nu și-au personalizat TestRail și s-au descurcat cu setările standard. Așadar, în acest articol, voi încerca să descriu un exemplu de setări personalizate care ar putea să vă ajute să îmbunătățiți eficiența muncii dvs. Pentru exemplu, să luăm un proiect de dezvoltare a unei aplicații mobile.
O mică precizare. În acest articol nu este descrisă funcționalitatea de bază a TestRail (există multe ghiduri pentru aceasta) și nu sunt folosite expresii comerciale care să descrie plăcut de ce ar trebui să alegi acest furnizor pentru a crea un depozit de teste.
Plan de fundamentare (ce va fi implementat)
Cerințe generale
Cazul trebuie să poată fi parcurs de oricine
Cazurile trebuie să își păstreze relevanța cât mai mult timp
Cazurile trebuie să acopere cât mai bine funcționalitatea aplicației mobile, în măsura în care acest lucru nu contravine primelor două puncte
Separarea în TestCase și TestScenario
Generarea rapidă a TestRun de tipuri diferite
Smoke
Regress
Testarea de Impact etc.
Optimizarea suportului pentru cazuri
Renunțarea la capturi de ecran „moarte” hardcodate și trecerea la „date mutabile”
Cerințe
Pentru a edita câmpurile, aveți nevoie de acces de administrator
Alegerea tipului de proiect
Se pot alege trei tipuri de proiecte:
Vom alege tipul implicit. În acesta vor fi disponibile simultan toate cazurile. Vom folosi filtrarea inteligentă și vom gestiona dinamic toate cazurile deodată.
Adăugarea câmpurilor pentru vizualizarea listei de teste
Vom adăuga un câmp pentru a afișa prioritatea testelor:
De asemenea, se pot adăuga și alte câmpuri.
Configurarea câmpurilor și etichetelor testelor
Deschidem meniul de configurare:
Avem nevoie de următoarele câmpuri:
Câmpul „Summary” (antetul testului)
Acest câmp există deja, vom sistematiza doar utilizarea sa. Vom separa cazurile în TestCase și TestScenario. Pentru o mai bună citire a unei liste mari de cazuri, cel mai bine este să convenim din timp asupra regulilor de redactare a rezumatului.
TestScenario:
Exemplu: TestScenario — Principalul scenariu de utilizare al aplicației mobile
TestCase:
Exemplu: MainScreen — Secțiunea de autentificare — Introducerea numelui de utilizator
Prin urmare, vedem în rezumatul cazului o înțelegere clasică: „ce, unde, când”. De asemenea, vizual separăm scenariile de testare de nivel superior și cazurile de testare de nivel inferior într-o formă care este cel mai potrivit pentru automatizare.
Eticheta „StartScreen” (ecranul de început al TestScenario, de asemenea, multe teste pot afecta ecranele învecinate)
Pentru ce poate fi necesar: vom elimina din textul testelor pașii standard care duc utilizatorul la ecranul testului curent. (pașii standard pentru crearea unei situații de testare specifice) Toți pașii standard pentru toate testele vor fi descriși într-un singur fișier. Despre acesta voi scrie mai în detaliu separat.
Creăm un nou câmp:
Umplem componentele noului câmp:
În acest caz, creăm un câmp de selecție dintr-o listă de valori. Introducem valorile acestui câmp:
Atenție, ID-urile valorilor nu încep de la unu și nu sunt consecutive. De ce așa? Motivul este că, dacă vom avea teste înregistrate cu ID-uri introduse,
și după aceea va fi necesar să creăm un al treilea ecran între cele două existente,
atunci va trebui să rescriem ID-urile, iar deoarece acestea sunt deja legate de etichetele testelor existente, ele vor fi pur și simplu șterse. Acest lucru va fi foarte neplăcut.
Eticheta „Screen” (denumirea ecranului care este afectat de TestCase)
Pentru ce poate fi necesar: unul dintre punctele de ancorare pentru testarea impactului. De exemplu, dezvoltatorii au realizat o nouă caracteristică grozavă. Trebuie să o testăm, dar pentru aceasta trebuie să înțelegem ce anume ar putea fi afectat de această caracteristică. În mod implicit, ne putem baza pe paradigma că diferitele ecrane (Activity) ale aplicației au clase diferite și, prin urmare, formează componente diferite ale aplicației. Desigur, în acest caz este necesară o abordare individuală.
Exemplu: home_screen, MapScreen, PayScreen etc.
Câmpul „MovableData” (link către baza de date proxy cu datele de test modificabile)
În continuare, vom încerca să rezolvăm problema menținerii actualizării datelor în teste:
Linkuri către machete actualizate (acesta este mult mai bine decât să facem capturi de ecran moarte)
Pașii standard până la ecranul cu situația de testare
Interogări SQL
Linkuri către date externe și alte date
În loc să introducem datele de testare în fiecare caz de test, vom crea un fișier extern și vom face referire la acesta în toate cazurile de test. Atunci când actualizăm aceste date, nu va trebui să parcurgem toate cazurile de test pentru a le modifica, ci putem schimba aceste date într-un singur loc. Dacă cineva neavizat deschide un caz de test, va vedea în corpul cazului de test un link către fișier și o sugestie că trebuie să meargă acolo pentru datele de testare.
Toate aceste date le vom ambala într-un singur fișier extern, care va fi disponibil tuturor celor interesați în proiect. De exemplu, putem folosi Google Sheet sau Excel și să configurăm căutarea în interiorul fișierului. De ce anume acești furnizori? Pentru că ne bazăm pe paradigma că oricine din echipă trebuie să fie capabil să deschidă și să parcurgă un caz de test fără a necesita instalarea preliminară a diverselor unelte.
Pentru Google Sheet putem folosi interogări SQL. Exemplu:
=query(DATA!A1:M1146;"
SELECT C,D
WHERE
C contains '"&SEARCH!A2&"'" )Pentru Excel putem configura macrocomenzi convenabile pentru căutare rapidă. (filtrare) Exemplu .
Ideea, de fapt, nu este nouă și este descrisă în prima carte a testerului „Testarea dot com”. (autor Savin Roman) Noi integrăm doar în TestRail metodologiile propuse de Roman Savin. Pentru aceasta, vom crea un câmp cu un link către fișierul creat:
completăm valoarea implicită a linkului, astfel încât în fiecare caz de test nou să existe deja un link:
Dacă locația fișierului extern se va schimba (preconizăm orice forță majoră), atunci putem modifica convenabil în toate cazurile de test simultan unul sau mai multe câmpuri:
Câmpul „Descriptions” (descriere sau idee a cazului de test, instrucțiuni tipice)
Pentru ce poate fi necesar: În acest câmp text, vom introduce o descriere scurtă a cazului de test și instrucțiuni tipice.
Exemplu: Toate datele de test (modele actuale, utilizarea uneltelor și alte date) din acest caz de test sunt marcate cu linkuri {…} și se află în fișierul MovableData. Linkul către MovableData se află în câmpul corespunzător de sus.
Tagul „Component” (componenta aplicației mobile)
Pentru ce poate fi necesar: pentru testarea de impact. Dacă o aplicație mobilă poate fi împărțită în componente (care afectează cât mai puțin una pe cealaltă), atunci modificările într-o componentă vor fi suficiente (cu anumite riscuri) pentru a fi verificate în cadrul acelei componente, iar motivele pentru a efectua regresii generale vor fi reduse. Dacă există informații că o componentă poate afecta o altă componentă, se elaborează o matrice de testare de impact.
Exemple de componente: GooglePay, Order, Users, Map, Authorization etc.
Tag-ul „TAG” (Alte etichete pentru filtrare)
Etichetarea cazului de testare cu etichete pentru filtrare arbitrară.
Foarte util pentru:
compunerea rapidă a TestRun pentru diverse sarcini standard: smoke, regresie etc.
dacă testele vor fi automatizate sau sunt deja automatizate
orice alte etichete
Exemplu: Smoke, Automated, WhiteLabel, ForDelete etc.
Configurăm ordinea de afișare a câmpurilor în cazul de testare
Am creat multe câmpuri noi, acum este timpul să le organizăm într-o ordine convenabilă:
Crearea TestRun
Acum vom crea un nou test run cu cazurile actuale pentru a efectua testarea smoke în trei clicuri:
Alte sfaturi utile
Dacă în TestRail sunt mai multe proiecte, nu uitați să creați câmpuri noi doar pentru proiectul dvs., altfel colegii din echipele vecine vor fi foarte surprinși de apariția unor câmpuri noi neobișnuite. Pot apărea lesinuri locale.
2. Cazurile cu un număr mare de câmpuri sunt mai ușor de copiat dintr-un grup similar decât de a crea noi:
3. Puteți folosi conturi în comun. De exemplu: un cont de administrator, mai multe conturi de utilizator.
Concluzie
Exemplele de mai sus au fost implementate în mai multe proiecte și și-au demonstrat eficiența. Sper că vă vor ajuta să înțelegeți mai bine acest instrument și să creați „bănci de teste” eficiente și convenabile. Aș fi foarte recunoscător dacă ați descrie în comentarii experiența dvs. de utilizare a TestRail și sfaturi utile.
Linkuri:
Cartea:
Vă mulțumesc mult pentru atenție!
Sursa: habr.com
