Ce este testul de acceptare a utilizatorului (UAT): un ghid complet

what is user acceptance testing

Aflați ce este testul de acceptare a utilizatorilor (UAT), împreună cu definiția, tipurile, pașii și exemplele sale:

Regula mea numărul unu când încerc să înțeleg un nou concept este că: numele va fi întotdeauna relevant și mai ales un sens literal (în context tehnic).

Aflarea a ceea ce este, va oferi o înțelegere inițială a acestuia și mă va ajuta să încep cu.

căști de realitate virtuală pentru Xbox One

=> Faceți clic aici pentru seria completă de programe de testare

Să punem la încercare acest concept.

=> Citiți toate tutorialele în seria noastră de testare a acceptării.

Ce veți învăța:

• Ce este testarea acceptării utilizatorilor?
  • Când se efectuează?
  • Cine efectuează UAT?
  • Necesitatea testării acceptării utilizatorilor
  • Procesul de testare a acceptării utilizatorului
  • Guvernarea UAT
  • Planificarea testului UAT
  • Proiectare testare acceptare utilizator
  • Executarea testului
  • Instrumente și metodologii
  • UAT în mediu agil
  • Echipa UAT - Roluri și responsabilități
• 7 Provocări ale UAT și ale planului de atenuare
• Testarea sistemului vs. Testarea acceptării utilizatorului
• Concluzie
  • Lectură recomandată

Ce este testarea acceptării utilizatorilor?

Știm ce este testarea, acceptarea înseamnă aprobare sau acord. Utilizatorul în contextul unui produs software este fie consumatorul software-ului, fie persoana care a solicitat să fie construit pentru el (client).

Deci, urmând regula mea - definiția va fi:

Testarea acceptării utilizatorului (UAT), cunoscută și sub numele de testare beta sau utilizator final, este definită ca testarea software-ului de către utilizator sau client pentru a determina dacă acesta poate fi acceptat sau nu. Aceasta este testarea finală efectuată după finalizarea testării funcționale, a sistemului și a regresiei.

Scopul principal al acestei testări este validarea software-ului în funcție de cerințele afacerii. Această validare este efectuată de utilizatorii finali care sunt familiarizați cu cerințele companiei.

UAT, testarea alfa și beta sunt diferite tipuri de teste de acceptare.

Întrucât testul de acceptare a utilizatorului este ultimul test care se efectuează înainte ca software-ul să intre în funcțiune, evident, aceasta este ultima șansă pentru client de a testa software-ul și de a măsura dacă este potrivit pentru acest scop.

Când se efectuează?

Acesta este de obicei ultimul pas înainte ca produsul să devină activ sau înainte ca livrarea produsului să fie acceptată. Acest lucru se realizează după ce produsul însuși este testat temeinic (de exemplu, după testarea sistemului ).

Cine efectuează UAT?

Utilizatori sau client - Acesta poate fi fie cineva care cumpără un produs (în cazul unui software comercial), fie cineva care a avut un software personalizat prin intermediul unui furnizor de servicii software sau al utilizatorului final dacă software-ul este pus la dispoziția lor înainte de timp și când se caută feedback-ul lor.

Echipa poate fi formată din beta testeri sau clientul ar trebui să selecteze membri UAT intern din fiecare grup al organizației, astfel încât fiecare rol de utilizator să poată fi testat în consecință.

Necesitatea testării acceptării utilizatorilor

Dezvoltatorii și testerii funcționali sunt persoane tehnice care validează software-ul în funcție de specificații funcționale . Ei interpretează cerințele în funcție de cunoștințele lor și dezvoltă / testează software-ul (aici este importanța cunoașterii domeniului).

Acest software este complet în conformitate cu specificațiile funcționale, dar există unele cerințe de afaceri și procesele care sunt cunoscute doar de utilizatorii finali, fie nu sunt comunicate, fie sunt interpretate greșit.

Această testare joacă un rol important în validarea dacă toate cerințele de afaceri sunt îndeplinite sau nu înainte de a lansa software-ul pentru utilizare pe piață. Utilizarea datelor live și a cazurilor reale de utilizare fac din această testare o parte importantă a ciclului de lansare.

