what is user acceptance testing
Esbrineu què és la prova d’acceptació d’usuaris (UAT), juntament amb la seva definició, tipus, passos i exemples:
La meva regla número u quan intento entendre un concepte nou és que: el nom sempre serà rellevant i majoritàriament un significat literal (en el context tècnic).
Esbrinar què és això, m’entendrà inicialment i m’ajudarà a començar.
html preguntes i respostes per a entrevistes amb experiència
=> Feu clic aquí per obtenir una sèrie completa de programes de proves
Posem a prova aquest concepte.
=> Llegiu tots els tutorials a la nostra sèrie de proves d’acceptació.
Què aprendreu:
- Què són les proves d'acceptació d'usuaris?
- Quan es realitza?
- Qui realitza UAT?
- Necessitat de proves d’acceptació d’usuaris
- Procés de prova d’acceptació d’usuaris
- Governança de la UAT
- Planificació de proves UAT
- Disseny de proves d’acceptació d’usuaris
- Execució de la prova
- Eines i metodologies
- UAT en un entorn àgil
- Equip UAT: rols i responsabilitats
- 7 reptes de la UAT i del pla de mitigació
- Prova del sistema contra la prova d’acceptació de l’usuari
- Conclusió
Què són les proves d'acceptació d'usuaris?
Sabem què és la prova, l'acceptació significa aprovació o acord. L'usuari en el context d'un producte de programari és el consumidor del programari o bé la persona que va sol·licitar que es construís per a ell (client).
Per tant, seguint la meva regla, la definició serà:
Les proves d’acceptació d’usuaris (UAT), també conegudes com a proves beta o d’usuari final, es defineixen com a proves del programari per part de l’usuari o del client per determinar si es pot acceptar o no. Aquesta és la prova final que es realitza un cop finalitzades les proves de funcionament, sistema i regressió.
L’objectiu principal d’aquestes proves és validar el programari en funció dels requisits empresarials. Aquesta validació la fan els usuaris finals que coneixen els requisits empresarials.
UAT, proves alfa i beta hi ha diferents tipus de proves d’acceptació.
Com que la prova d'acceptació de l'usuari és l'última prova que es realitza abans que el programari es posi en funcionament, òbviament aquesta és l'última oportunitat per al client de provar el programari i mesurar si és adequat per al propòsit.
Quan es realitza?
Normalment, aquest és l'últim pas abans que el producte es publiqui o abans que s'accepti el lliurament del producte. Això es realitza després de provar a fons el producte (és a dir, després de les proves del sistema ).
Qui realitza UAT?
Usuaris o client: pot ser algú que estigui comprant un producte (en el cas de programari comercial) o algú que hagi creat un programari personalitzat a través d’un proveïdor de serveis de programari o de l’usuari final si el programari els està disponible abans del temps i quan es busquen els seus comentaris.
L’equip pot estar format per provadors beta o el client hauria de seleccionar internament els membres de la UAT de tots els grups de l’organització per tal que cada rol d’usuari es pugui provar en conseqüència.
Necessitat de proves d’acceptació d’usuaris
Els desenvolupadors i verificadors de funcions són persones tècniques que validen el programari en contra de especificacions funcionals . Interpreten els requisits segons els seus coneixements i desenvolupen / proven el programari (aquí teniu la importància del coneixement del domini).
Aquest programari està complet d’acord amb les especificacions funcionals, però hi ha alguns requisits i processos empresarials que només es coneixen per als usuaris finals o bé s’interpreten erròniament.
Aquestes proves tenen un paper important en la validació de si es compleixen o no tots els requisits empresarials abans de llançar el programari per al seu ús al mercat. L’ús de dades en directe i casos d’ús reals fan d’aquestes proves una part important del cicle de llançament.
Moltes empreses que van patir grans pèrdues a causa de problemes posteriors al llançament saben la importància d’una prova d’acceptació d’usuaris amb èxit. El cost de solucionar els defectes després de la publicació és moltes vegades superior a la solució anterior.
És realment necessària la UAT?
Després de realitzar un munt de sistemes, proves d’integració i regressió, ens preguntaríem sobre la necessitat d’aquestes proves. En realitat, aquesta és la fase més important del projecte, ja que és el moment en què els usuaris que realment utilitzaran el sistema validarien el sistema perquè s’adapti al seu propòsit.
UAT és una fase de prova que depèn en gran mesura de la perspectiva dels usuaris finals i del coneixement del domini d’un departament que representa els usuaris finals.
De fet, seria realment útil per als equips empresarials si participessin en el projecte força aviat, de manera que poguessin aportar les seves opinions i contribucions que ajudarien a l’ús eficaç del sistema al món real.
Procés de prova d’acceptació d’usuaris
La forma més senzilla d’entendre aquest procés és pensar-ho com un projecte de proves autònom, és a dir, que tindrà les fases de pla, disseny i execució.
Els requisits previs següents són els següents abans de començar la fase de planificació:
# 1) Recopileu els criteris clau d'acceptació
En termes senzills, els criteris d’acceptació són una llista de coses que s’avaluaran abans d’acceptar el producte.
Poden ser de 2 tipus:
(i) Funcionalitat de l'aplicació o relacionada amb l'empresa
L’ideal seria que es validessin totes les funcions empresarials clau, però a causa de diversos motius, inclòs el temps, no és pràctic fer-ho tot. Per tant, una reunió o dues amb el client o els usuaris que participaran en aquesta prova ens pot donar una idea de la quantitat de proves que es farà i de quins aspectes es provaran.
(ii) Contractual - No hi entrarem i la implicació de l'equip de control de qualitat en tot això és gairebé res. Es revisa el contracte inicial que es redacta fins i tot abans que comenci el SDLC i s’arriba a un acord sobre si tots els aspectes del contracte s’han lliurat o no.
Ens centrarem només en la funcionalitat de l'aplicació.
# 2) Definiu l’abast de la participació en el control de qualitat.
El paper de l'equip de control de qualitat és un dels següents:
(i) Sense implicació - Això és molt rar.
(ii) Ajudeu en aquesta prova - El més comú. En aquest cas, la nostra implicació podria ser la formació dels usuaris de la UAT sobre com utilitzar l'aplicació i estar en espera durant aquestes proves per assegurar-nos que podem ajudar els usuaris en cas de qualsevol dificultat. O en alguns casos, a més d’estar en espera i ajudar-vos, podríem compartir les seves respostes i registrar els resultats o registrar errors, mentre els usuaris realitzen les proves reals.
(iii) Realitzar UAT i presentar resultats - Si aquest és el cas, els usuaris assenyalaran les àrees de l’AUT que volen avaluar i l’equip de control de qualitat realitza la pròpia avaluació. Un cop fets, els resultats es presenten als clients / usuaris i prendran una decisió sobre si els resultats que tenen a la mà són suficients o no i d’acord amb les seves expectatives per acceptar l’aut. La decisió mai no és la de l’equip de control de qualitat.
Segons el cas que ens ocupa, decidim quin és el millor enfocament.
Els objectius i expectatives principals:
Normalment, la UAT l’encarrega un expert en matèries (PIME) i / o un usuari empresarial, que pot ser el propietari o el client d’un sistema en proves. De manera similar a la fase de proves del sistema, la fase UAT també inclou fases religioses abans que es tanqui.
Les activitats clau de cada fase UAT es defineixen a continuació:
Governança de la UAT
De manera similar a les proves del sistema, s’aplica una governança eficaç per a la UAT per garantir que les portes de qualitat siguin juntes amb els criteris definits d’entrada i sortida (que es proporcionen a continuació **).
** Tingueu en compte que és només una orientació. Això es podria modificar en funció de les necessitats i requisits del projecte.
Planificació de proves UAT
El procés és gairebé el mateix que amb el fitxer pla de proves regulars en la fase del sistema.
L'enfocament més comú seguit en la majoria dels projectes és planificar conjuntament les fases de proves del sistema i de la UAT. Per obtenir més informació sobre el pla de proves UAT juntament amb una mostra, consulteu les seccions UAT del document de pla de proves adjunt.
Pla de prova d’acceptació d’usuaris
(Això és el mateix que trobareu al nostre lloc per a la sèrie de formació en QA).
Feu clic a la imatge següent i desplaceu-vos cap avall per trobar la mostra del document del pla de prova en diversos formats. En aquesta plantilla, consulteu la secció UAT.
Les dates, l’entorn, els actors (qui), els protocols de comunicació, les funcions i les responsabilitats, les plantilles, els resultats i el seu procés d’anàlisi, els criteris d’entrada-sortida, tot això i qualsevol altra cosa que sigui rellevant, es trobarà al pla de proves UAT.
Tant si l’equip de QA participa, participa parcialment o no participa en aquesta prova, és la nostra feina planificar aquesta fase i assegurar-nos que es tingui en compte tot.
=> Aquí teniu un document de mostra del pla de prova d’acceptació d’usuaris
Disseny de proves d’acceptació d’usuaris
En aquest pas s’utilitzen els criteris d’acceptació recollits per part dels usuaris. Les mostres podrien tenir l’aspecte que es mostra a continuació.
(Aquests són fragments de CSTE CBOK . Aquesta és una de les millors referències disponibles sobre aquesta prova.)
Plantilla de prova d'acceptació de l'usuari:
Basant-nos en els criteris, nosaltres (equip de control de qualitat) els proporcionem als usuaris una llista de casos de proves UAT. Aquests casos de prova no són diferents dels casos de prova del sistema habituals. Són només un subconjunt, ja que provem totes les aplicacions en contraposició, només a les àrees funcionals clau.
A més d’això, les dades, les plantilles per registrar els resultats de les proves, els procediments administratius, el mecanisme de registre de defectes, etc., han d’estar instal·lats abans de passar a la següent fase.
Execució de la prova
Normalment, quan és possible, aquesta prova es realitza en una classe de conferències o sales de guerra on els usuaris, els representants de l’equip PM, els representants de l’equip de control de qualitat s’asseuen junts un o dos dies i treballen tots els casos de proves d’acceptació.
O en cas que l’equip de control de qualitat realitzi les proves, executem els casos de prova a l’automàtic.
Un cop executades totes les proves i els resultats disponibles, el fitxer Decisió d'acceptació està fet. Això també s'anomena el Decisió d'anar / no anar . Si els usuaris n’estan satisfets és un Go, o bé és un No-go.
Arribar a la decisió d’acceptació sol finalitzar aquesta fase.
Eines i metodologies
Normalment, el tipus d’eines de programari que s’utilitzen durant aquesta fase de proves és similar a les eines que s’utilitzen durant la realització de proves funcionals.
Eines:
eines de revisió de codi obert git
Com que aquesta fase implica validar els fluxos completes de finalització de l'aplicació, pot ser difícil tenir una eina per automatitzar aquesta validació completament. Tanmateix, en certa mesura, podríem aprofitar els scripts automatitzats desenvolupats durant les proves del sistema.
De manera similar a les proves del sistema, els usuaris també utilitzarien eines de gestió de proves i gestió de defectes com QC, JIRA, etc. Aquestes eines es poden configurar per acumular dades per a la fase d'acceptació d'usuaris.
Metodologies:
Tot i que les metodologies convencionals, com ara usuaris empresarials específics que realitzen UAT del producte, segueixen sent rellevants, en un món veritablement global com l’actual, les proves d’acceptació d’usuaris de vegades han d’implicar clients variats entre països segons el producte.
Per exemple, els clients de tot el món utilitzarien un lloc web de comerç electrònic. En escenaris com aquest, les proves multitudinàries serien la millor opció viable.
Proves de multitud és una metodologia on persones de tot el món poden participar i validar l’ús del producte i donar suggeriments i recomanacions.
Les plataformes de proves de multitud estan construïdes i estan sent utilitzades per moltes organitzacions ara. A la plataforma s’allotja un lloc web o un producte que s’ha de fer una prova multitudinària i els clients poden proposar-se per validar-se. A continuació, s’analitzen i es prioritzen els comentaris proporcionats.
La metodologia de proves de multitud està demostrant ser més eficaç ja que es pot entendre fàcilment el pols del client a tot el món.
UAT en un entorn àgil
L’entorn àgil té una naturalesa més dinàmica. En un món àgil, els usuaris empresarials participaran al llarg dels sprints del projecte i el projecte es milloraria en funció dels bucles de retroalimentació d’aquests.
Al començament del projecte, els usuaris empresarials serien els principals grups d'interès que haurien de proporcionar requisits i actualitzar així la cartera de productes. Al final de cada sprint, els usuaris empresarials participarien a la demostració de sprint i estarien disponibles per proporcionar qualsevol comentari.
A més, es planificaria una fase UAT abans de la finalització del sprint on els usuaris empresarials fessin les seves validacions.
Els comentaris que es reben durant la demostració de sprint i el sprint UAT, es recopilen i es tornen a afegir a la cartera de productes que es revisa i es prioritza constantment. Així, en un món àgil, els usuaris empresarials estan més a prop del projecte i avaluen el mateix per al seu ús amb més freqüència a diferència dels projectes tradicionals de cascada.
Equip UAT: rols i responsabilitats
Una organització UAT típica tindria els següents rols i responsabilitats. L'equip de la UAT comptarà amb el suport del cap de projecte, el desenvolupament i els equips de proves en funció de les seves necessitats.
| Funcions | Responsabilitats | Lliurables |
|---|---|---|
| Director de programes empresarials | • Crear i mantenir el pla de lliurament del programa • Revisar i aprovar l'estratègia i el pla de proves UAT • Assegureu-vos que el programa es completi amb èxit segons el calendari i el pressupost previstos • Mantenir un contacte amb el gerent del programa de TI i supervisar el progrés del programa • Treballar estretament amb l'equip d'operacions comercials i equipar-los per a l'operació del primer dia • Document de requisit d’empresa de tancament de sessió • Reviseu el contingut del curs d'e-learning | • Informe de progrés del programa • Informe setmanal d’estat |
| Gestor de proves UAT | • Estratègia de Creta UAT • Assegureu una col·laboració eficaç entre IT i Business BA i PMO • Participar en reunions detallades sobre requisits • Revisió de l'estimació de l'esforç, pla de proves • Garantir la traçabilitat dels requisits • Impulseu la recopilació de mètriques per quantificar els beneficis derivats de la metodologia de proves actualitzada, les eines i l’ús de l’entorn | • Master Test Strategy • Revisar i aprovar escenaris de prova • Revisar i aprovar casos de prova • Revisar i aprovar la matriu de traçabilitat dels requisits • Informe d'estat setmanal |
| Líder i equip de proves de la UAT | • Verificar i validar els requisits empresarials contra el procés empresarial • Estimació de la UAT • Crear i executar un pla de prova UAT • Participar a la sessió JAD de requisits • Prepareu escenaris de prova, casos de prova i dades de prova en funció del procés empresarial • Mantenir la traçabilitat • Executeu casos de proves i prepareu registres de proves • Notificar els defectes de l'eina de gestió de proves i gestionar-los durant tot el cicle de vida • Elaborar l’informe final de la prova UAT • Proporcionar suport per a la preparació empresarial i proves en directe | • Registre de proves • Informe d'estat setmanal • Informe de defectes • Prova les mètriques d'execució • Informe resum de proves • Artefactes de proves reutilitzables arxivats |
7 reptes de la UAT i del pla de mitigació
Tant se val si formeu part d’un llançament de mil milions de dòlars o si sou un equip d’inici, hauríeu de superar tots aquests reptes per oferir programari amb èxit a l’usuari final.
# 1) Procés de configuració i desplegament de l'entorn:
La realització d’aquesta prova en el mateix entorn que l’equip de proves funcionals segurament acabarà passant per alt els casos d’ús del món real. A més, les activitats de prova crucials, com ara les proves de rendiment, no es poden dur a terme en un entorn de prova que estigui incomplet dades de prova .
Per a aquesta prova s’hauria d’establir un entorn similar a la producció.
Quan l’entorn UAT està separat de l’entorn de prova, haureu de controlar el cicle de llançament amb eficàcia. Un cicle de llançament incontrolat pot provocar diferents versions de programari en entorns de prova i UAT. Es perd un temps de prova d’acceptació valuós quan no es prova el programari amb la versió més recent.
Mentrestant, el temps necessari per al seguiment de problemes en una versió de programari incorrecta és elevat.
# 2) Planificació de proves:
Aquesta prova s’ha de planificar amb un pla de prova d’acceptació clar a la fase d’anàlisi de requisits i disseny.
En la planificació d’estratègies, s’hauria d’identificar el conjunt de casos d’ús del món real per a la seva execució. És molt important definir els objectius de la prova per a aquesta prova, ja que no és possible una execució completa de la prova per a aplicacions grans en aquesta fase de prova. Les proves s’han de realitzar prioritzant primer els objectius empresarials crítics.
Aquestes proves es realitzen al final del cicle de proves. Viouslybviament, és el període més crític per al llançament del programari. El retard en qualsevol de les fases anteriors de desenvolupament i proves es consumirà el temps UAT.
Una planificació incorrecta de les proves, en el pitjor dels casos, comporta una superposició entre la prova del sistema i la UAT. A causa de menys temps i pressió per complir els terminis, el programari es desplega en aquest entorn encara que no es completin les proves funcionals. Els objectius bàsics d’aquestes proves no es poden assolir en aquestes situacions.
El pla de proves UAT s’hauria de preparar i comunicar a l’equip abans de començar aquesta prova. Això els ajudarà a planificar proves, escriure casos de prova i scripts de prova i crear un entorn UAT.
# 3) Gestió de nous requisits empresarials com a incidents / defectes:
Les ambigüitats en els requisits queden atrapades en la fase UAT. Els verificadors UAT troben problemes que sorgeixen a causa de requisits ambigus (consultant la IU completa que no estava disponible durant la fase de recollida de requisits) i el registren com a defecte.
El client espera que es solucionin a la versió actual sense tenir en compte el moment de les sol·licituds de canvi. Si la direcció del projecte no pren una decisió oportuna sobre aquests canvis d'última hora, això podria provocar el fracàs de la versió.
# 4) Testers no qualificats o verificadors sense coneixement empresarial:
Quan no hi ha cap equip permanent, l’empresa selecciona personal de la UAT de diversos departaments interns.
Fins i tot si el personal està ben familiaritzat amb les necessitats empresarials o si no està format per als nous requisits que s’estan desenvolupant, no poden realitzar una UAT eficaç. A més, un equip empresarial no tècnic pot trobar-se amb moltes dificultats tècniques per executar els casos de prova.
Mentrestant, l'assignació de verificadors al final del cicle UAT no aporta cap valor al projecte. Poc temps per formar el personal de la UAT pot augmentar significativament les possibilitats d’èxit de la UAT.
# 5) Canal de comunicació inadequat:
La comunicació entre desenvolupament remot, proves i equip UAT és més difícil. La comunicació per correu electrònic sol ser molt difícil quan es té un equip de tecnologia offshore. Una petita ambigüitat en els informes d’incidents pot endarrerir la seva solució per un dia.
Una planificació adequada i una comunicació eficaç són fonamentals per a una col·laboració eficaç en equip. Els equips del projecte haurien d’utilitzar una eina basada en web per registrar defectes i preguntes. Això ajudarà a distribuir la càrrega de treball de manera uniforme i evitar la notificació de problemes duplicats.
# 6) Demanar a l'equip de proves funcionals que realitzi aquesta prova:
No hi ha pitjor situació que demanar a l’equip de proves funcionals que realitzi UAT.
Els clients descarreguen la seva responsabilitat a l’equip de proves per manca de recursos. En aquests casos, el propòsit d'aquestes proves es veu compromès. Un cop el programari es publiqui, els usuaris finals detectaran ràpidament els problemes que els verificadors funcionals no consideren escenaris del món real.
Una solució a això és assignar aquestes proves als verificadors dedicats i qualificats que tinguin coneixement empresarial.
# 7) El joc de la culpa
De vegades, els usuaris empresarials intenten trobar motius per rebutjar el programari. Podria ser el seu domini mostrar la seva superioritat o culpar l’equip de desenvolupament i proves per obtenir respecte a l’equip empresarial. Això és molt rar, però passa en equips amb política interna.
És molt difícil afrontar situacions d’aquest tipus. Tot i això, establir una relació positiva amb l’equip empresarial ajudaria definitivament a evitar el joc de la culpa.
Espero que aquestes directrius sens dubte us ajudaran a executar un pla d’acceptació d’usuaris amb èxit superant diversos reptes. La planificació, la comunicació, l’execució i un equip motivat adequats són les claus per a les proves d’acceptació d’usuaris amb èxit.
Prova del sistema contra la prova d’acceptació de l’usuari
La participació de l'equip de proves comença força aviat en el projecte des de la fase d'anàlisi de requisits.
Durant tot el cicle de vida del projecte, es realitza algun tipus de validació del projecte, és a dir, Proves estàtiques , Proves d’unitats, proves de sistemes, proves d’integració, proves de punta a punta o proves de regressió. Això ens permet entendre millor les proves realitzades en la fase UAT i la diferència que té de les altres proves realitzades anteriorment.
Tot i que veiem les diferències en SIT i UAT, és important que aprofitem les sinergies, però mantenim la independència entre ambdues fases que permetrien un temps de comercialització més ràpid.
Conclusió
# 1) UAT no tracta de pàgines, camps o botons. El subjacent suposició fins i tot abans que comenci aquesta prova és que tot allò bàsic es prova i funciona bé. Déu no ho vulgui, els usuaris troben un error tan bàsic com aquest: és una notícia molt dolenta per a l’equip de control de qualitat. :(
# 2) Aquesta prova tracta sobre l'entitat que és l'element principal del negoci.
Deixeu-me donar-vos un exemple: Si l'AUT és un sistema de venda de bitllets, la UAT no existirà, cercarà el menú que obre una pàgina, etc. Es tracta dels bitllets i la seva reserva, dels estats que pot fer, del seu recorregut pel sistema, etc.
Un altre Exemple, si el lloc és un lloc de concessionari de vehicles, el focus se centra en el 'cotxe i les seves vendes' i no realment el lloc. Per tant, el negoci principal és el que es verifica i es valida i qui és millor fer-ho que els propietaris d’empreses. Per això, aquesta prova té més sentit quan el client participa en gran mesura.
# 3) La UAT també és una forma de prova que significa que hi ha moltes possibilitats d'identificar alguns errors en aquesta fase també . De vegades passa. A part del fet que es tracta d’una escalada important a l’equip de control de qualitat, els errors UAT solen significar una reunió per seure i discutir com gestionar-los, ja que després d’aquesta prova no sol haver-hi temps per corregir-los i tornar-los a provar.
La decisió seria:
com obrir fitxers XML en word
- Premeu la data de publicació, primer solucioneu el problema i després continueu.
- Deixeu l'error tal qual.
- Considereu-ho com a part de la sol·licitud de canvi per a versions futures.
# 4) UAT es classifica com a proves Alpha i Beta, però aquesta classificació no és tan important en el context de projectes típics de desenvolupament de programari en una indústria basada en serveis.
- Proves alfa és quan UAT es duu a terme a l’entorn del creador de programari i és més significatiu en el context del programari comercial fora de la plataforma.
- Prova beta és quan la UAT es realitza a l’entorn de producció o a l’entorn del client. Això és més comú per a les aplicacions orientades al client. Els usuaris aquí són els clients reals com tu i jo en aquest context.
# 5) La majoria de les vegades en un projecte regular de desenvolupament de programari, UAT es duu a terme a Entorn de control de qualitat si no hi ha un entorn de posada en escena o UAT.
En resum, la millor manera d’esbrinar si el vostre producte és acceptable i adequat al propòsit és posar-lo davant dels usuaris.
Les organitzacions estan entrant en la forma àgil de lliurar, els usuaris empresarials s’impliquen més i els projectes es milloren i es lliuren mitjançant bucles de retroalimentació. En acabar, la fase d’acceptació d’usuaris es considera la porta d’entrada a la implementació i la producció.
Quina va ser la vostra experiència UAT? Vau estar en espera o heu provat els vostres usuaris? Els usuaris han trobat algun problema? Si és així, com vau tractar-los?
=> Llegiu també TOTS els tutorials d’aquesta sèrie
=> Visiteu aquí per obtenir la sèrie completa de programes de proves
Lectura recomanada
- Proves alfa i proves beta (guia completa)
- Què és la prova d'acceptació (una guia completa)
- Guia completa de proves de verificació de compilació (proves BVT)
- Proves funcionals contra proves no funcionals
- Les millors eines de prova de programari 2021 (Eines d'automatització de proves de control de qualitat)
- Tipus de proves de programari: diferents tipus de proves amb detalls
- Tutorial de proves de magatzem de dades de proves ETL (una guia completa)
- Tutorial de proves GUI: una guia completa de proves de la interfície d'usuari (UI)