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

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

Regula mea numărul unu atunci când încerc să înțeleg un concept nou este aceea că: numele va fi întotdeauna relevant și în principal 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.

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

Să punem la încercare acest concept.

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

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 :

Testul de acceptare a 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 companiei. Această validare este efectuată de utilizatorii finali care sunt familiarizați cu cerințele companiei.

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

Deoarece testul de acceptare a utilizatorului este ultimul test care se efectuează înainte ca software-ul să devină activ, evident acesta este ultima șansă pentru client de a testa software-ul și de a măsura dacă acesta este potrivit scopului respectiv.

Când se realizează?

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 (adică după testarea sistemului).

Cine efectuează UAT?

Utilizatori sau client – Acesta poate fi fie cineva care cumpără un produs ( în cazul software-ului comercial) sau 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 atunci când se solicită feedback-ul lor.

Echipa poate fi formată din testeri beta 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 corespunzător.

Necesitatea testării acceptării utilizatorilor

Dezvoltatorii și testerii funcționali sunt persoane tehnice care validează software-ul în funcție de specificațiile 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 conform specificațiilor funcționale, dar există unele cerințe și procese de afaceri care sunt cunoscute doar utilizatorilor finali, fie le este lipsit de comunicare, fie este interpretat greșit.

Această testare joacă un rol important în validarea dacă toate cerințele comerciale sunt îndeplinite sau nu înainte de a lansa software-ul pentru utilizare pe piață. Utilizarea datelor live și a cazurilor de utilizare reală 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 de remediere a defectelor după eliberare este de multe ori mai mare decât remedierea acestuia înainte.

Este UAT cu adevărat necesar?

După efectuarea încărcărilor de sistem, testarea integrării și regresiei ne-am întreba despre necesitatea acestei testări. De fapt, aceasta este cea mai importantă fază a proiectului, deoarece acesta este momentul în care utilizatorii care vor folosi sistemul ar valida sistemul pentru a se potrivi cu scopul său.

UAT este un test fază 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ă au fost implicați î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 utilizatorilor

cel mai simplu mod de a înțelege acest proces este să vă gândiți la acest lucru 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 prealabile înainte de faza de planificare. începe:

# 1) Adunați criteriile cheie de acceptare

În termeni simpli, criteriile de acceptare sunt o listă ng-uri care vor fi 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 companiei ar trebui să fie validate, dar datorită din diverse motive, inclusiv timpul, 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) Contractual – Nu vom analiza acest lucru, iar implicarea echipei QA în toate acestea nu este aproape nimic. Contractul inițial întocmit 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) Asistență la acest test – Majoritatea uzual. Î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 Rezultate prezente – Dacă acesta este cazul, utilizatorii vor indica zonele AUT pe care doresc să le evalueze, iar evaluarea în sine este realizată 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ă.

Obiectivele și așteptările principale:

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 ca aceasta să fie închisă.

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 îndrumare. Acest lucru ar putea fi modificat în funcție de necesitățile și cerințele proiectului.

Planificarea testului UAT

Procesul este aproape același cu planul de testare regulat în faza de sistem.

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

Planul de testare a acceptării utilizatorilor

(Acesta este același lucru pe care l-ați face găsiți și pe site-ul nostru 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 (cine), protocoalele de comunicare, rolurile și responsabilitățile, șabloanele, rezultatele și procesul lor de analiză, criteriile de intrare-ieșire – toate acest lucru și orice altceva care este relevant vor fi găsite în planul de testare UAT.

Fie că echipa QA participă, participă parțial sau nu participă deloc la acest test, este de datoria noastră să planificăm această fază și asigurați-vă că totul este luat în considerare.

= > Iată un exemplu de document de eșantionare a planului de testare a acceptării utilizatorilor

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 acest test.)

Ș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, deoarece testăm toate aplicațiile spre deosebire de domeniile funcționale cheie.

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

Executarea testului

De obicei, atunci când este posibil, acest test are loc într-o conferință sau într-o cameră de război stabiliți acolo unde utilizatorii, PM, reprezentanții echipei QA stau toți împreună pentru o zi sau două și lucrează la toate cazurile de testare de acceptare.

Sau în cazul în care echipa QA efectuează testele, executăm testul cazuri pe AUT.

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