Multe companii care au suferit pierderi mari din cauza problemelor post-lansare cunosc importanța unui test de acceptare a utilizatorului de succes. Costul remedierii defectelor după eliberare este de multe ori mai mare decât remedierea acestuia înainte.

Este UAT cu adevărat necesar?

După efectuarea unor sarcini de sistem, integrare și testare de regresie, ne-am întreba de necesitatea acestui test. De fapt, aceasta este cea mai importantă fază a proiectului, întrucât acesta este momentul în care utilizatorii care urmează să folosească sistemul ar valida sistemul pentru a se potrivi scopului său.

UAT este o fază de testare care depinde în mare măsură de perspectiva utilizatorilor finali și de cunoștințele de domeniu ale unui departament care reprezintă utilizatorii finali.

De fapt, ar fi cu adevărat de ajutor echipelor de afaceri, dacă ar fi implicate în proiect destul de devreme, astfel încât să își poată oferi opiniile și contribuțiile care ar ajuta la utilizarea eficientă a sistemului în lumea reală.

Procesul de testare a acceptării utilizatorului

Cel mai simplu mod de a înțelege acest proces este să vă gândiți la acesta ca la un proiect de testare autonom - ceea ce înseamnă că va avea planul, proiectarea și fazele de execuție.

Următoarele sunt condițiile preliminare înainte de începerea fazei de planificare:

# 1) Adunați criteriile cheie de acceptare

În termeni simpli, criteriile de acceptare sunt o listă de lucruri care urmează să fie evaluate înainte de a accepta produsul.

Acestea ar putea fi de 2 tipuri:

(i) Funcționalitatea aplicației sau legată de afaceri

În mod ideal, toate funcționalitățile cheie ale afacerii ar trebui să fie validate, dar din diverse motive, inclusiv timp, nu este practic să le faci pe toate. Prin urmare, o întâlnire sau două cu clientul sau utilizatorii care urmează să fie implicați în această testare ne pot oferi o idee despre cât de mult va fi implicat testarea și ce aspecte vor fi testate.

(ii) Contractuale - Nu vom analiza acest lucru și implicarea echipei QA în toate acestea nu este aproape nimic. Contractul inițial care se întocmește chiar înainte de începerea SDLC este revizuit și se ajunge la un acord cu privire la faptul dacă toate aspectele contractului au fost livrate sau nu.

Ne vom concentra doar pe funcționalitatea aplicației.

# 2) Definiți sfera implicării QA.

Rolul echipei de asigurare a calității este unul dintre următoarele:

(i) Fără implicare - Acest lucru este foarte rar.

(ii) Asistați la această testare - Cel mai comun. În acest caz, implicarea noastră ar putea fi formarea utilizatorilor UAT despre cum să utilizeze aplicația și să fie în standby în timpul acestei testări pentru a ne asigura că putem ajuta utilizatorii în cazul oricărei dificultăți. Sau, în unele cazuri, pe lângă faptul că suntem în așteptare și asistăm, am putea să împărtășim răspunsurile lor și să înregistrăm rezultatele sau să înregistrăm erori etc., în timp ce utilizatorii efectuează testarea efectivă.

(iii) Efectuați UAT și prezentați rezultatele - Dacă acesta este cazul, utilizatorii vor indica zonele AUT pe care doresc să le evalueze, iar evaluarea însăși este efectuată de echipa QA. Odată terminate, rezultatele sunt prezentate clienților / utilizatorilor și aceștia vor lua o decizie dacă rezultatele pe care le au în mână sunt suficiente sau nu și în conformitate cu așteptările lor pentru a accepta AUT. Decizia nu este niciodată cea a echipei QA.

În funcție de caz, decidem ce abordare este cea mai bună.

Principalele obiective și așteptări:

De obicei, UAT este realizat de un expert în materie (IMM) și / sau un utilizator de afaceri, care ar putea fi proprietarul sau clientul unui sistem supus testării. Similar cu faza de testare a sistemului, faza UAT cuprinde și faze religioase înainte de a fi închise.

Activitățile cheie ale fiecărei faze UAT sunt definite mai jos:

Guvernarea UAT

Similar testării sistemului, guvernanța eficientă este impusă pentru UAT pentru a se asigura că porțile de calitate puternică, împreună cu criteriile de intrare și ieșire definite (furnizate mai jos **).

