how effectively prepare test bed
Testul de testare / Mediul de testare Configurarea provocărilor și cele mai bune practici:
În mai multe ocazii, testerii își găsesc defectele respinse din cauza problemelor de mediu sau se găsesc în mod constant să reproducă defectele din motive similare. În timp ce deschiderea celui mai mare număr de defecte trebuie să fie cu siguranță unul dintre reperele personale pentru fiecare tester, majoritatea testerilor trebuie să sublinieze, de asemenea, faptul că au cel mai mare număr de defecte valabile.
Cum se realizează acest lucru?
În afară de celelalte aspecte, cum ar fi planificarea unei varietăți de scenarii de testare și înțelegerea temeinică a elementului rând, a trebuie investit un timp bun în instalarea patului de testare sau a mediului de testare . În al doilea rând, în ciuda faptului că au o sumă estimată pentru planificarea cazurilor de testare, testerii trebuie, de asemenea concentrați-vă energiile crearea de date de testare eficiente .
Personal, fiind o parte a procesului de audit, am observat că cel mai mare număr de defecte valide se găsesc atunci când s-a investit o cantitate bună de efort în crearea patului de testare sau a mediului de testare într-o manieră corectă și atunci când testatorul are înțelegerea tipului de mediu necesar.
De asemenea, tipul de date de test furnizate mediului de testare poate expune unele defecte foarte grave în codul / caracteristica testată, care pot avea un impact grav asupra calității produsului.
Acest articol vorbește despre ceea ce presupune exact patul de testare: este un proces în doi pași de configurare a mediului de testare și de configurare a datelor de testare:
Partea 1) Partea anterioară a articolului va discuta despre proces general de configurare a mediului de testare , cel mai frecvent se confruntă cu probleme de configurare cu care se confruntă testele și indicatoarele pe care trebuie să le aveți în vedere în timp ce creați un pat de test în locul acestor provocări.
Partea 2) După ce am spus atât de multe lucruri cu privire la patul de testare în mod colectiv în acest articol, a meritat să aruncăm o lumină asupra Testarea întreținerii mediului aspecte, de asemenea. Ultima parte a articolului discută a doua parte a configurării patului de testare, care implică datele de testare, abordarea de configurare și unele eficiente Testarea tehnicilor de gestionare a datelor .
Cu un „big bang” constant în dezvoltarea și testarea software-ului, se concentrează din ce în ce mai mult pe adoptarea diverselor metodologii pentru a face procesul global de asigurare a calității transparent, eficient și adecvat.
Diferite audituri de calitate sunt efectuate între organizații pentru a se asigura că performanța echipei de testare poate fi evaluată în mod adecvat și are rezultate măsurabile cu indicatorii identificați la inițializarea ciclului de testare. Aceste rezultate permit identificarea locului în care se află o anumită echipă în ceea ce privește asigurarea unei calități optime pentru software-ul testat.
Aceste rapoarte ajută, de asemenea, echipa să înțeleagă oportunitățile de îmbunătățire pe baza observațiilor făcute în timpul auditului.
Inutil să menționăm, o valoare foarte evidentă pentru orice echipă de testare ar fi cu privire la numărul total de defecte deschise față de numărul de defecte valide . Prin urmare, una dintre întrebările care apar în mod evident este - Care este baza încercării de a descoperi orice defect? Într-un alt mod, care este baza pe care se poate găsi un defect?
Răspunsul este unanim - Test Bed and / or Test Environment setup. Există repere de calitate stabilite în cadrul echipelor la reduce defectele respinse ca o eroare de configurare de test / eroare de utilizator, configurații nevalide sau, în unele cazuri, defectele care apar ca evadări dintr-o anumită echipă din cauza configurațiilor indisponibile, configurațiilor netestate.
Să începem aruncând o privire mai atentă asupra definirii a ceea ce este un pat de testare sau un mediu de testare.
Ce veți învăța:
Ce este un pat de testare și un mediu de testare?
Într-un sens foarte generic, un pat de testare ar putea fi definit ca un fel de mediu de dezvoltare prin care implementatorii de coduri sau module au libertatea de a-și testa modulele fără nicio perturbare din partea echipei de testare, în spațiu de închidere absolut.
Cu toate acestea, un pat de testare nu este specific doar unei echipe de dezvoltare. Din perspectiva unei echipe de testare sau a unui tester, întrucât patul de testare nu este altceva decât o platformă identificată pentru testarea software-ului / produsului, acesta este, de asemenea, interschimbabil numit mediu de testare.
Orice pat de testare sau mediu de testare ar trebui configurat în conformitate cu obiectivul de testare identificat pentru aplicația / produsul / software-ul testat. În anumite situații, un pat de testare ar fi colectarea mediului de testare și a datelor de testare cu care operează.
Componentele unui mediu de testare
Orice test ar avea cerințele sale specifice de mediu de testare, dar într-un sens foarte larg, orice pat de testare / mediu de testare va cuprinde hardware-ul, software-ul și piesele de rețea pentru a susține configurația necesară la minimum pentru a conduce și a efectua testul particular .
Este un fapt bine cunoscut că o cantitate rezonabilă de timp al testerului este consumată de problemele de mediu, care la rândul lor afectează productivitatea și programele de testare. Deși tipul de provocări variază pentru fiecare echipă de testare, unele dintre ele pot fi comune.
Unele provocări cheie cu care se confruntă în mod obișnuit sunt:
# 1) Mediu la distanță
Activele sau mediile de testare sunt plasate în cea mai mare parte geografic în site-uri aflate la distanță de echipe. Aceasta este una dintre cele mai frecvente provocări cu care se confruntă echipele de testare, ca în cazul oricăror probleme care pot apărea legate de hardware, firmware, software, rețea etc.
Echipele care consumă activele ar trebui să se bazeze în mare măsură pe echipele de asistență din locația în care activele sunt prezente.
În aceleași rânduri, dacă un anumit activ are nevoie de o actualizare a firmware-ului sau de un upgrade de construire, din nou, echipa de testare poate avea nevoie de sprijinul echipelor de asistență care dețin mediul, deschizând bilete de asistență. Acest lucru poate, de asemenea, să acopere un timp considerabil de testare și să întârzie programele, mai ales în cazuri de diferențe de fus orar.
# 2) Utilizare combinată între echipe
Cel mai adesea, echipele de dezvoltare și test folosesc aceleași active de mediu. Deși norma generală definește că mediile de dezvoltare, testare și producție trebuie să fie separate, în realitate acest scenariu ideal este foarte rar atins. Devine extrem de neprietenos pentru organizații să achiziționeze resurse separate pentru fiecare echipă.
Prin urmare, majoritatea organizațiilor impun utilizarea comună a mediului între dezvoltare și testare. În plus, dacă resursele de dezvoltare și testare se luptă pentru utilizarea aceluiași activ în același timp, aceasta duce la haos și dezacorduri în cadrul membrilor.
# 3) Planificare ineficientă pentru utilizarea resurselor pentru integrare
În unele cazuri pentru scenarii care necesită un testare cap la cap prin care există o integrare a două sau mai multe componente pentru a funcționa împreună, din nou poate exista o cerință de a avea o utilizare comună a resurselor între echipele de testare. Planificarea ineficientă în ceea ce privește utilizarea este un factor important pentru ca mediul să devină instabil, pe lângă conflictele dintre echipe.
Efectul cel mai evident al acestui fapt este că o problemă care este observată pentru o anumită dată sau de două ori poate produce un comportament complet diferit în următoarele rulări pentru același scenariu. Dacă un defect este deja deschis pentru acest lucru, există șanse mari să nu fie acceptat de către dezvoltare ca un candidat valid pentru o remediere.
# 4) Configurare complexă a testului
Configurația patului de testare sau mediului de testare este uneori prea complexă. Acest lucru va pune mai multe provocări, deoarece echipa de testare va avea nevoie de abilitățile necesare pentru a înțelege configurațiile necesare. Uneori există o lipsă de baze de cunoștințe disponibile pentru ca testerul să poată veni cu configurația necesară.
În astfel de cazuri, testerii pot induce ei înșiși o eroare în patul de testare, configurându-l incorect. Acest lucru ar avea un impact semnificativ asupra cazului de testare și asupra rezultatelor pe care le produce.
# 5) Timp de configurare elaborat
În anumite alte perioade, pentru fiecare caz de testare, configurarea testului poate fi mult prea elaborată pentru fiecare caz de testare identificat. Acest lucru s-ar putea datora unei largi varietăți de tehnologii coexistente care trebuie să fie cuplate împreună sau mai multor componente pentru a lucra împreună în cazurile de testare a integrării.
În aceste cazuri, fiecare dintre componente trebuie să funcționeze perfect pentru a asigura rezultate consistente, deoarece o componentă poate forma o intrare la următoarea.
Cele mai bune practici pentru configurarea unui mediu de testare
Am aruncat o privire asupra schemei generale a provocărilor cu care se confruntă un tester înainte sau în timp ce începe executarea testului. Majoritatea dintre noi ne-am confruntat cu una sau mai multe dintre aceste probleme la un moment dat în etapele proiectului nostru. Aceste provocări au existat și vor continua să existe în diferite grade, deoarece o situație idealistă nu există.
Având în vedere că provocările de configurare fac parte integrantă din activitatea unui tester și sunt inevitabile, iată câteva sugestii despre cum să pregătiți în mod eficient setarea pentru testare. Acest lucru ar putea ajuta la minimizarea defectelor care pot apărea din cauza problemelor de configurare.
Sfatul nr. 1) Intelege Cerințe de testare temeinic și educați-vă
ce este testarea funcționalității cu exemplu
Începeți întotdeauna cu elementele de bază și cu cele mai evidente! Atunci când un document de specificații sau un document de caz de utilizare este lansat de echipa de dezvoltare, pasul invariabil pentru echipa de testare este să înțeleagă cerințele elementului rând și apoi să pregătească un document de caz de testare care să detalieze cazurile de testare.
În timp ce planificarea testului este efectuată, este cel mai bun practică de a include și informații detaliate despre mediul de testare în documentul cazului de testare. Nu se presupune că testerul va petrece timp analizând ce mediu de testare poate fi necesar și, în consecință, configurațiile necesare.
Acest lucru se poate realiza vorbind cu echipa de dezvoltare / arhitecți pentru a construi o bază de cunoștințe bună. Acest lucru nu numai că va economisi ceva timp în ciclul de execuție, ci va ajuta și un tester să își aloce timpul de execuție în mod eficient între testele simple și complexe.
Personal, un bun rezultat al acestui fapt este că mulți dintre noi au descoperit probleme de configurare (care ar împiedica în mod inerent executarea consecventă a testelor) chiar la începutul ciclului, ceea ce ne-a dat timp să canalizăm și să dobândim ajutorul necesar pentru a rezolva aceste probleme - astfel nu extinde ciclul de testare dincolo de perioade inacceptabile.
Un alt impact pozitiv pe care acesta îl va avea este că acest lucru ar îmbunătăți foarte mult cunoștințele echipei de testare și ar preveni defectele inutile. Deși această practică rezumă aproape toate practicile care sunt inerent necesare pentru a face față provocărilor de configurare a testelor menționate mai sus, merită totuși să faceți o mențiune despre celelalte sfaturi.
Sfatul nr. 2) Verificarea conectivității
Un alt punct de control cel mai important este să vă asigurați că resursele sau activele pe care intenționați să le utilizați pentru testare sunt accesibile. În cazul în care sistemul trebuie să ruleze integrat cu alte mașini, verificați conectivitatea între ele utilizând ping sau telnet.
De asemenea, dacă sistemele trebuie să interacționeze între ele și se află în spatele firewall-urilor, asigurați-vă că se pot autentifica prin aceste firewall-uri folosind Opțiuni de securitate de bază (BSO) și verificați și dacă există proxy-uri. În cazul în care observați că unele mașini nu sunt accesibile sau au nevoie de autentificare BSO, pot fi solicitate servicii adecvate pentru a îndeplini cerința către echipa de asistență.
Acest lucru este deosebit de util atunci când mediul se află în locații îndepărtate și va evita, de asemenea, escaladările cu privire la mașini și sisteme. În cazul în care echipa de testare necesită acces la orice resursă sau depozit, acest lucru ar ajuta la determinarea proactivă a aceluiași lucru.
Sfatul nr. 3)Verificarea rețelei și / sau stocării
Aceasta este aproape o extensie la sfatul anterior și ar avea nevoie de o altă verificare mai mare cu o adâncime tehnică mai mare. Asigurați-vă că testarea de care aveți nevoie are lățimea de bandă necesară și dacă testarea dvs. are nevoie de o conexiune la internet. De asemenea, asigurați-vă că găsiți o modalitate de a verifica dacă topologia rețelei dintre sisteme și resurse este corectă.
În al doilea rând, dacă obiectivul dvs. de testare implică nevoia de stocare, asigurați-vă că există stocare și conectivitate la rețea. În general, este responsabilitatea administratorului să aibă acest lucru în loc, însă este, de asemenea, o mare valoare adăugată să ai niște cunoștințe funcționale și funcționale.
Sfatul nr. 4) Verificați dacă sunt necesare hardware-ul și software-ul, licențele
De multe ori se întâmplă ca testerii să înceapă execuția pe sisteme fără a verifica hardware-ul și software-ul necesar care ar putea fi necesare. Drept urmare, de multe ori, un tester își dă seama aproape în timpul ciclului de testare că anumite funcționalități sunt disponibile numai pe un nivel superior de hardware sau software / firmware.
În acel moment, testerul va semnaliza un blocant în efortul său de testare, care consumă un timp considerabil de testare. Prin urmare, este o practică neprețuită să ai un punct de control pentru a nota nota hardware-ului și software-ului care sunt necesare anterior.
De multe ori poate exista timp de nefuncționare implicat în actualizarea hardware-ului / software-ului, care se reduce la toate Sfat 1 unde un tester trebuie să se implice în planificarea proactivă a hardware-ului. Unele dintre software-uri ar putea necesita licențe care pot necesita aprobări și acțiuni de la echipa juridică. Aceasta fiind o acțiune bazată pe proces, ar putea dura din nou câteva zile pentru a fi îndeplinită, ceea ce trebuie planificat.
Sfatul nr. 5)Browsere și versiuni
Testarea pe care o faceți trebuie să se reflecte ce va efectua un utilizator final . El ar putea testa pe un anumit browser cele mai recente versiuni ale tuturor browserelor. Prin urmare, este obligatoriu să identificați diferitele tipuri de browsere care ar fi utilizate pentru testare și să le instalați în propria dvs. configurare de testare locală.
În al doilea rând, identificați și ce versiuni de browsere trebuie utilizate pentru testare. O bună practică ar fi să începeți cu un browser cu versiunea inferioară, asigurând astfel compatibilitatea cu versiunile anterioare și apoi să faceți upgrade la cea mai recentă versiune.
Sfatul nr. 6)Planificarea utilizării mediului de testare.
Având în vedere faptul că echipa de testare nu va avea niciodată situația de a avea propriile resurse de testare, sisteme și active - este una dintre etapele majore în planificarea testării de a avea o utilizare eficientă a resurselor de testare.
cum se scrie un plan de testare
Acest lucru este necesar în special atunci când mai multe echipe trebuie să acceseze același set de resurse, fie din cauza unui scenariu de capăt la capăt care cuprinde două sau mai multe componente care lucrează împreună, fie a unei situații în care configurarea testului este prea elaborată sau complexă pentru a fi reprodusă. foarte ușor și ar putea exista mai mulți membri în cadrul aceleiași echipe care își au propriile obiective de testare cu aceeași configurare.
O bună practică ar fi elaborarea unei abordări de partajare a timpului prin care o anumită echipă sau persoană o utilizează pentru prima jumătate și restul de oameni pentru a doua jumătate. Poate exista o perioadă între care va fi obișnuit, în care fiecare dintre ei poate rula teste independente care nu îl vor împiedica pe celălalt.
Acest lucru nu numai că va reduce haosul și conflictele din interiorul membrilor, ci va asigura și stabilitatea comportamentală a mediului pe o durată mai lungă.
Sfatul nr. 7)Instrumente de automatizare și configurațiile acestora
După cum știm, fiecare element rând din testare va avea câteva teste repetitive care vor face parte din ciclul de regresie care va trebui automatizat. Echipa de testare trebuie să identifice ce fel de automatizare ar dori să facă și instrumentele necesare pentru aceasta.
Deși acest lucru necesar nu trebuie să facă parte din pregătirea mediului, aș înscrie în continuare acest lucru ca fiind cea mai bună practică pentru ca instrumentele de automatizare să fie identificate și configurate corespunzător. Acest lucru ar depinde complet de discreția testerului atunci când dorește să efectueze această activitate, deoarece acesta nu este un factor obligatoriu pentru a asigura pregătirea testului.
Concluzie
Aceste sfaturi și trucuri pot forma un indicator și o amprentă bună pentru a asigura disponibilitatea mediului de testare pentru testare. Fără îndoială, fiecare echipă se confruntă cu propriul set unic de provocări și sfaturile de mai sus pot fi adaptate și personalizate pentru a se potrivi propriilor nevoi.
De fapt, sursa pentru evidențierea acestui întreg schelet de sfaturi provine dintr-una din sarcinile mele în care m-am confruntat cu probleme de configurare foarte complexe și mi-a luat aproape un an să încep testarea!
Deși limitările din mediul de testare erau în afara controlului meu, am simțit că multe dintre aceste probleme ar fi putut fi raportate mai devreme dacă aș fi aplicat aceste sfaturi. Am aplicat-o pentru fiecare sarcină care îmi vine de atunci și acest schelet m-a ajutat foarte mult în găsirea pro-activă a problemelor de configurare și canalizarea eforturilor mele pentru a le rezolva.
Despre autor: Acest articol este scris de Sneha Nadig. Lucrează ca șef de testare cu peste 7 ani de experiență în proiecte de testare manuală și de automatizare.
În partea 2 a acestui articol, vom vedea procesul de configurare și întreținere a mediului de testare și sfaturi de pregătire și gestionare a datelor de testare. Între timp, nu ezitați să postați în comentarii întrebările dvs. privind pregătirea patului de testare
Lectură recomandată
- Cum să efectuați testarea post-lansare eficient și să minimizați impactul lansării pentru clienții live
- Cum decideți ce defecte sunt acceptabile pentru ca software-ul să fie difuzat?
- Cum să pregătiți și să furnizați o prezentare remarcabilă de testare a calității echipei
- Procesul de gestionare a defectelor: Cum să gestionați eficient un defect
- Cele mai bune 9 idei pentru testeri pentru a-și utiliza timpul în bancă eficient
- Leadership în testare - Responsabilitățile conducătorilor de testare și modul de gestionare eficientă a echipei de testare
- Cum să planificați și să gestionați eficient proiectele de testare (sfaturi)
- Procesul de triere a defectelor și modalitățile de gestionare a întâlnirii de triere a defectelor