Atingerea deciziei de acceptare este de obicei sfârșitul acestei faze.

Instrumente & Metodologii

De obicei, tipul de instrumente software 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ă aveți un instrument care să automatizeze complet această validare. Cu toate acestea, într-o oarecare măsură, vom putea să folosim scripturile automatizate dezvoltate în timpul testării sistemului.

Similar testării sistemului, utilizatorii ar folosi, de asemenea, managementul testelor și instrumentele de gestionare a defectelor, cum ar fi QC, JIRA etc. instrumentele 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-un mediu cu adevărat global La fel ca astăzi, testarea acceptării utilizatorilor trebuie să implice uneori 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 pot 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 clienților din întreaga lume poate fi ușor de înțeles.

UAT In Agile Environment

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 pentru furnizați cerințe, actualizând astfel restanța produsului. La sfârșitul fiecărui sprint, utilizatorii de afaceri ar participa la demonstrația de sprint și ar fi disponibili pentru a oferi orice feedback.

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

Feedback-urile primite în timpul demo 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 & 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 Plan 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 a furniza software de succes pentru utilizatorul final.

# 1) Procesul de configurare și implementare a mediului:

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 esențiale, cum ar fi testarea performanței, nu pot fi realizate pe un mediu de testare cu date de testare incomplete.

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 ridicat.

# 2) Test Planificare:

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

În planificarea strategiei, ar trebui identificat setul de cazuri de utilizare din lumea reală. 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 de afaceri critice.

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 necorespunzătoare 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ă. Obiectivele de bază ale acestei testări nu pot fi atinse în astfel de situații.

Planul de testare UAT ar trebui pregătit și comunicat echipei cu mult înainte de a începe acest test. Acest lucru îi va ajuta pentru planificarea testelor, scrierea unor cazuri de testare & 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ă oră, atunci aceasta ar putea duce la eșecul lansării.

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

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 sunt instruiți pentru noile cerințe care sunt fiind dezvoltate, nu pot efectua UAT eficient. 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. Timpul redus pentru instruirea personalului UAT poate crește semnificativ șansele de succes al 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 pentru 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 solicitarea testului funcțional. echipa pentru a efectua UAT.

Clienții își descarcă responsabilitatea echipei 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 să atribuiți acest test celor dedicați și calificați. testeri care au cunoștințe de afaceri.

# 7) Blame Game

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 diferite provocări. Planificarea corectă, comunicarea, execuția și echipa motivată sunt cheile pentru testarea cu succes a acceptării utilizatorilor.

Testarea sistemului împotriva testării acceptării utilizatorilor

Implicarea echipei de testare începe destul de devreme în proiect chiar 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 vedem diferențele în SIT și UAT, este important să valorificăm sinergiile dar păstrează totuși independența între ambele faze, ceea ce ar permite un timp mai rapid de comercializare.

Concluzie

# 1) UAT nu se referă la pagini, câmpuri sau butoane. Presupunerea de bază chiar înainte de începerea acestui test este 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. 🙁

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

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

Un alt 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 de aceea, această testare 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, ceea ce înseamnă că există șanse mari de identificarea unor bug-uri și în această fază. Se întâmplă uneori. În afară de faptul că este o escaladare majoră în echipa QA, bug-urile UAT înseamnă, de obicei, o întâlnire pentru a sta și a discuta despre cum să le tratezi ca următor În urma acestei testări, de obicei nu există 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 are loc atunci când UAT se realizează în mediul constructorului de software și este mai semnificativă în contextul comercialului de pe raft software.
• Testarea beta are loc atunci când UAT se realizează în mediul de producție sau în cel al clientului. Acest lucru este mai frecvent pentru aplicațiile orientate către clienți. Utilizatorii de aici sunt clienții reali ca tine și mine în acest context.

# 5) De cele mai multe ori, într-un proiect obișnuit de dezvoltare software, UAT se desfășoară în mediul QA dacă există nu este un mediu de punere în scenă sau 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. Toate acestea fiind făcute, faza de acceptare a utilizatorului este considerată poarta de intrare în implementare și producție.

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

= > Citiți aici TOATE tutorialele din această serie

= > Vizitați aici pentru seria de tutoriale complete a planului de testare