** Vă rugăm să rețineți că este doar o orientare. Acest lucru ar putea fi modificat pe baza nevoilor și cerințelor proiectului.

Planificarea testului UAT

Procesul este aproape la fel ca în cazul plan regulat de testare în faza de sistem.

Cea mai comună abordare urmată în majoritatea proiectelor este de a planifica atât faza de testare a sistemului, cât și faza de testare UAT împreună. Pentru mai multe informații despre planul de test UAT împreună cu un eșantion, vă rugăm să consultați secțiunile UAT din documentul planului de test atașat.

Planul de testare a acceptării utilizatorilor

(Acesta este același lucru pe care l-ați găsi pe site-ul nostru și pentru seria de instruire QA).

Faceți clic pe imaginea de mai jos și derulați în jos pentru a găsi exemplul de document al planului de testare în diferite formate. În acel șablon verificați secțiunea UAT.

Datele, mediul, actorii (care), protocoalele de comunicare, rolurile și responsabilitățile, șabloanele, rezultatele și procesul lor de analiză, criteriile de intrare-ieșire - toate acestea și orice altceva relevant este găsit în planul de testare UAT.

Indiferent dacă echipa QA participă, participă parțial sau nu participă deloc la acest test, este treaba noastră să planificăm această fază și să ne asigurăm că totul este luat în considerare.

=> Iată un exemplu de document de testare a planului de acceptare a utilizatorului

Proiectare testare acceptare utilizator

Criteriile de acceptare colectate de la utilizatori sunt utilizate în acest pas. Probele ar putea arăta așa cum se arată mai jos.

(Acestea sunt extrase din CSTE CBOK . Aceasta este una dintre cele mai bune referințe disponibile despre această testare.)

Șablon de testare a acceptării utilizatorului:

Pe baza criteriilor, noi (echipa QA) le oferim utilizatorilor o listă a cazurilor de testare UAT. Aceste cazuri de testare nu diferă de cazurile noastre de testare obișnuite ale sistemului. Acestea sunt doar un subset, pe măsură ce testăm toate aplicațiile spre deosebire de domeniile funcționale cheie.

În plus față de acestea, datele, șabloanele pentru înregistrarea rezultatelor testelor, procedurile administrative, mecanismul de înregistrare a defectelor etc. trebuie să fie la locul lor înainte de a trece la faza următoare.

Executarea testului

De obicei, atunci când este posibil, această testare are loc într-o conferință sau într-o cameră de război, într-un fel în care utilizatorii, reprezentanții echipei PM, ai echipei QA stau împreună pentru o zi sau două și lucrează prin toate cazurile de testare a acceptării.

Sau în cazul în care echipa QA efectuează testele, rulăm cazurile de testare pe AUT.

Odată ce toate testele sunt executate și rezultatele sunt la îndemână, Decizie de acceptare se face. Aceasta se numește și Decizie Go / No-Go . Dacă utilizatorii sunt mulțumiți, este un Go, sau altfel este un No-go.

A ajunge la decizia de acceptare este de obicei sfârșitul acestei faze.

Instrumente și metodologii

De obicei, tipul de instrumente software care sunt utilizate în timpul acestei faze de testare este similar cu instrumentele utilizate în timpul efectuării testării funcționale.

Instrumente:

Deoarece această fază implică validarea fluxurilor complete de la capăt la capăt ale aplicației, ar putea fi dificil să existe un instrument care să automatizeze complet această validare. Cu toate acestea, într-o oarecare măsură, vom fi capabili să folosim scripturile automatizate dezvoltate în timpul testării sistemului.

Similar testării sistemului, utilizatorii ar folosi, de asemenea, instrumentele de gestionare a testelor și de gestionare a defectelor, cum ar fi QC, JIRA, etc. Aceste instrumente pot fi configurate pentru a cumula date pentru faza de acceptare a utilizatorului.

Metodologii:

Deși metodologiile convenționale, cum ar fi utilizatorii de afaceri specifici care efectuează UAT al produsului, sunt încă relevante, într-o lume cu adevărat globală ca astăzi, testarea acceptării utilizatorilor trebuie uneori să implice clienți variați din țări în funcție de produs.

De exemplu, un site de comerț electronic ar fi utilizat de clienții din întreaga lume. În astfel de scenarii, testarea mulțimii ar fi cea mai bună opțiune viabilă.

