what is acceptance testing
Introducere în testarea acceptării (partea I):
În această serie de tutoriale, veți învăța:
- Ce este testarea acceptării
- Teste de acceptare și plan de testare
- Rapoarte de stare și rezumate ale testelor de acceptare
- Ce este testul de acceptare a utilizatorilor (UAT)
Ați terminat cu testarea sistemului? Sunt majoritatea bug-urilor remediate? Sunt verificate și închise erorile? Deci ce urmeaza?
Următorul în listă vine Testarea acceptării, care este ultima fază a procesului de testare software . Aceasta este faza în care clientul decide GO / No-GO pentru produs și trebuie urmat în mod obligatoriu înainte de a lansa produsul pe piață. Eforturile comune ale dezvoltării și ale echipei de testare vor fi acordate de către client, fie prin acceptarea sau respingerea Produsului dezvoltat.
Acest tutorial unic privind testarea acceptării vă va oferi o imagine de ansamblu completă a semnificației, tipurilor, utilizărilor și a altor factori implicați în testul de acceptare într-un mod simplu și ușor pentru o mai bună înțelegere.
Ce veți învăța:
- Ce este testarea acceptării?
- De ce teste de acceptare?
- Tipuri
- Cine face testarea de acceptare?
- Calitățile testatorilor de acceptare
- Utilizare
- Diferențe între testarea sistemului, testarea acceptării și testarea acceptării utilizatorului
- Teste de acceptare
- Pat de testare de acceptare
- Criterii de intrare și ieșire pentru AT
- Procesul de testare a acceptării
- Factori de succes pentru acest test
- Concluzie
- Lectură recomandată
Ce este testarea acceptării?
Odata ce Proces de testare a sistemului este completat de echipa de testare și este semnat, întregul produs / aplicație este predat clientului / puțini utilizatori ai clienților / ambii, pentru a testa acceptabilitatea acestuia, adică, produsul / aplicația ar trebui să fie impecabil în îndeplinirea atât a aspectelor critice, cât și a celor cerințe majore de afaceri. De asemenea, fluxurile de afaceri de la un capăt la altul sunt verificate similar ca în scenariul în timp real.
Mediul asemănător producției va fi mediul de testare pentru acceptarea testării (denumit de obicei Staging, Pre-Prod, Fail-Over, mediu UAT).
Acesta este un tehnica de testare a cutiei negre unde numai funcționalitatea este verificată pentru a se asigura că produsul îndeplinește criteriile de acceptare specificate (nu este nevoie de cunoștințe de proiectare / implementare).
De ce teste de acceptare?
Deși testarea sistemului a fost finalizată cu succes, testul de acceptare este solicitat de către client. Testele efectuate aici sunt repetitive, deoarece ar fi fost acoperite în testarea sistemului.
Atunci, de ce se efectuează testarea de către clienți?
Asta pentru ca:
- Pentru a câștiga încredere în produsul care este lansat pe piață.
- Pentru a vă asigura că produsul funcționează așa cum trebuie.
- Pentru a vă asigura că produsul corespunde standardelor actuale ale pieței și că este suficient de competitiv cu celelalte produse similare de pe piață.
Tipuri
Există mai multe tipuri de testare.
Puțini dintre ei sunt enumerați mai jos:
# 1) Testarea acceptării utilizatorului (UAT)
UAT este de a evalua dacă produsul funcționează pentru utilizator, corect pentru utilizare. Cerințele specifice, care sunt destul de des utilizate de utilizatorii finali, sunt selectate în principal în scopul testării. Aceasta este denumită și Testarea utilizatorului final.
Termenul „Utilizator” aici înseamnă utilizatorii finali cărora le este destinat Produsul / aplicația și, prin urmare, testarea se efectuează din perspectiva utilizatorilor finali și din punctul lor de vedere.
=> De asemenea Citit: Ce este testul de acceptare a utilizatorilor (UAT)?
# 2) Testarea acceptării afacerii (BAT)
Aceasta este pentru a evalua dacă produsul îndeplinește sau nu obiectivele și scopurile afacerii.
BAT se concentrează în principal pe beneficii comerciale (finanțe), care sunt destul de provocatoare din cauza condițiilor de piață în schimbare / tehnologiilor avansate, astfel încât implementarea actuală ar putea fi nevoită să sufere modificări care să ducă la bugete suplimentare.
cel mai bun downloader video gratuit Windows 10
Chiar și produsul care trece cerințele tehnice poate eșua BAT din aceste motive.
# 3) Testarea acceptării contractului (CAT)
Acesta este un contract care specifică că, odată ce produsul devine activ, într-o perioadă prestabilită, trebuie efectuat testul de acceptare și trebuie să treacă toate cazurile de utilizare a acceptării.
Contractul semnat aici este denumit Contract de nivel de serviciu (SLA), care include termenii în care plata va fi efectuată numai dacă serviciile pentru produs sunt conforme cu toate cerințele, ceea ce înseamnă că contractul este îndeplinit.
Uneori, acest contract se poate întâmpla înainte ca Produsul să intre în vigoare. Fie căile, un contract ar trebui să fie bine definit în ceea ce privește perioada de testare, domeniile de testare, condițiile privind problemele întâmpinate în etapele ulterioare, plăți etc.
# 4) Reglementări /ConformitateTestarea acceptării (RAT)
Aceasta este pentru a evalua dacă Produsul încalcă regulile și reglementările definite de guvernul țării în care este lansat. Acest lucru poate fi neintenționat, dar va avea un impact negativ asupra afacerii.
De obicei, produsul / aplicația dezvoltat care este destinat să fie lansat în întreaga lume, trebuie să fie supus RAT, deoarece diferite țări / regiuni au reguli și reglementări diferite definite de către organele sale de conducere.
Dacă se încalcă oricare dintre reguli și reglementări pentru orice țară, atunci țara respectivă sau regiunea specifică din țara respectivă nu va avea permisiunea de a utiliza Produsul și este considerat ca un Eșec. Furnizorii Produsului vor fi direct responsabili dacă Produsul este eliberat, chiar dacă există o încălcare.
# 5) Testarea operațională de acceptare (OAT)
Aceasta este pentru a evalua disponibilitatea operațională a produsului și este o testare nefuncțională. Acesta include în principal testarea recuperării, compatibilității, mentenanței, disponibilității asistenței tehnice, fiabilității, fail-over-ului, localizării etc.
OAT asigură în principal stabilitatea produsului înainte de a-l lansa în producție.
# 6) Testarea alfa
Aceasta este pentru a evalua produsul în mediul de dezvoltare / testare de către o echipă specializată de testeri numiți de obicei testeri alfa. Aici, feedback-ul testerilor, sugestiile ajută la îmbunătățirea utilizării produsului și, de asemenea, la remedierea anumitor erori.
Aici, testarea are loc într-un mod controlat.
=> Citește și: Ce este testarea alfa?
# 7) Testarea beta / Testarea pe teren
Aceasta este pentru a evalua produsul expunându-l utilizatorilor finali reali, numiți de obicei beta testeri / utilizatori beta, în mediul lor. Se colectează feedback continuu de la utilizatori și problemele sunt rezolvate. De asemenea, acest lucru ajută la îmbunătățirea / îmbunătățirea produsului pentru a oferi o experiență bogată de utilizator.
Testarea are loc într-o manieră necontrolată, ceea ce înseamnă că un utilizator nu are restricții cu privire la modul în care este utilizat produsul.
=> Citește și: Ce este testarea beta?
Toate aceste tipuri au un obiectiv comun:
- Asigurați-vă că câștigați / îmbogățiți încrederea în produs.
- Asigurați-vă că Produsul este gata pentru a fi utilizat de utilizatorii reali.
Cine face testarea de acceptare?
Pentru tipul Alpha, doar membrii organizației (care au dezvoltat produsul) efectuează testarea. Acești membri nu fac parte direct din proiect (manageri / clienți de proiect, dezvoltatori, testeri). Echipele de management, vânzări, asistență efectuează de obicei testarea și oferă feedback în consecință.
În afară de tipul Alpha, toate celelalte tipuri de acceptare sunt în general efectuate de diferiți actori. La fel ca clienții, clienții clienților, testerii specializați din organizație (nu întotdeauna).
De asemenea, este bine să implicați analiști de afaceri și expertiză în materie în timp ce efectuați acest test pe baza tipului său.
Calitățile testatorilor de acceptare
Testerii cu calitățile de mai jos sunt calificați ca testori de acceptare:
- Abilitatea de a gândi logic și analitic.
- Cunostinte bune de domeniu.
- Capabil să studieze produsele competitive de pe piață și să le analizeze la fel în produsul dezvoltat.
- Având percepția utilizatorului final în timpul testării.
- Înțelegeți nevoile de afaceri pentru fiecare cerință și testați în consecință.
Impactul problemelor constatate în timpul acestei testări
Orice problemă întâmpinată în faza de testare a acceptării trebuie considerată ca fiind una cu prioritate ridicată și remediată imediat. Acest lucru necesită, de asemenea, să se efectueze analiza cauzei rădăcină pentru fiecare problemă găsită.
Echipa de testare joacă un rol major în furnizarea de RCA-uri pentru probleme de acceptare. Acestea ajută și la determinarea eficienței testării.
De asemenea, problemele valide ale testului de acceptare vor atinge atât eforturile de testare, cât și eforturile echipei de dezvoltare în ceea ce privește impresia, evaluările, sondajele clienților etc. Uneori, dacă se constată o ignoranță din partea echipei de testare cu privire la validări, aceasta duce la escaladări.
Utilizare
Această testare este utilă din mai multe aspecte.
Puține dintre acestea includ:
- Pentru a afla problemele ratate în timpul fazei de testare funcțională.
- Cât de bine este dezvoltat produsul.
- Un produs este ceea ce au nevoie de fapt clienții.
- Feedback-urile / sondajele au contribuit la îmbunătățirea performanței produsului și a experienței utilizatorului.
- Îmbunătățiți procesul urmat de RCA-uri ca intrare.
- Minimizați sau eliminați problemele care decurg din produsul de producție.
Diferențe între testarea sistemului, testarea acceptării și testarea acceptării utilizatorului
Date mai jos sunt diferențele principale dintre aceste 3 tipuri de teste de acceptare.
Testarea sistemului | Testarea de acceptare | Testarea acceptării utilizatorului |
---|---|---|
Se efectuează teste pozitive și negative | De obicei se efectuează teste pozitive | Se efectuează numai teste pozitive |
Testarea de la cap la cap se efectuează pentru a verifica dacă produsul îndeplinește toate cerințele specificate | Testarea se efectuează pentru a verifica dacă produsul îndeplinește cerințele clientului pentru acceptabilitate | Testarea se efectuează pentru a verifica dacă cerințele utilizatorilor finali sunt îndeplinite pentru acceptabilitate |
Un produs este testat ca întreg concentrându-se doar pe nevoi funcționale și nefuncționale | Produsul este testat pentru nevoile afacerii - acceptabilitatea utilizatorului, obiective comerciale, reguli și reglementări, operațiuni etc. | Produsul este testat numai pentru acceptabilitatea utilizatorului |
Echipa de testare efectuează testarea sistemului | Clientul, clienții clienților, testerul (rar), managementul, vânzările, echipele de asistență efectuează teste de acceptare în funcție de tipul de test efectuat | Clientul, clientul clienților, testerii (rar) efectuează teste de acceptare a utilizatorilor |
Testele sunt scrise și executate | Testele de acceptare sunt scrise și executate | Testele de acceptare a utilizatorilor sunt scrise și executate |
Poate fi funcțional și nefuncțional | De obicei funcțional, dar nefuncțional în cazul RAT, OAT etc. | Numai funcțional |
Pentru testare sunt utilizate numai datele de testare | Datele în timp real / datele de producție sunt utilizate pentru testare | Datele în timp real / datele de producție sunt utilizate pentru testare |
Problemele găsite sunt considerate ca erori și rezolvate în funcție de severitate și prioritate | Problemele găsite marchează produsul ca eșec și considerat a fi remediat imediat | Problemele găsite marchează Produsul ca eșec și considerat a fi remediat imediat |
Mod controlat de testare | Poate fi controlat sau necontrolat pe baza tipului de testare | Mod de testare necontrolat |
Testarea mediului de dezvoltare | Testare pe mediu de dezvoltare sau mediu de pre-producție sau mediu de producție, în funcție de tip | Testarea este întotdeauna în mediul de pre-producție |
Nu există ipoteze, dar dacă există poate fi comunicată | Fără presupuneri | Fără presupuneri |
Teste de acceptare
Similar cu cazurile de testare a produselor, avem teste de acceptare. Testele de acceptare sunt derivate din criteriile de acceptare a poveștilor utilizatorilor. Acestea sunt de obicei scenariile scrise la detaliile la nivel înalt despre ceea ce trebuie să facă produsul în condiții diferite.
Nu oferă o imagine clară asupra modului de efectuare a testelor, ca în cazurile de testare. Testele de acceptare sunt scrise de testeri care au o aderență completă asupra produsului, de obicei expertiza în materie. Toate testele scrise sunt revizuite de un client și / sau analiști de afaceri.
Aceste teste executate în timpul testului de acceptare. Împreună cu testele de acceptare, trebuie pregătit un document detaliat cu privire la orice aranjament care trebuie făcut. Ar trebui să includă detalii în fiecare minut cu capturi de ecran adecvate, valori de configurare, condiții etc.
Pat de testare de acceptare
Patul de testare pentru acest test este similar cu un pat de test obișnuit, dar este unul separat. Platforma cu toate componentele hardware, software, produsele de operare, configurarea și configurarea rețelei, configurarea și configurarea serverului, configurarea și configurarea bazei de date, licențele, pluginurile etc., trebuie să fie configurate la fel. mediul de producție.
Patul de testare a acceptării este o platformă / mediu în care vor fi executate testele de acceptare proiectate. Înainte de a preda clientului mediul de testare a acceptării, este o bună practică să verificați eventualele probleme de mediu și stabilitatea produsului.
Dacă nu există un mediu separat configurat pentru testarea acceptării, în acest scop poate fi utilizat un mediu de testare regulat. Dar aici, va fi dezordonat, deoarece datele de testare de la testarea regulată a sistemului și datele în timp real de la testarea de acceptare sunt păstrate într-un singur mediu.
Patul de testare a acceptării este de obicei instalat în partea clientului (adică în laborator) și va avea acces restricționat la echipele de dezvoltare și testare.
Echipele vor fi obligate să acceseze acest mediu prin intermediul VM-urilor / sau adreselor URL concepute special, folosind acreditări speciale de acces, iar tot accesul la acesta va fi urmărit. Nimic din acest mediu nu trebuie adăugat / modificat / șters fără permisiunea clientului și acesta ar trebui să fie notificat cu privire la modificările efectuate.
Criterii de intrare și ieșire pentru AT
La fel ca orice altă fază din STLC, testarea acceptării are un set de criterii de intrare și ieșire care urmează să fie bine definite în Planul de testare a acceptării (care este acoperit în partea ulterioară a acestui tutorial).
Aceasta este faza care începe imediat după testarea sistemului și se termină înainte de lansarea producției. Deci, criteriile de ieșire din testarea sistemului devin o parte a criteriilor de intrare pentru AT. În mod similar, criteriile de ieșire din AT devin o parte a criteriilor de intrare pentru lansarea producției.
Criterii de intrare
Mai jos sunt condițiile care trebuie îndeplinite înainte de a începe:
- Cerințele comerciale ar trebui să fie clare și disponibile.
- Faza de testare a sistemului și a regresiei ar trebui finalizată.
- Toate erorile critice, majore și normale ar trebui să fie remediate și închise (erorile minore acceptate sunt în principal erori cosmetice care nu perturbă utilizarea produsului).
- Lista problemelor cunoscute ar trebui pregătită și împărtășită cu părțile interesate.
- Ar trebui să fie instalat patul de testare a acceptării și ar trebui să se efectueze verificări la nivel înalt pentru a nu exista probleme de mediu.
- Faza de testare a sistemului ar trebui să fie semnată, permițând produsului să treacă la faza AT (de obicei realizată prin comunicare prin e-mail).
Criterii de ieșire
Există anumite condiții care trebuie îndeplinite de AT pentru ca produsul să fie lansat pentru lansarea producției.
Acestea sunt după cum urmează:
- Testele de acceptare ar trebui executate și toate testele ar trebui să treacă.
- Niciun defect critic / major nu a rămas deschis. Toate defectele trebuie remediate și verificate imediat.
- AT ar trebui să fie semnat de toate părțile interesate incluse Du-te / Nu-Du-te Decizie privind produsul.
Procesul de testare a acceptării
În Modelul V , Faza AT este în paralel cu faza Cerințe.
Procesul real AT merge așa cum se arată mai jos:
Analiza cerințelor de afaceri
Cerințele de afaceri sunt analizate prin trimiterea tuturor documentelor disponibile în cadrul proiectului.
Unele dintre acestea sunt:
- Specificațiile cerințelor de sistem
- Document de cerințe comerciale
- Cazuri de utilizare
- Diagramele fluxului de lucru
- Matrice de date proiectată
Planul de testare a acceptării proiectului
Există anumite elemente care trebuie documentate în Planul de testare a acceptării.
Să aruncăm o privire asupra unora dintre ele:
- Strategia și abordarea testării acceptării.
- Criteriile de intrare și ieșire ar trebui să fie bine definite.
- Domeniul de aplicare al AT ar trebui să fie bine menționat și trebuie să acopere numai cerințele comerciale.
- Abordarea de proiectare a testului de acceptare ar trebui să fie detaliată, astfel încât oricine scrie teste să poată înțelege cu ușurință modul în care trebuie scris.
- Înființarea patului de testare, ar trebui menționate programul / termenele de testare efective.
- Deoarece testarea este efectuată de diferiți actori, ar trebui menționate detalii despre eroarea de înregistrare, deoarece este posibil ca părțile interesate să nu fie conștiente de procedura urmată.
Proiectarea și revizuirea testelor de acceptare
Testele de acceptare trebuie scrise la un nivel de scenariu menționând ceea ce trebuie făcut (nu în detaliu pentru a include cum se face). Acestea ar trebui să fie scrise numai pentru domeniile identificate de domeniu de aplicare pentru cerințele de afaceri și fiecare test trebuie să fie mapat la cerința sa de referință.
Toate testele de acceptare scrise trebuie revizuite pentru a atinge o acoperire ridicată a cerințelor de afaceri.
Aceasta este pentru a vă asigura că orice alte teste în afară de domeniul de aplicare menționat nu sunt implicate, astfel încât testarea să se încadreze în termenele programate.
Configurare pat de testare de acceptare
Patul de testare ar trebui să fie instalat similar cu un mediu de producție. Sunt necesare verificări la nivel foarte înalt pentru a confirma stabilitatea și utilizarea mediului. Împărtășiți acreditările pentru a utiliza mediul numai cu un părți interesate care efectuează acest test.
Configurați datele testului de acceptare
Datele de producție trebuie pregătite / completate ca date de testare în sisteme. De asemenea, ar trebui să existe un document detaliat astfel încât datele să fie utilizate pentru testare.
Nu aveți date de testare precum TestName1, TestCity1 etc., în schimb, Albert, Mexic etc. Acest lucru oferă o experiență bogată de date în timp real, iar testarea va fi actualizată.
Executarea testului de acceptare
Testele de acceptare proiectate trebuie executate pe mediu la acest pas. În mod ideal, toate testele ar trebui să treacă la prima încercare în sine. Nu ar trebui să existe erori funcționale care rezultă din testarea acceptării, dacă există, atunci acestea ar trebui raportate cu o mare prioritate pentru a fi remediate.
Din nou, erorile remediate trebuie verificate și închise ca o sarcină cu prioritate ridicată. Raportul de execuție a testului trebuie distribuit zilnic.
întrebări de interviu pe html și css
Erorile înregistrate în această fază ar trebui discutate într-o întâlnire de triaj a erorilor și trebuie să fie supuse unei proceduri de analiză a cauzei rădăcinii. Acesta este singurul punct în care testarea acceptării evaluează dacă toate cerințele comerciale sunt îndeplinite de produs sau nu.
Decizie de afaceri
Iese un Du-te / Nu-Du-te decizia pentru produsul care urmează să fie lansat în producție. Merge decizia va duce produsul înainte de a fi lansat pe piață. Impas decizia marchează produsul ca eșec.
Câțiva factori ai deciziei de interzicere:
- Calitatea slabă a produsului.
- Prea multe deschid erori funcționale.
- Abaterea de la cerințele afacerii.
- Nu respectă standardele pieței și are nevoie de îmbunătățiri pentru a se potrivi cu standardele actuale ale pieței.
Factori de succes pentru acest test
Odată ce acest test este planificat, pregătiți o listă de verificare care crește rata de succes a acestuia. Există câteva elemente de acțiune care trebuie urmate înainte de începerea testului de acceptare.
Sunt:
- Aveți un domeniu de aplicare bine definit și asigurați-vă că există o nevoie de afaceri pentru domeniul de aplicare identificat pentru aceste testări.
- Executați teste de acceptare în faza de testare a sistemului în sine cel puțin o dată.
- Efectuați extensiv testare ad-hoc pentru fiecare dintre scenariile testului de acceptare.
Concluzie
Pe scurt, testarea acceptării ajută la stabilirea eficienței echipelor de dezvoltare și testare.
Există mai multe instrumente pentru desfășurarea acestei activități, dar de obicei, este de preferat să se facă manual, deoarece există o implicare a utilizatorilor reali și a diferitelor părți interesate care nu provin dintr-un mediu tehnic și este posibil să nu fie fezabil pentru ei.
Ce urmeaza?
În următorul nostru tutorial, vom trece pe subiectele de mai jos:
- Exemple de criterii de testare a acceptării.
- Cum se scrie un plan de test de acceptare.
- Un șablon adecvat pentru scrierea testelor de acceptare.
- Cum se scrie teste de acceptare cu exemple.
- Identificarea scenariilor testului de acceptare.
- Rapoarte de testare de acceptare.
- Testarea acceptării în dezvoltarea Agile și bazată pe testare.
URMATORUL Tutorial nr. 2: Planul de testare a acceptării
Ați efectuat teste de acceptare? Am fi bucuroși să vă auzim experiențele !!
Lectură recomandată
- Testarea alfa și testarea beta (un ghid complet)
- Ce este testul de acceptare a utilizatorului (UAT): un ghid complet
- Ghid complet de testare a verificării de construcție (testare BVT)
- Testarea funcțională Vs testarea non-funcț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)
- Ghid de testare a securității aplicațiilor web