Testarea mulțimii este o metodologie în care oameni din întreaga lume pot participa și valida utilizarea produsului și pot oferi sugestii și recomandări.

Platformele de testare a mulțimii sunt construite și sunt utilizate acum de multe organizații. Un site web sau un produs care trebuie testat în mulțime este găzduit în platformă, iar clienții se pot nominaliza pentru a face validarea. Feedback-urile furnizate sunt apoi analizate și prioritizate.

Metodologia de testare a mulțimii se dovedește a fi mai eficientă, deoarece pulsul clientului din întreaga lume poate fi ușor de înțeles.

UAT în mediu agil

Mediul agil are o natură mai dinamică. Într-o lume agilă, utilizatorii de afaceri vor fi implicați pe tot parcursul sprinturilor proiectului și proiectul va fi îmbunătățit pe baza buclelor de feedback de la aceștia.

La începutul proiectului, utilizatorii de afaceri ar fi părțile interesate cheie care vor furniza cerințe, actualizând astfel restanța produselor. La sfârșitul fiecărui sprint, utilizatorii de afaceri ar participa la demo-ul sprint și ar fi disponibili pentru a oferi feedback.

întrebări de interviuri de testare a performanței pentru experți

Mai mult, o fază UAT ar fi planificată înainte de finalizarea sprintului în care utilizatorii de afaceri își vor face validările.

Feedback-urile primite în timpul demo-ului sprint și sprint UAT sunt colectate și adăugate înapoi în backlog-ul produsului, care este constant revizuit și prioritizat. Astfel, într-o lume agilă, utilizatorii de afaceri sunt mai apropiați de proiect și evaluează același lucru pentru utilizarea acestuia mai des, spre deosebire de proiectele tradiționale de cascadă.

Echipa UAT - Roluri și responsabilități

O organizație tipică UAT ar avea următoarele roluri și responsabilități. Echipa UAT ar fi susținută de managerul de proiect, echipele de dezvoltare și testare pe baza nevoilor acestora.

7 Provocări ale UAT și ale planului de atenuare

Nu contează dacă faceți parte dintr-o versiune de miliarde de dolari sau o echipă de startup, ar trebui să depășiți toate aceste provocări pentru furnizarea de software de succes pentru utilizatorul final.

# 1) Configurarea mediului și procesul de implementare:

Efectuarea acestui test în același mediu utilizat de echipa de testare funcțională va sfârși cu siguranță cu vederea cazurilor de utilizare din lumea reală. De asemenea, activitățile de testare cruciale, cum ar fi testarea performanței, nu pot fi efectuate pe un mediu de testare incomplet date de testare .

Pentru acest test ar trebui să fie creat un mediu separat de producție.

Odată ce mediul UAT este separat de mediul de testare, trebuie să controlați eficient ciclul de eliberare. Ciclul de eliberare necontrolată poate duce la diferite versiuni de software în mediul de testare și UAT. Timpul valoros al testului de acceptare este irosit când software-ul nu este testat pe cea mai recentă versiune.

Între timp, timpul necesar pentru urmărirea problemelor în versiunea incorectă a software-ului este mare.

# 2) Planificarea testului:

Această testare ar trebui să fie planificată cu un plan de testare de acceptare clar în faza de analiză a cerințelor și de proiectare.

În planificarea strategiei, setul de cazuri de utilizare din lumea reală ar trebui identificat pentru executare. Este foarte important să definiți obiectivele testului pentru această testare, deoarece nu este posibilă executarea completă a testului pentru aplicații mari în această fază de testare. Testarea ar trebui efectuată prin prioritizarea obiectivelor critice ale afacerii.

Această testare se efectuează la sfârșitul ciclului de testare. Evident, este perioada cea mai critică pentru lansarea software-ului. Întârzierea în oricare dintre etapele anterioare de dezvoltare și testare va consuma timpul UAT.

Planificarea incorectă a testelor, în cele mai grave cazuri, duce la o suprapunere între testarea sistemului și UAT. Datorită timpului și presiunii mai mici pentru a respecta termenele limită, software-ul este implementat în acest mediu chiar dacă testarea funcțională nu este finalizată. Scopurile principale ale acestei testări nu pot fi atinse în astfel de situații.

Planul de testare UAT trebuie pregătit și comunicat echipei cu mult înainte de a începe acest test. Acest lucru îi va ajuta pentru planificarea testelor, scrierea de cazuri de testare și scripturi de testare și crearea unui mediu UAT.

# 3) Gestionarea noilor cerințe comerciale ca incidente / defecte:

Ambiguitățile în cerințe sunt surprinse în faza UAT. Testerii UAT găsesc probleme apărute din cauza cerințelor ambigue (examinând interfața completă care nu era disponibilă în timpul fazei de colectare a cerințelor) și o înregistrează ca defect.

Clientul se așteaptă ca acestea să fie remediate în versiunea curentă fără a lua în considerare timpul pentru solicitările de modificare. Dacă conducerea proiectului nu ia o decizie în timp util cu privire la aceste modificări de ultim moment, atunci aceasta ar putea duce la eșecul lansării.

# 4) Testeri necalificați sau testeri fără cunoștințe de afaceri:

întrebări și răspunsuri la interviuri de tip shell scripting

Atunci când nu există o echipă permanentă, compania selectează personal UAT din diferite departamente interne.

Chiar dacă personalul este bine familiarizat cu nevoile afacerii sau dacă nu este instruit pentru noile cerințe care sunt dezvoltate, nu pot efectua UAT eficace. De asemenea, o echipă de afaceri non-tehnică s-ar putea confrunta cu multe dificultăți tehnice în executarea cazurilor de testare.

Între timp, atribuirea testerelor la sfârșitul ciclului UAT nu adaugă nici o valoare proiectului. Putin timp pentru a instrui personalul UAT poate crește semnificativ șansele de succes UAT.

# 5) Canal de comunicare necorespunzător:

Comunicarea dintre dezvoltarea la distanță, testarea și echipa UAT este mai dificilă. Comunicarea prin e-mail este adesea foarte dificilă atunci când aveți o echipă de tehnologie offshore. O mică ambiguitate în rapoartele de incidente poate întârzia remedierea acesteia cu o zi.

Planificarea corectă și comunicarea eficientă sunt esențiale pentru o colaborare eficientă a echipei. Echipele de proiect ar trebui să utilizeze un instrument bazat pe web pentru a înregistra defecte și întrebări. Acest lucru va ajuta la distribuirea uniformă a volumului de muncă și la evitarea raportării problemelor duplicate.

# 6) Solicitând echipei de testare funcțională să efectueze această testare:

Nu există o situație mai gravă decât cererea echipei de testare funcțională să efectueze UAT.

Clienții își descarcă responsabilitatea către echipa de testare din cauza lipsei de resurse. Întregul scop al acestei testări este compromis în astfel de cazuri. Odată ce software-ul devine live, utilizatorii finali vor identifica rapid problemele care nu sunt considerate scenarii din lumea reală de către testerii funcționali.

O soluție la acest lucru este de a atribui acest test testerilor dedicați și calificați care au cunoștințe de afaceri.

# 7) Jocul Blame

Uneori, utilizatorii de afaceri încearcă doar să găsească motive pentru a respinge software-ul. S-ar putea să fie propria lor autonomie să arate cât de superiori sunt sau să dea vina pe echipa de dezvoltare și testare pentru a obține respect în echipa de afaceri. Acest lucru este foarte rar, dar se întâmplă în echipe cu politică internă.

Este foarte dificil să te descurci cu astfel de situații. Cu toate acestea, construirea unei relații pozitive cu echipa de afaceri ar contribui cu siguranță la evitarea jocului de vina.

Sper că aceste linii directoare vă vor ajuta cu siguranță să executați un plan de acceptare a utilizatorilor de succes, depășind diverse provocări. Planificarea corectă, comunicarea, execuția și echipa motivată sunt cheile pentru testarea cu succes a acceptării utilizatorilor.

Testarea sistemului vs. Testarea acceptării utilizatorului

Implicarea echipei de testare începe destul de devreme în proiect încă din faza de analiză a cerințelor.

Pe tot parcursul ciclului de viață al proiectului, se realizează un fel de validare pentru proiect, adică Testarea statică , Testarea unității, testarea sistemului, testarea integrării, testarea cap la cap sau testarea de regresie. Acest lucru ne lasă să înțelegem mai bine despre testele efectuate în faza UAT și cât de diferit este de celelalte teste efectuate anterior.

Deși observăm diferențele în SIT și UAT, este important să valorificăm sinergiile, dar să menținem totuși independența între ambele faze, care ar permite un timp mai rapid de comercializare.

Concluzie

# 1) UAT nu se referă la pagini, câmpuri sau butoane. Subiacentul presupunere chiar înainte de începerea acestui test este faptul că toate acele lucruri de bază sunt testate și funcționează bine. Doamne ferește, utilizatorii găsesc un bug la fel de simplu ca acesta - este o veste foarte proastă pentru echipa QA. :(

#Două) Această testare se referă la entitatea care este elementul principal în afaceri.

Permiteți-mi să vă dau un exemplu: Dacă AUT este un sistem de ticketing, UAT nu va fi vorba, căutând meniul care deschide o pagină etc. Este vorba despre bilete și rezervarea lor, despre stările pe care le poate lua, călătoria sa prin sistem, etc.

O alta Exemplu, dacă site-ul este un site de reprezentanță auto, atunci accentul se pune pe „mașină și vânzările sale” și nu chiar pe site. Prin urmare, activitatea de bază este ceea ce este verificat și validat și cine este mai bine să o facă decât proprietarii de afaceri. De aceea, acest test are cel mai mult sens atunci când clientul este implicat într-o măsură majoră.

# 3) UAT este, de asemenea, o formă de testare la bază, ceea ce înseamnă că există șanse mari să identificăm unele bug-uri și în această fază . Uneori se întâmplă. În afară de faptul că este o escaladare majoră pentru echipa QA, bug-urile UAT înseamnă, de obicei, o întâlnire pentru a sta și a discuta despre cum să le gestionăm, deoarece în urma acestei testări nu există de obicei timp pentru a remedia și a testa din nou.

Decizia ar fi fie:

• Apăsați data intrării în funcțiune, remediați mai întâi problema și apoi continuați.
• Lăsați bug-ul așa cum este.
• Luați în considerare aceasta ca parte a cererii de modificare pentru versiunile viitoare.

# 4) UAT este clasificat ca testare Alpha și Beta, dar această clasificare nu este atât de importantă în contextul proiectelor tipice de dezvoltare software într-o industrie bazată pe servicii.

• Testarea alfa este atunci când UAT se desfășoară în mediul constructorului de software și este mai semnificativ în contextul software-ului comercial comercial.
• Testarea beta este atunci când UAT se desfășoară în mediul de producție sau în mediul clientului. Acest lucru este mai frecvent pentru aplicațiile orientate către clienți. Utilizatorii de aici sunt clienții reali ca tine și ca mine în acest context.

# 5) De cele mai multe ori, într-un proiect regulat de dezvoltare software, UAT se desfășoară în Mediul QA dacă nu există niciun stadiu sau mediu UAT.

Pe scurt, cel mai bun mod de a afla dacă produsul dvs. este acceptabil și adecvat scopului este să îl puneți în fața utilizatorilor.

Organizațiile intră în modul agil de livrare, utilizatorii de afaceri se implică mai mult și proiectele sunt îmbunătățite și livrate prin bucle de feedback. Făcând toate acestea, faza de acceptare a utilizatorului este considerată poarta de intrare în implementare și producție.

Care a fost experiența dvs. UAT? Ai fost în standby sau ai testat pentru utilizatorii tăi? Utilizatorii au găsit probleme? Dacă da, cum te-ai descurcat cu ei?

=> De asemenea, citiți TOATE tutorialele din această serie aici

=> Vizitați aici pentru seria completă de programe de testare

Lectură recomandată

• Testarea alfa și testarea beta (un ghid complet)
• Ce este testarea acceptării (Un ghid complet)
• Test de verificare a construcției (testare BVT) Ghid complet
• Testarea funcțională Vs testarea nefuncțională
• Cele mai bune instrumente de testare software 2021 (Instrumente de automatizare a testelor de calitate)
• Tipuri de testare software: diferite tipuri de testare cu detalii
• Tutorial de testare a depozitului de date ETL (ghid complet)
• Tutorial de testare GUI: un ghid complet de testare a interfeței de utilizator (UI)